[baxen]

Summary

Adds POST /operator/communities/invites, so a deployment's trusted operator (its account service) can mint an invite link on behalf of a community owner or admin. The website where people manage their communities never holds the owner's own key, so it can't call POST /api/invites (owner-signed NIP-98).

• Trust model: the same as /operator/communities/{archive,transfer}. A configured operator signs the request (NIP-98, payload-bound, replay-checked) and vouches only for which identity its signed-in caller is bound to (actor_pubkey). The relay decides that identity's authority from its own roster at mint time: owner or admin only, the same check /api/invites makes. Nothing the operator says about roles is trusted.
• Same invite: it mints through db.mint_relay_invite, with the same lifecycle gate and restriction check, the same ttl_secs/max_uses bounds and defaults (validate_mint_request), and the same response (minted_invite_json, extracted from /api/invites). The link is an ordinary https://<host>/invite/<code> that every client's join flow already claims.
• Archived, deleted and deleting communities return 404 (lookup_community_host only resolves active ones).

Request body (unknown fields rejected):

{ "community_id": "<uuid>", "actor_pubkey": "<64-hex>", "ttl_secs": 259200, "max_uses": 5 }

Errors keep the /api/invites text in error and add a stable code, so the operator can tell its own misconfiguration from the actor's refusal without matching on text:

Status	code	When
403	not_operator	the signer is not a configured operator
400	invalid_request	bad JSON, an unknown field, a bad pubkey, or out-of-range limits
404	community_not_found	unknown, archived, deleted or deleting community
403	not_owner	the actor isn't an owner or admin in the relay's roster
403	restricted	the actor is banned or restricted (invite_restricted)
503	unavailable	community writes are paused

This is an HTTP operator route rather than an event kind because it belongs on the existing operator plane (operator-signed, outside the event data plane), like the other operator community actions.

Stack (invite links on the Builderlab Communities page)

1. This PR: the relay route. It ships first.
2. The account service endpoint that calls it (private repo). Depends on this PR.
3. The website UI (private repo). Depends on 2.

Related issue

None found.

Testing

• New Postgres journey operator_mints_invites_only_for_relay_owners_and_admins (run against a freshly migrated local database):
  • An owner mints with the defaults. The URL, null max_uses and the 72h expiry match /api/invites.
  • A joiner claims the minted code through POST /api/invites/claim and becomes a member.
  • An admin mints with limits.
  • A banned admin is refused.
  • A member and an outsider get 403 with the same refusal text as /api/invites. The test pins each error's code.
  • Out-of-range ttl_secs and max_uses, an unknown field, a bad pubkey and a non-operator signer are all refused.
  • An unknown community and an archived community get 404.
• cargo test -p buzz-relay --lib -- --include-ignored api::invites api::operator: 78 passed and 2 timed out under heavy machine load. Both timeouts (claim_follow_up_survives_a_client_disconnect, temporary_listing_failure_is_recovered_for_each_admission_path) also pass on this branch when run on their own, as on main.
• cargo fmt and pre-push hooks (clippy) passed.
• Not yet done: a run against a local relay with curl, and a human check.

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-09T04:42:50.261344Z	0e560c3	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 66095e55985777dd84be140b328f0ee97af19ae9...8e3140dded19b8f9294612fbb7a85613ea4a6618.
A new review must complete for this exact range. When manual authorization
is required, a user with write access must comment exactly
@buzz-security-review 8e3140dded19b8f9294612fbb7a85613ea4a6618 to authorize a new review.
Any previous review applies only to its recorded range.

[wpfleger96]

🤖 Approving. The authorization model holds: the operator signature is checked the same way as archive and transfer, the owner/admin decision comes from the relay's own member list, and invites are created through the same mint_relay_invite, limits and response as /api/invites, with bans re-checked inside the transaction. The Postgres journey creates an invite and claims it end to end. Since the operator can already transfer any community's ownership, this route doesn't widen what an operator key can do.

Everything below is nonblocking:

• Role check race (inline): shared with /api/invites, so it's worth one fix for both routes.
• Access log (inline): refused requests are logged as successful authentications, and the log line doesn't name the community.
• Archive comment (inline): it overstates what the transaction re-checks.
• with_code vs coded_api_error (inline).
• Test gap: nothing exercises the unavailable code (community writes paused). Every other row of the error table is pinned by the journey.

[kazemek21]

Kyle reviewed this PR and the Nexus review-tracker notes. Approved with the following non-blocking concern.

[P2] Recheck the actor’s role inside the mint transaction

The roster lookup happens before mint_relay_invite opens its transaction, so an overlapping demotion or removal can still be followed by invite insertion. This is already covered by the existing role-check thread; I agree that checking owner/admin authority inside the shared mint transaction, under a lock that also serializes role changes, would cover both this route and /api/invites. Referencing that thread rather than adding a duplicate inline comment.

Posted by Codex (gpt-6.1-sol) on behalf of kylez

[kalvinnchau]

🤖 Review follow-up in 8e3140d: all four inline threads are addressed and resolved. For the test gap raised in the review body, operator_mint_rechecks_role_and_lifecycle_inside_the_mint now covers unavailable. It holds the deletion lock and an uncommitted quiescing fence, set up the way the deletion executor sets it, after the host lookup has passed. It then asserts 503 unavailable with no invite row. The operator invite, /api/invites, relay invite and admission Postgres tests pass locally, and CI is green on this head. The push dismissed the earlier approvals, so this needs re-approval.