fix(relay): close community ban gaps across audio, agents and HTTP

[wpfleger96]

🤖 Community bans had gaps. Audio sockets never checked them: the audio join path didn't look up ban state, and a ban closed only the member's root sockets, so a banned member could join a huddle or stay in one. An agent's access comes from its owner, but the ban and timeout checks only looked at the pubkey that signed the event. Several write paths returned before those checks ran, admission could miss a ban that landed mid-AUTH, and removing or losing a member left live sockets open. This PR closes those gaps.

Audio

• handlers/auth.rs: the root socket's ban lookup, including the NIP-OA owner cascade and fail-closed DB handling, is community_ban_outcome. Root auth and audio join both call it, so the two checks can't drift apart.
• audio/handler.rs: audio join runs the ban check after the write-free channel membership check and before any huddle lease or durable write. A ban is refused with AuthorizationDenied and a DB error with AuthorizationUnavailable. With no FI assertion, the refusal is the root route's text (blocked: you are banned from this community / error: internal error checking restriction state).
• state.rs: CommunityConnectionControl holds the authenticated pubkey. CommunityConnectionRegistry::disconnect_pubkey closes bound audio sockets for one pubkey in one community with a 1008 access revoked close. AppState::disconnect_pubkey_local closes everything a pubkey has open in a community on this pod (root and audio); the clusterwide disconnect and the conn-control Redis subscriber in main.rs both use it, so remote pods close audio sockets too. Root sockets are still closed through ConnectionManager, so nothing is closed twice. A socket that proved a NIP-FI identity instead gets the standard NIP-FI denial (the restricted frame, then 1008 authorization denied), and a ban never overwrites a close reason already chosen.

Behavior

• Owner restrictions carry to agents. restriction_state folds in the restriction row of the agent's owner (users.agent_owner_pubkey) at read time. Nothing is copied onto the agent, so unbanning or un-timing-out the owner restores the agent immediately. Every hot-path caller (AUTH, ingest, audio, HTTP) picks this up.
• Admission is fenced against a concurrent ban. Root AUTH and audio admission bind the proven pubkey to the socket first, then make the final ban and relay-membership decision (handlers::auth::final_admission_denial), then refuse if a disconnect already cancelled the socket. A ban or removal whose disconnect ran before the bind is visible to those fresh reads; one that runs after it finds and closes the bound socket. Both reads come from the writer, never the bounded-stale replica, so a removal that committed before the bind cannot be undone by a lagging replica. Both fail closed, and the check covers a delegated agent's owner. Each admitted socket records the agent's owner, from the NIP-OA tag or the stored link.
• Agents are always linked to their owner before admission. Root AUTH and audio both record users.agent_owner_pubkey for a NIP-OA agent before admitting it, and refuse admission (error: internal error recording agent owner) if that write fails, because revoking the owner finds the agent's sockets through that link.
• Revoking live access covers agents without a database read. AppState::revoke_live_access sends one clusterwide disconnect that closes, on every pod, each root and audio socket in the community whose principal or recorded owner is the target. An agent socket admitted before its owner link existed carries no recorded owner, so recording an owner for the first time (materialize_nip_oa_owner, the single writer used by root AUTH, audio admission and HTTP NIP-OA) closes that agent's ownerless root and audio sockets clusterwide; they reconnect with the owner attached. That disconnect skips owner-bound sockets. Admission with a NIP-OA owner records it on the socket before binding the pubkey, so the socket survives its own link; admission without one binds the pubkey first and then reads the stored owner, so a concurrent link either closes the socket or is seen by the read. A users.agent_owner_pubkey sweep still runs as a secondary path; if its lookup fails, the error is returned and there is no retry task. The kind-9040 ban, the report-action ban (left non-terminal so recovery re-runs it), relay-admin removal (9031), and NIP-43 self-leave all use it and report an incomplete revoke instead of claiming success. Each revokes right after its change commits; the ban no longer waits on its audit insert, whose error is still returned.
• NIP-43 self-leave works over WebSocket. Kind 28936 is in the ephemeral range, so handle_event used to fan it out and answer OK true without removing membership. It is now routed to ingest; no other ephemeral kind changes.
• The write gate runs before every kind-specific branch. enforce_write_restriction runs ahead of command routing (DM open, DM add member, DM hide, workflow definitions and triggers, approvals), product feedback, reports, and moderation or relay-admin commands. Ephemeral events and agent observer frames return before ingest in handle_event, so they go through the same gate there.
  • A ban exempts nothing.
  • A timeout admits only reports (kind 1984), unban (9041) and untimeout (9043). A timed-out admin cannot send relay-admin commands (9030–9033) until the timeout ends.
