Closed-relay production defaults lock the desktop out of its own relay — no invite/token-mint path exists

[bokiko]

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/compose bundle, image ghcr.io/block/buzz:sha-0096d71@sha256:32a8c6aa8ca3617d767eb5743891f45d956c9cdbe161d244c8702a7645b64a78 (v0.4.26, commit 0096d710)
• .env left 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

1. Deploy deploy/compose per the README, .env at closed-relay defaults above.
2. Add the desktop identity's pubkey as a member: ./run.sh add-member <hex> --role admin. Confirmed via buzz-admin list-members — row present.
3. Desktop → Add/join community → enter the relay wss:// URL.
4. 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).
5. Relay logs during the attempt: HTTP bridge requests authenticated as that pubkey (signature verified, pubkey logged) → 403 on /query and /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.example default
• 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.

[DanTup]

Isn't this what RELAY_OWNER_PUBKEY is for in the .env file? Set it to the public key from the desktop app?

[bokiko]

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 by community_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 with RELAY_OWNER_PUBKEY set to the desktop key and capture the failing request's community.