feat(desktop): relay admin console for the /api/admin/v1 operator surface

[wpfleger96]

Adds a relay admin console under Settings — the single surface for relay-level operator work — replacing the previously unreachable moderation section. Operators authenticate with their own Nostr key over NIP-98 — no browser extension, no bearer token — to view deployment-wide moderation reports and product feedback, resolve/dismiss/escalate/reopen reports, update feedback status, and manage the operator/moderator staffing roster.

Nav reachability

The old moderation section id was defined in settingsSections but never wired into any group in settingsNavGroups, so the sidebar never rendered it — unreachable since #1617. This PR replaces it with a relay-admin section wired into the Communities nav group, pointing at the relay admin console, and drops the separate admin-console section id so a single surface owns relay-level trust & safety.

Relay admin console

The console is gated behind the relay OPERATOR/MODERATOR roles from #3777; every /api/admin/v1/* route returns 403 to anyone else. Community self-administration (community-members / Invites) and in-channel enforcement (the 9040–9043 signed commands) are a separate axis and are untouched. The previously-duplicate community report queue (ModerationQueueCard, moderationQueue.ts, and three dead hooks) was unreachable dead code and is deleted in its own commit; useBanMemberMutation and the rest of features/moderation/hooks.ts remain in use by the members sidebar and message menu.

The Relay admin nav entry is hidden when originSource === "none" (i.e. NIP-11 discovery has not yet run or returned no admin_api field and no manual origin has been saved). Once a valid origin is discovered or manually saved, the entry becomes visible. Auth still gates the panel itself; the nav entry is a door, not a credential.

Discovery and connection

On mount the console reads the connected relay's NIP-11 document for the optional admin_api field. When a valid origin is discovered it is automatically saved and probed — the panel renders immediately with no Save step required. Saving is only required for manual origin changes. The advertised origin is untrusted input: revalidated through AdminOrigin::parse, falling back to manual entry when absent or invalid. A saved manual origin always takes precedence over discovery.

Auth and transport (Rust, src-tauri/src/commands/admin/)

• AdminOrigin value object: validates scheme + host + optional port, rejects credentials/path/query/fragment; http:// only for loopback.
• AdminRoute closed enum: no IPC surface accepts arbitrary URLs, so the NIP-98-signed URL is byte-identical to the fetched URL.
• Dedicated no-redirect reqwest client as an SSRF guard: a relay 3xx is an error and the NIP-98 header never crosses origins.
• admin_probe signs GET /probe and returns a typed state (nip98Authorized / nip98Denied / tokenMode / disabled / notAdminApi / networkOrIntercepted). The response body is validated against the full relay contract — nip98Authorized only when the complete NIP-98 invariant holds, disabled only on a coherent disabled-mode body; any incoherent or unrelated JSON classifies as notAdminApi, so the console never fails open at the network boundary. Unknown fields are tolerated for forward compatibility.
• NIP-98 signing via AppState::signing_keys(), one retry on 401 with a fresh signed event; response size bounded by a Content-Length preflight and a streaming byte counter; per-pubkey origin storage with atomic 0o600 writes.

Console UI (TypeScript, src/features/admin-console/)

