Mobile Pairing Fails - WebSocket connection failed: HTTP error: 404 Not Found

[julianengel]

Describe the bug

I’m unable to connect the Buzz mobile app to the Buzz desktop relay. When I open the Mobile section in the desktop app’s settings, the pairing process fails with the following error:

WebSocket connection failed: HTTP error: 404 Not Found

Clicking Try again temporarily displays a pairing QR code, but after approximately 2–3 seconds the QR code disappears and the same WebSocket 404 error returns. Because the QR code does not remain available and the underlying WebSocket connection fails, I cannot complete the mobile pairing process or reach the six-digit verification step.

Steps to reproduce

1. Open the Buzz desktop app.

2. Open Settings.

3. Select Mobile under the App section.

4. Wait for the mobile pairing screen to load.

5. If the error is already displayed, click Try again.

6. Observe that a pairing QR code appears briefly.

7. After approximately 2–3 seconds, observe that the QR code disappears.

8. See the following error:

   WebSocket connection failed: HTTP error: 404 Not Found

Expected behavior

The desktop app should establish the required WebSocket connection and display a stable pairing QR code. I should then be able to scan the code using the Buzz mobile app, compare and confirm the six-digit verification code on both devices, and complete the pairing process successfully.

Version and platform

• Buzz version: 0.5.8
• OS: macOS Tahoe 26.5.2
• Mobile OS: Unknown

Logs / additional context

Error displayed in the Buzz desktop app:

WebSocket connection failed: HTTP error: 404 Not Found

The issue was reproduced multiple times using the Try again button. On each retry, the QR code appeared only briefly before being replaced by the same error.

The failure occurs before the mobile device can be paired and before the six-digit verification step is reached. No additional diagnostic logs or technical details were exposed in the app interface.

[blxxt]

Same here. We're self-hosting (via Render) and get the same exact issue

[derekross]

Likely cause: the auth-free pairing sidecar is not running behind /pair.

Device pairing (NIP-AB, kind 24134) needs the separate buzz-pair-relay binary — no auth, no persistence, no history. A device mid-pairing holds a fresh ephemeral key that is not a relay member yet, so the main relay refuses it at handlers/auth.rs:219-236 ("restricted: not a relay member"). So pointing BUZZ_PAIRING_RELAY_URL at the main relay is not a workaround — it just turns the 404 into a 401, which surfaces as "pairing relay rejected the authentication" and a Desktop hang on "relay closed waiting for EOSE".

Five-second check, if you are self-hosting:

curl -sS -o /dev/null -w "%{http_code}\n" https://<your-relay>/pair

404 = no route and/or no sidecar — this issue. Bare 400 = the sidecar is there and answering; it serves no NIP-11, so a non-upgrade GET is expected to 400 (lib.rs:941-945). /pair is upstream's own convention, not something operators invent — lib.rs:9 routes only that path and values.yaml:206-212 calls it "the legacy same-host /pair convention".

Why this is easy to hit: the sidecar is in the image (Dockerfile:72/171/178) and Helm deploys it (templates/pairing-relay.yaml, values.yaml:210-220), but Helm is the only shipped deployment config that does. No compose file in the repo references it — git grep -in pair -- "*compose*" on main returns one hit, the word "keypair" in deploy/compose/README.md:24. Every non-Helm self-hosted path therefore needs the operator to add it by hand.

What worked for us: a pairing-relay service using entrypoint: — not command:, since the image ENTRYPOINT is already buzz-relay, so command: just passes args to the wrong binary (Helm can use command: because k8s command maps to ENTRYPOINT) — bound loopback-only, plus a /pair proxy location with a WebSocket upgrade. Phone paired end-to-end after that.

Two things we ruled out on the wire, so nobody re-chases them: #4932 / PR #5298's path-strip (a full handshake through the container succeeded, SAS matched, key transferred, zero AUTH frames in 12s), and the AppImage-vs-.deb packaging difference (separate WebKit issue). Also note a REQ without a #p filter is CLOSED with "#p filter required" — expected, not a bug.

#2734, #3842 and #3291 already pointed at the sidecar and were right.

Happy to share a generalized compose bundle change if that would be useful.