fix(desktop): pairing shows a bare 404 when the legacy /pair fallback hits a relay with no pairing endpoint

[webdevtodayjason]

Problem

When a NIP-43 relay advertises no pairing_relay_url in its NIP-11 document, the desktop resolves the pairing endpoint through the legacy fallback: pairing_relay_from_nip11 (desktop/src-tauri/src/commands/pairing.rs:469) sees 43 in supported_nips and returns PairingRelay::LegacyPath, and resolve_pairing_relay_url (pairing.rs:452) appends /pair to the main relay URL.

If nothing serves that path (the state every compose deployment was in before #2736), the WebSocket upgrade 404s and the QR panel surfaces the raw transport error from pairing.rs:240:

WebSocket connection failed: HTTP error: 404 Not Found

That message names no URL, no route decision, and no config lever. Several self-hosters in #2734 independently had to source-dive config.rs and pairing.rs to discover that BUZZ_PAIRING_RELAY_URL (or routing /pair to a buzz-pair-relay sidecar) was the fix. @DrDoomi called out the diagnosability gap explicitly: #2734 (comment)

Suggested fix

The route decision is already a typed enum (PairingRelay, pairing.rs:411), so the connect error mapping at pairing.rs:238 can know which route failed. When the route is LegacyPath and the handshake fails with an HTTP status, emit something actionable instead of the bare transport error, along the lines of:

Pairing endpoint wss://<domain>/pair not found (404). The relay advertises
NIP-43 but no pairing_relay_url, and nothing is serving /pair. Set
BUZZ_PAIRING_RELAY_URL on the relay or route /pair to a buzz-pair-relay
instance (see deploy/compose/README.md, Device pairing).

Configured and MainRelay failures can keep the current message with the attempted URL appended, which also helps the split domain case when the configured URL is wrong.

Context

Follow-up to #2734. #2736 fixes the compose bundle so fresh deployments get a working /pair out of the box, but any deployment without a routed /pair or a configured pairing_relay_url still fails with the bare 404, and the error should say why.

[mgoulart]

Confirmed on Desktop 0.5.3 against a closed NIP-43 compose relay — the bare HTTP error: 404 Not Found cost us a source dive, and your suggested actionable error would have ended it in one line. +1 on the fix.

The confusion path, concretely: our self-hosted relay ran require_relay_membership=true with a stable key, so its NIP-11 advertised NIP-43 but carried no pairing_relay_url. pairing_relay_from_nip11 therefore returned LegacyPath, resolve_pairing_relay_url appended /pair, and the QR panel surfaced only:

WebSocket connection failed: HTTP error: 404 Not Found

Nothing in that names the URL it dialed (wss://<relay>/pair), the route decision (LegacyPath), or the lever (BUZZ_PAIRING_RELAY_URL / a /pair sidecar). We only got unstuck by reading pairing.rs and config.rs — the same dead end #2734 describes.

Concretely, the PairingRelay::LegacyPath arm has everything the message needs already typed. Something like:

Pairing endpoint wss://<relay>/pair returned HTTP 404.
This relay advertises NIP-43 but no pairing_relay_url, so pairing fell back to the
legacy /pair route, which nothing is serving. Set BUZZ_PAIRING_RELAY_URL on the relay
(or route /pair to a buzz-pair-relay sidecar). See #2734 / #3842.

would have turned a multi-file source dive into a copy-paste fix. The route enum makes the branch known at the error site, so the message can be specific without guessing.

[rian-dolphin]

Seeing the same error when using a relay based on the Buzz Railway template