• AdminConsoleSettingsCard: discovery + probe flow, honest copy for every probe state, manual origin under an Advanced disclosure at the bottom. The role (operator/moderator) is rendered in the connection status line as plain text ("Connected as operator") — no badge-shaped elements above the tab row. The origin provenance (relay config / database) appears inside the Advanced card as small muted text. Section title changed to Admin.
• AdminConsolePanel with Reports / Feedback / Staffing tabs (Staffing gated on role === "operator"); reports and feedback grouped by community for cross-community triage.
• Reports: always requests scope=all so the existing resolve/cancel/reopen controls can reach every status (open, processing, resolved, dismissed, escalated). The relay's omitted-scope default is escalated-only (the platform-safety backstop); scope=all is explicit and scoped to this console. Full action matrix per target_kind (event → delete/kick/ban/timeout/dismiss/escalate; pubkey → ban/timeout/dismiss/escalate; blob → dismiss/escalate); kick is suppressed when the report carries no channelId. A processing row stays navigable — enforcement state lives in the detail view. A failed action (always pre-mutation) offers a single Cancel & reopen via POST /reports/{id}/cancel with {actionId} fencing; there is no client-side retry. pending/enforcing actions belong to the relay recovery worker and offer no button; a 409 reloads detail. Lists refetch on back-navigation after a mutation.
• Report failure UX: reportErrorMessage() strips HTTP status prefixes and surfaces the relay's own error reason in the toast (e.g. relay returns "400: you cannot report this content" → toast shows "you cannot report this content"). Self-report blocking UI removed — the relay has no self-report gate, and the failure was purely client-side error surfacing.
• Reason audience disclosure: the Reason (optional) field shows exact copy under the input based on selected action — Delete discloses that reason is sent verbatim to the affected user and posted publicly in the room; Kick/Ban/Timeout disclose affected-user only; Dismiss/Escalate disclose reporter only. These mirror the actual relay notice paths.
• Enforcement history: the report detail carries the governing action even after the report leaves processing — a report enforced then reopened is open yet still shows its succeeded action as executed history alongside the resolve form; a reopen does not un-happen a ban. The resolve form gates on open status alone.
• Reopen: terminal reports (resolved/dismissed/escalated) can be returned to open for re-triage via POST /reports/{id}/reopen. Reopen never reverses applied enforcement, and the copy says so.
• Feedback: list, detail, and status control (new/reviewed/archived) with a generation-fenced attachment viewer. A purged source community severs provenance to null rather than deleting the row; severed rows bucket under a "source community removed" heading.
• Staffing: Add is create-only with display names resolved via useUsersBatchQuery and npub cross-fade on hover (HoverStaffingIdentity). An entered key that already appears in the authoritative roster (config, owner-fallback, or DB) is rejected locally with an inline duplicate-key message and no request is issued; a config-backed principal targeted by remove returns the relay's 409 Conflict. Roster with config/owner_fallback/db source labels; config-backed entries disable remove client-side. In-place role change via <select> calling putAdminOperator; read-only badge for config-managed entries.
• Timeout expiry: useTimeoutState clears the store when derived state is INACTIVE but the store is still active; the 1s tick interval is scoped to entries with a known expiresAtMs so that the countdown and automatic clearing work reactively without a permanent rerender loop for null-expiry entries. useMembersSidebarModeration gets a 1s nowMs interval so moderationStateByPubkey re-runs reactively on expiry.
• Mutations confirm via sonner toasts; failures surface the relay's parsed error message, not raw JSON. tokenMode and disabled auth modes render read-only.

Mutation idempotency

Resolve and reopen carry a per-attempt requestId. On first submit the whole command ({requestId, action, reason, expirationSecs}) is frozen; after an ambiguous failure (409, 5xx, transport error, truncated response) the snapshot is retained, action/reason/duration controls are locked, and the retry sends the exact same payload byte-for-byte. A definitive pre-commit rejection (non-409 4xx with bodyComplete: true) discards the snapshot, unlocks controls, and the corrected submit uses a fresh payload. On success the toast derives from the authoritative AdminReportResolution (activeAction.action when present; otherwise status for decision-only outcomes) — never from the mutable form selection.

The native commands reject with a typed AdminMutationError carrying the relay's HTTP status (relayStatus, null when no verdict exists) and a bodyComplete flag that is true only when the full response body was read.

Deferred

AdminConsoleStaffingTab.tsx renders non-409 staffing mutation errors via raw e.message rather than adminErrorMessage(e) (the 409 branches and the Reports/Feedback handlers already use friendly copy). Pre-existing, error-presentation only — no effect on auth or authorization.

Related: #3777 (relay OPERATOR/MODERATOR role model + NIP-98 auth + admin_api NIP-11 advertisement — provides the runtime and the discovery field this console consumes)
Related: bb-public#339 (Phase 4 rollout config)

Screenshots

Captured headless at 197f0ba0c against the mock bridge (1280×720).

Setup

Origin setup — Advanced disclosure open, idle state

Authorized console — all three tabs

Reports

Reports queue — open, processing, resolved across two relay groups

Open report detail — reporter, target, message snapshot, resolve form

Processing report — PROCESSING/HARASSMENT, ban enforcing state

