docker-compose deploy has no wiring for the buzz-pair-relay sidecar — mobile QR pairing 404s out of the box

[davidglogan]

Title: docker-compose deploy has no wiring for the buzz-pair-relay sidecar — mobile QR pairing 404s out of the box

Body:

Mobile QR pairing failed with WebSocket connection failed: HTTP error: 404 Not Found on a self-hosted relay deployed via deploy/compose/ (plain Docker Compose, not the Helm chart).

Root cause: the relay's NIP-11 doc advertised NIP-43 support (membership-enforcing relay, correctly per crates/buzz-relay/src/nip11.rs's own test suite intent), which makes the desktop client (desktop/src-tauri/src/commands/pairing.rs::pairing_relay_from_nip11) infer a /pair legacy-path sidecar — but deploy/compose/ never stands one up. There's no /pair route anywhere in the stack (bare reverse_proxy relay:3000 catch-all in the example Caddyfile), and no buzz-pair-relay service in deploy/compose/compose.yml. The relay's own test comment (nip11.rs) even predicts this exact failure mode: "advertising it on open relays misroutes pairing peers to a non-existent /pair sidecar."

By contrast, deploy/charts/buzz/templates/pairing-relay.yaml (Helm) does wire this up correctly — but it's pairingRelay.enabled: false by default there too, so it's easy to end up with a relay that advertises NIP-43 without a working pairing sidecar on either deploy path.

We worked around it by hand for our own compose deployment:

1. Added a pairing-relay service to compose.yml using the same ${BUZZ_IMAGE}, with entrypoint: ["/usr/local/bin/buzz-pair-relay"] (worth noting: Compose's command: only appends args to the image's baked-in ENTRYPOINT ["/usr/local/bin/buzz-relay"], unlike Kubernetes where command: replaces it — so copying the Helm chart's command: pattern into Compose silently runs the wrong binary; needed entrypoint: instead)
2. handle_path /pair* { reverse_proxy pairing-relay:5000 } in the Caddyfile
3. BUZZ_PAIRING_RELAY_URL=wss://<domain>/pair on the relay service, so NIP-11 advertises pairing_relay_url directly instead of relying on the NIP-43 inference path

Ask: add the pairing-relay service + Caddyfile route to deploy/compose/compose.yml/Caddyfile (or the example files), matching what the Helm chart already does, so a membership-enforcing compose deployment doesn't advertise a pairing capability it can't serve.

Secondary observation, lower confidence: the first pairing attempt after standing up the sidecar failed with "Lost connection to pairing relay" in the desktop app, even though both devices displayed and matched the same SAS code — it worked cleanly on retry. handle_nip42_auth (pairing.rs) waits up to 3s for an AUTH challenge from the relay before subscribing; buzz-pair-relay never sends one (it's a bare relay, no NIP-42), so both sides burn a fixed ~3s stall before their REQ subscription goes out. Against an ephemeral, non-buffered relay (no event replay), that's a plausible race window if one side's event arrives before the other side's subscription is live. Not confirmed as the root cause, but worth a look if this is reproducible elsewhere — happy to provide sidecar logs from the one reproduction we have.

[mgoulart]

There's a workaround that needs no sidecar at all and — unlike BUZZ_PAIRING_RELAY_URL=wss://pairing.buzz.xyz — keeps the entire pairing handshake on your own relay: temporarily drop NIP-43 so the desktop pairs directly against the main relay. Worth calling out because pointing BUZZ_PAIRING_RELAY_URL at Block's public pairing relay routes a private/self-hosted deployment's key-transfer handshake through Block infrastructure, which rather defeats the point of self-hosting.

Steps (verified on Desktop v0.5.3, relay image from main, closed compose deploy):

1. Set BUZZ_REQUIRE_RELAY_MEMBERSHIP=false on the relay, docker compose up -d relay.
2. NIP-43 leaves supported_nips (advertise_nip43 = has_stable_key && require_relay_membership), so pairing_relay_from_nip11 returns MainRelay instead of LegacyPath — the desktop connects the unpaired peer straight to the main relay, no /pair.
3. Pair (Scan QR). The relay log shows the two ephemeral pairing pubkeys doing NIP-42 auth and handing off directly:

   WebSocket connection established … addr=…
   NIP-42 auth successful … pubkey=<ephemeral source>
   NIP-42 auth successful … pubkey=<ephemeral target>
   

4. Re-close: BUZZ_REQUIRE_RELAY_MEMBERSHIP=true, docker compose up -d relay. Any identity already in relay_members (owner, existing members) stays admitted — the just-paired device keeps working. A brand-new identity would need a relay_members row before re-closing.

Caveat: this briefly opens the relay to any authenticated key, so only do it if the relay is network-restricted (ours is tailnet-only, so "open" = our own devices) or inside a maintenance window. For a publicly-reachable relay, PR #2736 (wire the sidecar) is the right permanent fix; this is the zero-extra-service option when you can gate the open window at the network layer.