• HTTP refuses banned principals. enforce_relay_membership runs a ban check after the membership decision, including on open relays: 403 blocked: you are banned from this community for a ban, 503 for a failed lookup. Media upload, media GET/HEAD and Git transport keep that 503 instead of reporting it as "not a relay member": in NIP-FI Enforce mode they send the canonical AuthorizationUnavailable response (text/plain; charset=utf-8, authorization unavailable\n), and in Off mode each keeps its legacy unavailable response. Media storage failures are not reclassified. Git transport checks membership and then runs its own ban check once per request. The NIP-OA owner is resolved from x-auth-tag when present. HTTP checks bans only: a timeout blocks writes, HTTP writes already reach the ingest gate, and reading stays allowed under a timeout.

Unchanged by design: a lost Redis fan-out can leave another pod's socket open until it reconnects, and there is no recurring ban recheck on open sockets.

Path table

Path	Category	Ban check
Root WebSocket AUTH and audio admission, including NIP-OA owner binding	community admission	final fenced check after bind; owner link required
POST /events, /query, /count (bridge.rs)	community HTTP	existing enforce_relay_membership caller
GIF search and POST /gifs/share (gifs.rs), media upload and fetch (media.rs), workflows (workflows.rs)	community HTTP	existing caller; media keeps 503 on lookup failure
Git transport (git/transport.rs), git settings (git/settings.rs)	community HTTP	existing caller; transport keeps 503 on lookup failure
GET /moderation/reports, /moderation/audit, /moderation/restricted	community HTTP	newly covered
POST /api/invites (invite mint)	community HTTP	newly covered
NIP-43 self-leave (WebSocket and POST /events, both via ingest)	roster change	revokes live access like admin removal
Invite claim, accept-policy, /api/join-policy*	pre-membership invite and policy flows	none; ban state is checked when the caller authenticates
/, /info, /.well-known/nostr.json, /health, /_liveness, /_readiness	public metadata and health	none
/hooks/{id}	secret-authenticated webhooks	none; no community pubkey
/operator/*, /api/admin/v1, /internal/git/policy	operator, admin and internal routes	none; separate auth plane
/_mesh/demo/echo	demo only (mesh plus mesh_demo_echo)	none

Known limits

• Cross-pod closure depends on the Redis fan-out; the tests prove the pod-local close by principal and recorded owner.
• Live delivery to existing subscriptions depends on the disconnect. Events are not rechecked one by one.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 24c1e702a68c7b1623f4a33dd2745a39b0597098...32b22fc09f923742792e31f61d577323592e20a8.
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 32b22fc09f923742792e31f61d577323592e20a8 to authorize a new review.
Any previous review applies only to its recorded range.

[bradseiler]

Approved at Brad Seiler’s request based on the delegated code review of 76bca4a, which reported no actionable findings in the ban-enforcement and revocation changes. Validation limits: selected local tests passed, but PostgreSQL-backed cases were skipped and PostgreSQL/Redis behavior was not exercised end-to-end locally. This approval is not a clean full-suite or live-local sign-off; required CI checks still need to pass.