Context
#669 delivers the first end-to-end NIP-66 monitor:
- shared probe engine
- relay-monitor worker
- basic kind
30166 / 10166 publishing
- latest network-health snapshot in admin
This issue is the next phase: turns that foundation into a practical relay operations layer.
Problem
After #669, operators can see a current health snapshot, but they still cannot easily:
- track failures over time
- compare advertised relay behavior vs measured behavior
- inspect mirror/worker/NIP-05/storage health from one place
- audit admin actions or receive alerts when things break
Goal
Extend the admin console into an operations platform without redoing #669.
Scope
1) Advanced NIP-66 telemetry
- Add
rtt-read and rtt-write probes
- Detect NIP-42 auth requirements where applicable
- Enrich kind
30166 tags (rtt-read, rtt-write, N, R, k, optional NIP-52 g)
- Add NIP-11 vs probe mismatch warnings (auth, limits, public URL mismatch)
- Monitor peer relays from
mirroring.static[]
2) Network Health operations
- Persist bounded probe history
GET /admin/network-health/history
- Optional
POST /admin/network-health/probe (manual trigger + audit entry)
- History charts/timeline in dashboard
nip66.* controls in settings editor (interval, targets, timeouts, retention)
3) Ops visibility panels
- Mirror Health: connection state, reconnects, last event, lag/failure reason
- Worker Ops: maintenance / mirroring / relay-monitor status and last run
- NIP-05 Verification: search/filter, age, failures, manual re-verify
- Storage (NIP-45 COUNT): counts by kind/time range, retention impact
- Tor/I2P visibility and explicit
.onion DNS-skip behavior
4) Trust and automation
- Append-only audit log (login, settings changes, manual probes, webhook config)
- Outbound webhooks:
probe.failed, probe.recovered, ssl.expiring, mirror.disconnected
- OpenTelemetry probe/mirror metrics
- Redacted diagnostics export bundle (version, sanitized config, recent health, worker state)
Out of scope (handled by #669)
- Initial probe engine implementation
- First relay-monitor worker
- First publish path for kind
30166 / 10166
- First
GET /admin/network-health latest snapshot endpoint
- First basic Network Health panel
Important constraint
Self-hosted probing validates public URL/DNS/TLS/routing from the relay’s own network location.
It is useful for operators, but not a substitute for independent external monitors.
UI and published NIP-66 data must label monitor identity/location and avoid presenting one monitor as authoritative.
Relevant NIPs
- NIP-66 (advanced monitor/discovery tags)
- NIP-11 (advertised vs observed mismatch checks)
- NIP-42 (auth probing)
- NIP-52 (optional geohash)
- NIP-45 (storage counts)
- NIP-05 (verification visibility)
- NIP-65 (monitor bootstrap continuity)
Dependencies
Success criteria
- Operators can diagnose recurring DNS/TLS/WS/mirror/worker issues without SSH/SQL
- Probe history and mismatch warnings are visible in admin
- Admin mutations and manual probes are auditable
- Alerts are opt-in, reliable, and never expose secrets
- Nostream publishes richer NIP-66 data compatible with client aggregation models
Context
#669 delivers the first end-to-end NIP-66 monitor:
30166/10166publishingThis issue is the next phase: turns that foundation into a practical relay operations layer.
Problem
After #669, operators can see a current health snapshot, but they still cannot easily:
Goal
Extend the admin console into an operations platform without redoing #669.
Scope
1) Advanced NIP-66 telemetry
rtt-readandrtt-writeprobes30166tags (rtt-read,rtt-write,N,R,k, optional NIP-52g)mirroring.static[]2) Network Health operations
GET /admin/network-health/historyPOST /admin/network-health/probe(manual trigger + audit entry)nip66.*controls in settings editor (interval, targets, timeouts, retention)3) Ops visibility panels
.onionDNS-skip behavior4) Trust and automation
probe.failed,probe.recovered,ssl.expiring,mirror.disconnectedOut of scope (handled by #669)
30166/10166GET /admin/network-healthlatest snapshot endpointImportant constraint
Self-hosted probing validates public URL/DNS/TLS/routing from the relay’s own network location.
It is useful for operators, but not a substitute for independent external monitors.
UI and published NIP-66 data must label monitor identity/location and avoid presenting one monitor as authoritative.
Relevant NIPs
Dependencies
Success criteria