Resolve form — Delete selected, audience disclosure copy

Resolved report — enforcement history block

Feedback

Feedback list — community grouping with status badges

Feedback detail — mutable status control (operator mode)

Feedback detail — passive status badge (read-only/disabled mode)

Staffing

Staffing roster — config/owner_fallback/db source labels

Add form — new pubkey filled, ready to submit

Duplicate rejection — inline error for existing principal

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested

• [P1] Do not auto-probe an unrestricted relay-advertised origin — desktop/src-tauri/src/commands/admin/mod.rs:938-949

  admin_api is explicitly untrusted NIP-11 data, but discovery applies the same permissive policy as manual operator input: HTTP loopback is accepted and every HTTPS host is accepted. Both the nav resolver and settings card then probe that value automatically without confirmation (hooks.ts:45-56, AdminConsoleSettingsCard.tsx:303-316). A malicious connected relay can therefore make the native client contact http://localhost:<port> (the client pins localhost to 127.0.0.1) or HTTPS private/link-local targets. If the target returns 401 WWW-Authenticate: Nostr, the app sends it a fresh app-key signature, adding a signing oracle and pubkey-ownership disclosure to the SSRF. Separate advertised-origin validation from manual configuration: do not auto-probe loopback/private/link-local advertised destinations, and account for DNS resolution/rebinding, or require explicit operator confirmation before any cross-origin probe. Keep the loopback HTTP carve-out only for manual origins.

• [P2] Actually make disabled-auth mode read-only — desktop/src/features/admin-console/AdminConsoleSettingsCard.tsx:397-480

  disabled currently renders the same AdminConsolePanel as an authorized principal, with only the staffing tab hidden. The report resolve/reopen/cancel controls and feedback status controls remain enabled, although the related relay contract intentionally rejects every mutation in disabled mode with 403. This contradicts the PR’s stated read-only behavior and presents controls guaranteed to fail. Pass a read-only capability into the panel and suppress/disable all mutation affordances when the probe result is disabled.

The command registration/API seams, identity and async fencing, report lifecycle/idempotency paths, attachment cleanup, navigation, staffing gating, and legacy-surface removal were otherwise coherent in this read-only diff review. GitHub currently exposes only a passing DCO check for this head; PR code was not executed locally under the automation trust policy.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Two security/resource-boundary blockers remain on this head:

1. Do not auto-probe a relay-advertised admin origin under the manual-origin trust policy. The NIP-11 admin_api value is explicitly untrusted, but admin_origin_from_nip11 passes it through the same AdminOrigin::parse policy used for operator-entered values. That policy accepts loopback HTTP and unrestricted HTTPS hosts. Both the navigation resolver and the settings card then automatically probe the advertised origin, and the probe performs a native GET before sending a fresh NIP-98 signature when the target replies with 401 WWW-Authenticate: Nostr. A malicious connected relay can therefore advertise http://127.0.0.1:<port> / localhost (the client explicitly pins localhost to 127.0.0.1) or an HTTPS private/link-local target and trigger zero-click native SSRF; a cooperating target also gets an attacker-triggered signing oracle and proof of the app pubkey. This is not hypothetical policy drift: mod_tests.rs currently asserts that a loopback origin from NIP-11 is accepted and returned for automatic probing. Please separate advertised-origin validation from explicit manual configuration: never auto-probe loopback/private/link-local advertised destinations, and account for DNS rebinding, or require an explicit operator confirmation before any cross-origin probe. Keep loopback HTTP only for a manually entered origin.

