Repository navigation
Closed-relay production defaults lock the desktop out of its own relay — no invite/token-mint path exists #2969
Description
Summary
With the production deploy/compose/.env.example defaults (BUZZ_REQUIRE_AUTH_TOKEN=true), the desktop's join flow demands an invitation token, but no command in the shipped tooling can mint one. A self-hoster following the official compose README cannot join their own relay from the desktop, even as an already-added member.
Environment
- Desktop: Buzz.app 0.4.26 (macOS, Tauri/WKWebView)
- Relay: official
deploy/composebundle, imageghcr.io/block/buzz:sha-0096d71@sha256:32a8c6aa8ca3617d767eb5743891f45d956c9cdbe161d244c8702a7645b64a78(v0.4.26, commit0096d710) .envleft at production defaults from.env.example:BUZZ_REQUIRE_AUTH_TOKEN=true,BUZZ_REQUIRE_RELAY_MEMBERSHIP=true,BUZZ_ALLOW_NIP_OA_AUTH=true
Steps to reproduce
- Deploy
deploy/composeper the README,.envat closed-relay defaults above. - Add the desktop identity's pubkey as a member:
./run.sh add-member <hex> --role admin. Confirmed viabuzz-admin list-members— row present. - Desktop → Add/join community → enter the relay
wss://URL. - Desktop shows "MEMBERSHIP REQUIRED / This relay requires an invitation. Ask a relay admin to add you as a member, then come back and try again" — displaying the npub of an identity that is a member (decoded and byte-compared against the admin row — identical).
- Relay logs during the attempt: HTTP bridge requests authenticated as that pubkey (signature verified, pubkey logged) →
403on/queryand/events.
What I found
buzz-admin --help at this commit offers only add-member, remove-member, list-members, generate-key, migrate, product-feedback, reconcile-channels — confirmed against the Command enum in crates/buzz-admin/src/main.rs. There is no mint-token/invite-creation command, and the desktop can't create an invite for a community it can't join. The buzz CLI authenticates fine with membership alone (NIP-42 path) — the token gate only bites the desktop's HTTP-bridge path. So with BUZZ_REQUIRE_AUTH_TOKEN=true (the shipped production default), the first desktop user of a fresh self-hosted relay does not appear to have a satisfiable join path through the shipped admin/desktop tooling.
Related: crates/buzz-cli/TESTING.md and crates/buzz-acp/README.md both still document a buzz-admin -- mint-token invocation for minting test credentials — that command doesn't exist anywhere in the current source (git grep for MintToken/mint_token across all .rs files returns nothing). Separate stale-docs issue, possibly the same removal that left this gap.
Workaround
Set BUZZ_REQUIRE_AUTH_TOKEN=false (keep BUZZ_REQUIRE_RELAY_MEMBERSHIP=true), recreate the relay. Desktop joins immediately; non-member keypairs are still correctly rejected (403 relay_membership_required, separately verified with a throwaway key).
Suggested fixes (any one resolves it)
- Ship a
buzz-admin mint-token/invite command - Have the desktop fall back to NIP-42 + membership when it holds no token
- Change the
deploy/compose/.env.exampledefault - At minimum, document the flag flip in the compose README
Related
- Self-host onboarding dead-ends: 'I already have a community' → 'I own the community' only offers Builderlab, never a relay URL #2816 (fixed via fix: self-host compose ownership, key import, owner onboarding #2824) routes self-hosters to the "enter relay URL" screen correctly — but that's a UI-routing fix. A member who reaches that screen via the now-fixed path will still hit this issue's lockout immediately after, since it's a separate backend auth-gate problem.
Activity
DanTup commentedon Jul 26, 2026
Isn't this what
RELAY_OWNER_PUBKEYis for in the.envfile? Set it to the public key from the desktop app?bokiko commentedon Jul 27, 2026
I don't think
RELAY_OWNER_PUBKEY=<desktop pubkey>changes this failure if the desktop pubkey is already a relay member in the same community. The closed-relay gate checks membership bycommunity_id + pubkey, not role (crates/buzz-db/src/relay_members.rs:31-38) — owner vs admin shouldn't matter for/query//events. If we want to rule out a host/community mismatch, I can re-run withRELAY_OWNER_PUBKEYset to the desktop key and capture the failing request's community.