[Admin Console] : Built-in NIP-66 Network Health Monitor and Operator Dashboard Integration

[Ferryx349]

Problem

The admin console (Phase 1 + Phase 2 metrics) gives operators internal relay health :- EPS, active WebSocket connections, CPU/RAM, DB/Redis ping — but it does not answer the questions that matter for hosted deployments:

• Can clients actually reach my relay over its public URL?
• Is DNS resolving correctly for my relay domain?
• Is TLS valid, and when does the certificate expire?
• What is real WebSocket latency from outside the process?

Today, operators must SSH in, run manual curl/dig/openssl checks, or rely on external monitors (e.g. BigBrotr) to get this data. Nostream also does not publish NIP-66 relay discovery events (kind 30166 / 10166), so clients like NDK cannot use Nostream's own health data when filtering dead relays.

Meanwhile, the approved admin console design treats the UI as an operator platform, not only a metrics dashboard. Network-level health belongs in that platform and should share infrastructure with ecosystem-facing NIP-66 publishing.

Proposed solution

Add a built-in NIP-66 relay health monitor as a new cluster worker, with a shared probe engine consumed by both:

1. Nostr network — publish kind 30166 (relay discovery) and kind 10166 (monitor announcement) events
2. Admin console — new Network Health panel and API endpoints so operators see probe results without terminal access

Benefits

For operators (admin console)

• See DNS, SSL expiry, and WebSocket RTT alongside existing EPS/connection metrics
• Detect "relay looks fine internally but unreachable externally" failures
• Configure probe interval and targets from the browser (via settings editor integration)
• Optional: webhook alerts on probe failure or SSL expiry (Phase 7 extension)
• No SSH, SQL, or manual DNS/TLS debugging for day-to-day health checks

For the Nostr ecosystem

• Nostream instances publish standardized NIP-66 health data
• Clients (e.g. NDK) can filter dead relays using monitor data (~45% faster loading in NDK benchmarks)
• Reduces reliance on a single external monitor authority
• Complements existing NIP-11 self-reporting with measured probe data

For the project

• Fills a gap not covered by Phases 1–8 of the admin console plan
• Reuses existing cluster worker pattern (maintenance, static-mirroring)
• Reuses NIP-33 parameterized replaceable storage (kind 30166 is in range 30000–39999)
• Natural extension of Phase 2 live metrics, not a competing feature

Scope

Track A — NIP-66 backend (core)

• New RelayMonitorWorker cluster worker (WORKER_TYPE=relay-monitor)
• Shared probe modules:
  • DNS (A, AAAA, CNAME, TTL) with caching
  • SSL/TLS (validity, expiry, issuer)
  • WebSocket RTT (rtt-open; later rtt-read, rtt-write)
  • NIP-11 fetch (Accept: application/nostr+json)
• Publish kind 30166 (relay discovery) for self (optional peer relays from mirroring.static)
• Publish kind 10166 (monitor announcement)
• Bootstrap monitor identity: kind 0 profile and kind 10002 relay list (NIP-66 SHOULD)
• Settings: nip66.enabled, probe interval, timeouts, monitor pubkey/key, targets
• Handle edge cases: nginx/Tor/I2P (probe public URL, not localhost:8008), .onion skips DNS
• Unit + integration tests

Track B — Admin console integration (extends Phase 2)

• GET /admin/network-health — latest probe snapshot (auth required)
• GET /admin/network-health/history — last N probe runs (optional v2)
• POST /admin/network-health/probe — manual probe trigger with audit log (optional v2)
• Dashboard Network Health panel in resources/admin/dashboard.html:
  • WebSocket RTT (open/read/write when available)
  • DNS records and TTL
  • SSL status and expiry countdown
  • Last probe time and success/failure
  • Network type (clearnet / tor / i2p)
• SSE or polling refresh alongside existing /admin/metrics stream

Track C — Settings editor slice (extends Phase 3)

• Schema-aware editor for nip66.* settings (probe interval, enabled, targets)
• Preview diff + timestamped backup + audit log (reuse Phase 3 patterns from [Admin Console] Phase 3: Visual Settings Editor #633)
• Hot-reload without relay restart

Track D — Stretch

• Peer monitoring for mirroring.static[] URLs
• Webhook triggers: probe.failed, ssl.expiring (extends [Admin Console] Phase 7: Webhooks and Notifications #637)
• OpenTelemetry metrics for probe duration/success
• Evaluation: compare published 30166 vs BigBrotr for sample relays

NIPs involved

NIP	Role
NIP-66 (new)	Primary — kind 30166 / 10166 relay liveness monitoring
NIP-33	Already supported — 30166 is parameterized replaceable
NIP-11	Already supported — fetched during probes, embedded in 30166 content
NIP-65	Already supported — kind 10002 relay list for monitor identity
NIP-01	Base event signing and WebSocket protocol for probes

Depends on

• Admin auth foundation (Phase 1 shipped)
• /admin/metrics SSE endpoint ([Admin Console] : Add cluster-aware /admin/metrics SSE endpoint (Prometheus-backed) #655 — review in progress)
• Existing cluster worker spawn pattern (app.ts, index.ts)
• Existing parameterized replaceable event storage (NIP-33)
• Separate monitor identity (MONITOR_PRIVATE_KEY or dedicated settings key)

Success criteria

• Relay publishes valid kind 30166 and 10166 events on a configurable interval
• Operator sees DNS, SSL, and RTT data in /admin without terminal access
• Probe targets the public relay URL, not internal bind address
• Admin console remains disabled by default; no secrets exposed in API responses
• NIP-66 events queryable via standard Nostr filters ({"kinds":[30166],"authors":["<monitor-pubkey>"]})

References

• NIP-66 spec
• BigBrotr monitor example
• NDK NIP-66 filtering (~45% faster loading)

Additional context

Approved admin console design covers operator platform needs (metrics, settings, moderation, payments, webhooks, ops) but does not include external network health probing or NIP-66 publishing. This issue proposes bridging that gap with shared probe infrastructure serving both the admin UI and the wider Nostr network.

CC: @cameri — seeking alignment before starting implementation. Happy to adjust scope based on feedback.

[cameri]

@Ferryx349 Looks good! please proceed