fix(pairing): stop routing mobile pairing to a non-existent /pair sidecar

[mfethe1]

The bug

Pairing a mobile device against a membership-enforcing relay fails with:

WebSocket connection failed: HTTP error: 404 Not Found

Root cause

probe_pairing_relay treated a NIP-11 supported_nips: [43] advertisement as "this relay has a /pair sidecar" and synthesised wss://host/…/pair.

Nothing serves that path. buzz-relay exposes its WebSocket only at / (crates/buzz-relay/src/router.rs), and the real dedicated pairing relay (buzz-pair-relay) is a separate service, advertised via NIP-11 pairing_relay_url. The /pair convention is dead infrastructure.

NIP-43 was also the wrong signal: it means membership enforcement, not "a pairing sidecar exists". crates/buzz-relay/src/nip11.rs already carries a regression test warning about exactly this ("advertising it on open relays misroutes pairing peers to a non-existent /pair sidecar").

Worse, the fallback could never have worked. On a membership-enforcing relay an unpaired peer is rejected during NIP-42 AUTH (crates/buzz-relay/src/handlers/auth.rs → enforce_relay_membership in crates/buzz-relay/src/api/mod.rs), with no exemption for pairing kind:24134 or for ephemeral events. Such a relay genuinely requires a separate open pairing relay — it cannot pair over its own root socket at all.

The change

Replace PairingRelay::LegacyPath with PairingRelay::MembershipWithoutPairingRelay, which returns an actionable error naming the operator fix instead of fabricating a URL that 404s.

The two paths that actually work are unchanged:

Relay	Behaviour
Advertises pairing_relay_url	Use it as-is
Open relay (no NIP-43)	Pair over the relay's root socket
NIP-43, no pairing_relay_url	Clear error (was: fabricated /pair → 404)

Scope / operator note

This is a client-side correctness fix. It converts a mystifying 404 into a message that names the cause. Operators of membership-enforcing relays must still deploy a pairing relay for pairing to succeed:

pairingRelay:
  enabled: true
  url: wss://pairing.example.com

(or BUZZ_PAIRING_RELAY_URL directly — see deploy/charts/buzz/README.md).

Testing

cargo test pairing_relay — 7 passed, 0 failed.

Updated the two tests that asserted the /pair behaviour; the replacement asserts the error never contains /pair and does name the missing pairing relay, so the fabrication can't regress.

Open question for maintainers

Should the relay instead exempt pairing kind:24134 from the membership gate, so one relay can serve pairing without a sidecar? That would remove the need for a separate deployment entirely, but it's a change to the auth gate and wants a security review — deliberately not attempted here.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TqBMPniDMJfXpwi4XicdMg