[Admin Console]: Extend relay operations with NIP-66 insights and operator workflows

[Ferryx349]

Summary

#669 establishes the NIP-66 relay-monitor foundation: shared DNS/TLS/WebSocket/NIP-11 probes, a monitor worker, standard Nostr event publishing, and an admin Network Health view.

This follow-up extends that foundation into an operator platform: deeper NIP-66 measurements, mirror and worker visibility, NIP-05 and storage operations, auditability, diagnostics, and alerting.

Important constraint

Probing a relay’s public URL from its own process verifies public URL configuration, DNS, TLS, and routing from that network location. It does not prove reachability from an independent external network.

NIP-66 events and the admin UI must identify the monitor location/identity clearly and must not treat one monitor as authoritative. Clients should aggregate results from multiple monitors, as required by NIP-66’s trust model.

Goals

• Give relay operators actionable health data without SSH, SQL, or manual DNS/TLS commands.
• Publish richer standards-compatible NIP-66 relay discovery data.
• Correlate advertised relay behavior (NIP-11) with measured behavior.
• Make existing Nostream subsystems—mirroring, NIP-05 verification, retention, and NIP-45 COUNT—visible and operable.
• Preserve safe defaults: admin disabled by default, secrets redacted, and explicit audit trails for mutations.

Proposed work

Phase 1 — Full NIP-66 monitoring

• Add rtt-read probe: measure subscription/request response latency.
• Add rtt-write probe: measure accepted write latency using a dedicated monitor identity.
• Add NIP-42 authentication capability detection where applicable.
• Publish richer kind 30166 events:
  • d normalized relay URL
  • rtt-open, rtt-read, rtt-write
  • n network type (clearnet, tor, i2p)
  • NIP-11-derived N, R, k, and relay metadata where reliable
  • NIP-52 g geohash for monitor location, only when explicitly configured
• Publish kind 10166 monitor announcements with frequency, check types, and per-check timeouts.
• Bootstrap the monitor identity with kind 0 profile and kind 10002 relay list, as recommended by NIP-66.
• Add NIP-11-versus-probe mismatch warnings:
  • advertised vs observed authentication requirement
  • advertised NIPs/limits vs observed protocol behavior
  • configured public URL vs actual probe target

Phase 2 — Admin Network Health operations

• Add probe history storage with bounded retention.
• Add GET /admin/network-health/history.
• Add optional authenticated manual probe trigger:
  POST /admin/network-health/probe.
• Add Network Health history charts and failure timeline.
• Display DNS records/TTL, TLS issuer/expiry, RTT measurements, network type, NIP-11 metadata, and mismatch warnings.
• Add nip66.* settings-editor support:
  enabled state, targets, interval, timeout values, monitor identity reference, cache TTL, and retention.
• Hot-reload safe monitor settings where possible; clearly mark restart-required values.

Phase 3 — Mirror, worker, and data operations

• Monitor relay URLs in mirroring.static[].
• Add Mirror Health panel:
  connection state, last successful connection, reconnect count, last received event, and lag where measurable.
• Add Worker Operations panel:
  maintenance, mirroring, relay-monitor status, last run, failures, and restart metadata.
• Add NIP-05 Verification panel using existing verification records:
  search/filter, verification age, failure count, and manual re-verification.
• Add Storage dashboard using existing NIP-45 COUNT support:
  event counts by kind and time range, retention impact, and approximate-count indication when applicable.
• Add Tor/I2P status in Network Health, including explicit DNS-skip behavior for .onion targets.

Phase 4 — Operational trust and automation

• Add append-only audit log for:
  login/logout, settings changes, manual probes, webhook configuration, and future moderation actions.
• Add outbound webhook delivery for:
  probe.failed, probe.recovered, ssl.expiring, mirror.disconnected, and worker.failed.
• Add delivery retry/backoff, signed payloads, redacted error logs, and test-delivery support.
• Export OpenTelemetry metrics for probe duration, probe result, TLS-expiry horizon, and mirror connectivity.
• Add a redacted diagnostics bundle containing version, sanitized configuration, worker state, recent health results, and relevant logs.

Stretch goals

• Public read-only status page with explicitly sanitized data.
• Onboarding wizard that validates relay URL, TLS, NIP-11, admin setup, and monitor configuration.
• Alert rules UI with thresholds, suppression windows, and notification routing.
• NIP-86 relay-management API slice authenticated with NIP-98:
  start with supportedmethods, read-only list methods, and carefully scoped moderation methods.
• Compare local monitor results with selected external NIP-66 monitor events.

Relevant NIPs

NIP	Purpose
NIP-66	Relay liveness monitoring; kinds 30166 and 10166
NIP-33	Parameterized replaceable storage for kind 30166
NIP-11	Relay information document and advertised capabilities
NIP-01	WebSocket protocol used by read/write probes
NIP-42	Authentication capability and auth probe behavior
NIP-52	Optional monitor geohash (g tag)
NIP-45	Existing COUNT support for storage analytics
NIP-05	Existing verification data surfaced in admin
NIP-65	Monitor relay list bootstrap (kind 10002)
NIP-98	HTTP authorization, if NIP-86 is implemented
NIP-86	Stretch standardized relay-management API

Dependencies

• feat(nip66): add shared relay probe engine (DNS, TLS, WS RTT, NIP-11) #669 / NIP-66 monitor foundation
• Admin metrics SSE and dashboard work
• Admin settings editor work
• Existing maintenance and static-mirroring worker infrastructure

Success criteria

• Operators can identify externally observable DNS, TLS, WebSocket, mirror, and worker failures from the admin console.
• Nostream publishes valid, normalized NIP-66 monitor/discovery events on a configurable interval.
• NIP-11 claims that conflict with measured behavior are visible to operators.
• Administrative mutations create audit entries.
• Alert delivery is reliable, observable, and never exposes secrets.
• All capabilities remain opt-in or disabled by default where they create external traffic, public data, or operational risk.