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 always visible — hiding it when NIP-11 discovery is absent, invalid, or pending would lock an operator out of the only place to configure a manual origin. 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 — zero manual input on the happy path. The advertised origin is untrusted input: revalidated through AdminOrigin::parse, falling back to a manual field 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, role/source badges when authorized, honest copy for every probe state, manual origin under an Advanced disclosure.
• 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.
• 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 operator (pubkey + role) — Add is create-only: 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 badges; config-backed entries disable remove client-side.
• 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

Settings → Relay admin nav entry

Origin setup — Advanced disclosure open, idle state

Authorized console — OPERATOR/DB badge, 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 badges

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: 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.