Skip to content

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

Open

Description

@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

Activity

  1. DanTup commented on Jul 26, 2026

    @DanTup

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

  2. bokiko commented on Jul 27, 2026

    @bokiko
    Author

    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.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions