Skip to content

fix(compose): wire buzz-pair-relay so mobile QR pairing works - #3875

Open
Chessing234 wants to merge 7 commits into
block:mainfrom
Chessing234:fix/compose-pairing-relay
Open

fix(compose): wire buzz-pair-relay so mobile QR pairing works#3875
Chessing234 wants to merge 7 commits into
block:mainfrom
Chessing234:fix/compose-pairing-relay

Conversation

@Chessing234

Copy link
Copy Markdown
Contributor

Summary

  • Stand up the buzz-pair-relay sidecar in deploy/compose (using entrypoint, not command, so Compose does not append args to buzz-relay).
  • Advertise BUZZ_PAIRING_RELAY_URL in NIP-11 and proxy /pair* through Caddy so membership-enforcing self-hosts stop 404ing on legacy /pair.
  • Document TLS vs direct-port URL shapes in .env.example, README, and run.sh help.

Fixes #3842

Test plan

  • cd deploy/compose && cp .env.example .env (fill CHANGE_ME) and ./run.sh config succeeds with BUZZ_PAIRING_RELAY_URL set
  • BUZZ_COMPOSE_TLS=true ./run.sh start brings up pairing-relay healthy; Caddy /pair reaches it
  • Desktop/mobile QR pairing completes against the compose stack without HTTP 404
  • Without Caddy, pairing still works when BUZZ_PAIRING_RELAY_URL points at the published :5000 port

Made with Cursor

Membership-enforcing relays need a pairing sidecar; without it mobile/desktop
QR pairing 404s on the legacy /pair path.

Signed-off-by: Taksh <takshkothari09@gmail.com>
Point clients at the sidecar URL instead of inferring a broken /pair path
from NIP-43 membership advertisement alone.

Signed-off-by: Taksh <takshkothari09@gmail.com>
TLS installs terminate on Caddy; route pairing traffic to the sidecar before
the catch-all reverse_proxy to the main relay.

Signed-off-by: Taksh <takshkothari09@gmail.com>
Give operators a copy-pasteable NIP-11 pairing URL for both Caddy and
direct-port deployments.

Signed-off-by: Taksh <takshkothari09@gmail.com>
Call out the TLS vs non-TLS URL shapes so self-hosters do not ship a
membership relay that advertises a dead pairing path.

Signed-off-by: Taksh <takshkothari09@gmail.com>
Avoid racing /pair traffic against a sidecar that is still binding its
listen port on first boot.

Signed-off-by: Taksh <takshkothari09@gmail.com>
Operators reading ./run.sh help should see how TLS vs direct-port pairing
URLs differ before they open .env.example.

Signed-off-by: Taksh <takshkothari09@gmail.com>
@Chessing234

Copy link
Copy Markdown
Contributor Author

@tlongwell-block @wesbillman @wpfleger96 mind taking a look when you get a chance?

@Tony-ooo

Tony-ooo commented Aug 7, 2026

Copy link
Copy Markdown

Confirming this from a production self-host: I've been running the buzz-pair-relay sidecar on ghcr.io/block/buzz:main since Aug 4, and the shape this PR proposes is exactly what works in practice.

Verified working snippet:

pair:
  image: ${BUZZ_IMAGE:-ghcr.io/block/buzz:main}
  entrypoint: ["/usr/local/bin/buzz-pair-relay"]
  environment:
    BUZZ_PAIR_RELAY_BIND_ADDR: 0.0.0.0:5000
  ports:
    - "5000:5000"
  restart: unless-stopped
  networks:
    - buzz-net

Notes that line up with this PR:

  • entrypoint (not command) is the right call — with command, Compose appends args to the buzz-relay binary and the sidecar never behaves as a pairing relay.
  • The stock compose Caddyfile only routes to relay:3000, so /pair* 404s unless the sidecar is on a direct port or Caddy adds the handle_path /pair* route. The Caddyfile change here closes exactly that gap.
  • Set BUZZ_PAIRING_RELAY_URL=wss://<domain>/pair in .env so NIP-11 advertises the pairing endpoint.

Thanks for landing this — it makes compose self-hosts work out of the box for mobile pairing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

2 participants