Report a reproducible bug in Buzz

[myaji35]

Self-hosted iOS pairing is unreachable: #2734 fix lands, then #4198 blocks credential import

Summary

On a self-hosted relay, applying the buzz-pair-relay sidecar workaround from #2734
gets mobile pairing through steps 1 and 2 (QR scan, SAS confirm), but step 3
(credential import) then fails with the HTTPS requirement from #4198.

The two known issues compose into a dead end: there is no configuration that
satisfies both the relay's NIP-98 check and the iOS app's HTTPS requirement.

Environment

Component	Value
Relay image	ghcr.io/block/buzz:main @ sha256:295bf4f5fa93…
Relay version (NIP-11)	0.2.1
Desktop app	0.5.24 (macOS, Apple Silicon)
iOS app	App Store build, Sep 2026
Host	Debian 13 (trixie), aarch64 (Raspberry Pi 5)
Ingress	Cloudflare Tunnel → plaintext HTTP to relay

What works after the #2734 workaround

Added a pair-relay service using the same image with
entrypoint: /usr/local/bin/buzz-pair-relay, exposed it on its own hostname,
and set BUZZ_PAIRING_RELAY_URL on the main relay.

Two details that were not obvious and may be worth documenting:

1. BUZZ_PAIR_RELAY_BIND_ADDR defaults to 127.0.0.1:5000, so the sidecar is
   unreachable from outside the container unless it is set to 0.0.0.0:5000.
2. The relay then advertises it correctly:

   $ curl -s http://<relay-host> | jq .pairing_relay_url
   "ws://<pair-host>"
   

Pairing now progresses:

buzz-pair-relay listening on 0.0.0.0:5000
conn opened conn_id=1 active=1      # desktop
conn opened conn_id=2 active=2      # phone

Desktop shows steps 1 and 2 as complete (QR scanned, six-digit SAS confirmed on
both devices).

Where it fails

Step 3 fails on the phone:

Failed to import credentials:
FormatException: Relay URL must use HTTPS

Both sidecar connections then close and the desktop UI spins on
"Pairing mobile device…" indefinitely with no timeout or error surfaced:

conn closed conn_id=2 active=1
conn closed conn_id=1 active=0

The phone never reaches the main relay — no new pubkey appears in relay logs.

Why this cannot be fixed by configuration

Switching the relay URL to https:// breaks NIP-98 auth for every other client:

{"error":"auth_error","message":"relay error 401: NIP-98: NIP-98 HTTP Auth
verification failed: URL mismatch: event has `https://<host>/query`,
expected `http://<host>/query`"}

The relay derives the expected URL scheme from the protocol it received, not
from forwarding headers. Behind a TLS-terminating proxy this is always http.
Inspecting the relay binary, there appears to be no way to change that:

• no env var matching BUZZ_*(PROXY|FORWARD|SCHEME|TRUST)*
• no X-Forwarded-Proto / trust_proxy handling strings
• no BUZZ_TLS* / BUZZ_CERT* — the relay does not terminate TLS itself

So the requirements are mutually exclusive:

Client	Requires
iOS app (credential import)	https://
CLI, desktop, agents (NIP-98)	http://

Suggested directions

1. Have the iOS credential import accept http:// for private/self-hosted
   relays, or gate the check on something other than the scheme.
2. Or let the relay trust X-Forwarded-Proto (opt-in env var), so operators
   behind a reverse proxy can present https:// consistently to all clients.
3. Either way, documenting the BUZZ_PAIR_RELAY_BIND_ADDR default and shipping
   the sidecar in deploy/compose would close deploy/compose: mobile pairing broken out of the box — bundle ships no buzz-pair-relay and relay 404s the legacy /pair fallback #2734.

Related

• deploy/compose: mobile pairing broken out of the box — bundle ships no buzz-pair-relay and relay 404s the legacy /pair fallback #2734 — deploy/compose ships no buzz-pair-relay; relay 404s the legacy /pair fallback
• Mobile: QR pairing fails at credential import for private/VPN-only relays (relay URL must be HTTPS + public host) #4198 — Mobile QR pairing fails at credential import for private/VPN-only relays

Happy to test patches on this setup.