2. Bound attachment preview work across the whole feedback item, not only per response. parseImetaAttachments accepts and returns every valid imeta tag, FeedbackDetail mounts an AttachmentViewer for every result, and each image/* viewer immediately starts its own native fetch. The Rust command caps each response at 10 MiB, but there is no attachment-count, aggregate-byte, or concurrency bound. The relay’s feedback ingest bounds serialized tags to 64 KiB but does not cap the number of imeta entries, so an admitted feedback event can fan out many simultaneous image reads and retain their blob URLs until navigation. The existing test explicitly blesses multiple tags but covers no aggregate/concurrency ceiling. Please impose a small count plus aggregate-byte budget before rendering/fetching, avoid unbounded parallel auto-load, and add a regression showing excess attachments are not requested.

The closed route construction, exact-body NIP-98 binding, no-redirect client, mutation idempotency/recovery fences, and identity/origin React state fences otherwise held in this read-only diff review. GitHub currently exposes only the passing DCO check for this head; I did not execute PR code under the automation policy.

Accidental duplicate from a concurrent automated recovery. The earlier marked review 5032499207 is authoritative.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested

• [P1] Do not automatically probe an unrestricted relay-advertised origin — desktop/src-tauri/src/commands/admin/mod.rs:938-950

  admin_api is untrusted NIP-11 data, but discovery runs it through the manual-entry policy, which accepts loopback HTTP and every HTTPS host (origin.rs:64-90). With no saved origin, both the settings surface and navigation resolver automatically probe the advertised value (AdminConsoleSettingsCard.tsx:284-316, hooks.ts:41-56). The native probe first GETs that attacker-selected destination and, if it answers 401 WWW-Authenticate: Nostr, sends a fresh NIP-98 signature to it (mod.rs:160-215). A malicious or compromised connected relay can therefore target localhost, private/link-local addresses, or an attacker hostname that resolves there; no-redirect handling does not constrain this initial destination. Separate advertised-origin trust from explicit manual configuration: require an explicit confirmation or prove/bind the advertised endpoint to the connected relay, and reject resolved loopback/private/link-local/reserved targets with rebinding-safe connection handling. Add advertised-origin tests for loopback, RFC1918/link-local, and a public hostname resolving privately. The existing discovery test currently blesses automatic loopback probing (mod_tests.rs:872-916).

• [P1] Bound attachment fan-out across the feedback item — desktop/src/features/admin-console/AdminConsolePanelHelpers.tsx:243-272

  parseImetaAttachments returns every valid imeta tag, FeedbackDetail mounts every result (AdminConsoleFeedbackTab.tsx:420-465), and each image/* viewer immediately starts its own native fetch on mount (AdminConsoleFeedbackTab.tsx:215-224). The 10 MiB native cap is per response, with no attachment-count, aggregate-byte, or concurrency ceiling. A single admitted feedback event can therefore trigger many simultaneous native reads and retain all resulting blobs until navigation. Impose a small item-wide count/aggregate budget and bounded fetch concurrency (or explicit loading), then add a regression proving excess attachments are not requested.

• [P2] Keep disabled-auth mode read-only as documented — desktop/src/features/admin-console/AdminConsoleSettingsCard.tsx:470-480

  A coherent disabled probe mounts the same panel as an authorized principal without passing a read-only capability. Report resolve/reopen/cancel and feedback status controls therefore remain live, although the relay rejects mutations in this mode. This contradicts the documented contract that disabled mode renders feedback status read-only (docs/admin/README.md:267-276) and the PR description. Pass the auth capability into the panel and hide or disable every mutation affordance while preserving reads.

• [P2] Expose the selected feedback status programmatically — desktop/src/features/admin-console/AdminConsoleFeedbackTab.tsx:352-375

  The current status is communicated only through button styling (variant and ring classes). The three ordinary buttons have no aria-pressed, radio semantics, or textual current-value output, so a screen-reader user cannot determine the active status before changing it. Add a programmatic selected state and assert that semantic contract rather than only the visual class.

The closed route construction, exact URL/body NIP-98 binding, no-redirect client, response caps, identity/origin async fences, report lifecycle and request-ID recovery contract, role-gated staffing, and legacy moderation-surface removal were otherwise coherent in this read-only exact-head review. Desktop, Rust, build, and desktop integration checks are green; PR code was not executed locally under the automation trust policy.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested at exact head 63db828a09b270239d5e56bf82c3f5e8468cea43 and exact base a3730784fc851bb1125b40cca9b0a30788a293c1.

P1: require confirmation before removing an operator

The Staffing trash button calls handleRemove directly, which immediately invokes deleteAdminOperator (desktop/src/features/admin-console/AdminConsoleStaffingTab.tsx:105-121,203-224). One stray click therefore deletes a DB-backed operator, potentially the acting operator, without a confirmation, target/role recap, or undo. That can remove administrative access and may require another operator or out-of-band configuration to recover.

Put this destructive authorization change behind an explicit confirmation dialog. Make self-removal especially clear, and add cancel/confirm behavior tests. The current event suite only checks whether staffing controls are rendered; it does not exercise removal confirmation.

P2: recover when the active Staffing tab becomes unauthorized

activeTab persists independently of role (AdminConsolePanel.tsx:832-843). If the same mounted panel changes from operator to moderator/unknown while Staffing is selected, the tab button disappears and the content is suppressed (AdminConsolePanel.tsx:859-887), leaving an empty panel with no selected visible tab. Reset an invalid active tab to Reports when role/capabilities change and cover that prop transition.

The previous advertised-origin SSRF, attachment fan-out, disabled-mode mutation, and feedback-status accessibility blockers are otherwise closed at this head. Relay discovery is now prefill-only until an operator explicitly saves the origin; item-wide attachment limits, read-only mutation gating, and aria-pressed are present. Hosted substantive checks are green. This was a read-only review of immutable GitHub source/diffs; no PR code was checked out or executed.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: four P2 desktop integration defects.

Reviewed head 662db64518d72ba96a3e1726765baae71d203644 against exact base a3730784fc851bb1125b40cca9b0a30788a293c1.

The product boundary is a relay-operator/moderator console, distinct from community-owner administration. Discovery must remain untrusted until the operator confirms the origin; the relay remains authoritative for roles, report transitions and public enforcement notices. The four inline findings concern unreachable manual setup, non-escalated report access, undisclosed public-reason semantics, and retries that claim the wrong action succeeded. They do not require changing the relay's intentional escalated-only default or weakening discovery trust.

Coverage: Settings navigation/discovery and identity/origin transitions; native origin, route/auth, bounded-body/error plumbing; report list/detail/resolve/reopen/cancel and idempotency; feedback attachments/status; staffing confirmation/role changes. Compared client routes and closed action/status/role sets to exact-head relay producers. The previous staffing-confirmation, hidden-active-tab and unconditional request-ID-clearing defects are fixed in this head and are not repeated. Community signed-command enforcement and mobile/web UI are not changed by this desktop PR; they were not independently reviewed as whole features.

Validation was source/diff and existing-test inspection only under the read-only automation policy. Key source blobs were checked against the pinned Git tree. No checkout, build, test execution or live relay/app run; this is not a runtime pass.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested at head 0b972699c51d010ebdf349498fbe6cbc40468d16, base 4952f5810290d00a1dd9413235b39e9a7154acf6.

P2: Do not let “Add operator” silently demote an existing operator

AdminConsoleStaffingTab.tsx:97–105 sends an immediate role upsert, while the form says “Add operator” / “Add” and defaults to moderator (lines 81, 195, 229). With DB operators A and B, paste an existing operator key into this form and leave the default role: clicking Add changes that account to moderator without a role-change confirmation. If A submits their own key, A loses roster-management access and cannot reverse the change themselves. The new Remove confirmation and self-removal warning protect DELETE only, not this PUT path.

This is confirmed by the actual producer: crates/buzz-relay/src/api/admin/mod.rs:1037–1055 forwards the role to crates/buzz-db/src/store/relay_operators.rs:134–145, whose conflict branch updates the existing role. The last-operator guard at lines 169–174 deliberately permits the demotion when another operator exists. This is accidental individual access loss, not a claim that the deployment can lose its last operator.

Exit criterion: distinguish adding a new principal from modifying one. Reject an already-present key in Add, or explicitly present the existing→requested role change and confirm demotions, including a self-access warning. Keep relay authority and last-operator protection unchanged. Add a real form/IPC regression with two operator rows proving that an existing-key submission does not silently demote, while adding a new moderator still works. The existing event tests cover DELETE confirmation and synthetic role-prop changes, not this PUT submission. This was missed in earlier review rounds; it is not a regression introduced by the four latest fixes.

P2: Accept the relay’s supported .localhost manual origin

desktop/src-tauri/src/commands/admin/origin.rs:123–130 recognizes only bare localhost and loopback IPs. Consequently AdminOrigin::parse("http://admin.localhost:3000") takes the non-loopback HTTP rejection at lines 64–74, so an operator cannot save the repository’s local admin origin. This is an existing producer contract, not a proposed new deployment: Justfile:498 defaults BUZZ_ADMIN_HOST to admin.localhost:3000, and relay api/admin/auth.rs:109–155,534–538 deliberately advertises and verifies HTTP for every .localhost name. Substituting 127.0.0.1 is not equivalent: admin routing checks the configured Host exactly (auth.rs:99–106).

Exit criterion: support explicit manual entry of the relay’s loopback-name contract, preserving the configured hostname for Host/NIP-98 signing and ensuring it connects as loopback. Add a regression for the real http://admin.localhost:3000 value. Do not relax the separate prohibition on automatically probing untrusted advertised internal origins. This is a missed compatibility path, not a regression in the four latest fixes.

Non-blocking P3: Preserve status in read-only feedback detail

AdminConsoleFeedbackTab.tsx:497–507 hides the only detail status representation when canMutate=false; FeedbackFields (lines 340–358) has no passive status row. A disabled-auth reader can see a reviewed/archived badge in the list, then loses that information when opening detail. A passive status badge would preserve the read-only contract without adding mutation controls. This is not an additional merge gate.

Verified scope and limits

All four findings from review 5070332066 are closed: manual setup remains reachable without discovery; scope=all reaches the native query and relay while retaining the relay’s escalated-only default; reason-audience copy matches the actual notices; resolve retries freeze the command and derive success copy from the relay response. DELETE confirmation and hidden-Staffing reset remain present.

The integrated review traced Desktop Settings/Reports/Feedback/Staffing through native admin transport and exact-head relay/DB producers, including authorization, report/action closed sets, mutation retries, capability transitions, and attachment budgets/lifetimes. Community moderation, mobile/web operator UIs, and deployment configuration are outside this Desktop delivery. Reopen replay preserves the original audit and cannot reopen a later resolution again; its editable optional reason is not being promoted into an enforcement blocker. Raw Staffing error presentation remains the declared follow-up. The proposed blanket private-address prohibition on signed requests is not a blocker: the agreed boundary permits manually trusted internal origins after explicit Save, and discovery does not probe its advertised destination.

Source-only validation: immutable GitHub source/diffs and existing regression tests were inspected; key evidence blobs were verified against the pinned Git tree. No PR checkout, build, test execution, or live app/relay run. This is not a runtime pass.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Review clear: prior blockers resolved

Reviewed head 21f34f0138a4e00782f914d28a90346b994b650c against base 42aeb1571cc1f1ed4d73f05b420474be970021ab, including the corrections since review 5073088157. No remaining blocking finding in the reviewed paths and agreed delivery contract.

• Staffing: Add now requires a loaded roster and rejects normalized existing keys before PUT. The actual form/IPC regression checks zero PUTs for an existing operator and a successful new-moderator add with roster refresh. This closes the demonstrated accidental-demotion path; the API remains an upsert, so this is snapshot-based duplicate prevention, not atomic server-side create-only behavior.
• Manual localhost: http://admin.localhost:<port> is accepted and pinned to loopback without rewriting the hostname used for Host or NIP-98 signing. The added production-client/probe test inspects the signing URL and both wire Host headers. Discovery still requires explicit Save before contacting an advertised admin origin.
• Integration: Read-only feedback detail now shows its status. The “Relay admin” rename preserves the old moderation URL token in route validation and AppShell. Report scope, frozen resolve retries, cancel/reopen semantics, and operator/moderator authorization remain consistent with the previously reviewed contract.

Non-blocking follow-ups: the staffing regression does not explicitly exercise uppercase/whitespace, self-key, or pending/failed roster loading. Discovery’s reserved-domain check omits .localhost, so failed system DNS can allow a loopback prefill; explicit Save still prevents automatic access. These do not reopen the agreed fixes.

Validation: immutable source/diff and existing-test inspection only, with independent native and staffing/feedback reviews integrated. No checkout, builds, tests, or PR-code execution; no runtime-pass claim. Separate community moderation, mobile/web operator UX, deployment configuration, and unrelated merged-main changes were outside this corrective review. This is a COMMENTED review, not approval.