Separate canonical relay identity from WebSocket transport endpoint #1

Open
opened 2026-07-22 12:41:09 +00:00 by thesimplekid · 0 comments
Owner

Problem

Beekeeper currently uses relay_url for three distinct concerns:

  1. The TCP/WebSocket destination passed to connect_async.
  2. The HTTP Host used by Buzz for host-bound tenant selection.
  3. The canonical relay URL signed into the NIP-42 AUTH event.

This prevents a co-located Beekeeper deployment from connecting directly to its relay. For example, the canonical identity may be wss://buzz.example.com, while the relay is directly reachable at ws://10.0.0.10:3000. Using the canonical URL sends local traffic through the public TLS proxy and back to the same network. Using the internal URL directly changes both the tenant host and NIP-42 relay tag, so the relay rejects authentication.

We encountered this operationally when the public hairpin was blackholed by policy routing: the local relay health endpoint was healthy, but beekeeper-prepare repeatedly failed with Timeout waiting for relay message because it depended on the external route.

Proposed design

Separate logical relay identity from physical connection transport:

relay_url = "wss://buzz.example.com"
relay_connect_url = "ws://10.0.0.10:3000"

relay_connect_url should be optional and default to relay_url for backwards compatibility.

When it is set, the client should:

  • Open the socket using relay_connect_url.
  • Override the WebSocket handshake Host with the authority derived from relay_url.
  • Continue building the NIP-42 AUTH event with relay_url.

This permits an unencrypted connection only on the trusted local network while retaining the canonical public identity and TLS posture in the signed authentication event.

The NixOS module could expose this as services.beekeeper.relayConnectUrl. The generated fleet configuration should carry both values. Agent units should also receive an equivalent transport override such as BUZZ_RELAY_CONNECT_URL, coordinated with buzz-ws-client and the Buzz agent runtime.

Acceptance criteria

  • Existing configurations with only relay_url behave unchanged.
  • Beekeeper can connect to an internal ws://IP:port transport while sending the canonical public Host.
  • NIP-42 AUTH continues signing and validating against the canonical wss:// relay URL.
  • Tests cover a different transport address, Host override, and canonical AUTH relay tag.
  • The NixOS module exposes the optional connection URL and propagates it to Beekeeper and hosted agent runtimes.
## Problem Beekeeper currently uses `relay_url` for three distinct concerns: 1. The TCP/WebSocket destination passed to `connect_async`. 2. The HTTP `Host` used by Buzz for host-bound tenant selection. 3. The canonical relay URL signed into the NIP-42 AUTH event. This prevents a co-located Beekeeper deployment from connecting directly to its relay. For example, the canonical identity may be `wss://buzz.example.com`, while the relay is directly reachable at `ws://10.0.0.10:3000`. Using the canonical URL sends local traffic through the public TLS proxy and back to the same network. Using the internal URL directly changes both the tenant host and NIP-42 relay tag, so the relay rejects authentication. We encountered this operationally when the public hairpin was blackholed by policy routing: the local relay health endpoint was healthy, but `beekeeper-prepare` repeatedly failed with `Timeout waiting for relay message` because it depended on the external route. ## Proposed design Separate logical relay identity from physical connection transport: ```toml relay_url = "wss://buzz.example.com" relay_connect_url = "ws://10.0.0.10:3000" ``` `relay_connect_url` should be optional and default to `relay_url` for backwards compatibility. When it is set, the client should: - Open the socket using `relay_connect_url`. - Override the WebSocket handshake `Host` with the authority derived from `relay_url`. - Continue building the NIP-42 AUTH event with `relay_url`. This permits an unencrypted connection only on the trusted local network while retaining the canonical public identity and TLS posture in the signed authentication event. The NixOS module could expose this as `services.beekeeper.relayConnectUrl`. The generated fleet configuration should carry both values. Agent units should also receive an equivalent transport override such as `BUZZ_RELAY_CONNECT_URL`, coordinated with `buzz-ws-client` and the Buzz agent runtime. ## Acceptance criteria - Existing configurations with only `relay_url` behave unchanged. - Beekeeper can connect to an internal `ws://IP:port` transport while sending the canonical public Host. - NIP-42 AUTH continues signing and validating against the canonical `wss://` relay URL. - Tests cover a different transport address, Host override, and canonical AUTH relay tag. - The NixOS module exposes the optional connection URL and propagates it to Beekeeper and hosted agent runtimes.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
thesimplekid/beekeeper#1
No description provided.