Running a Nostream relay still requires too much terminal, SQL, log, and configuration-file knowledge, Operators need to monitor relay health, tune settings.yaml, inspect traffic, moderate abusive clients, review admission payments, without SSHing into a server or writing database queries.

This is really important for hosted deployments. A user should be able to deploy the latest Nostream image on a provider, open a secure web admin console, configure the relay, monitor it, and operate it day to day with minimal terminal usage.

I propose to Add an admin console for Nostream. This should be treated as an operator platform, not only a metrics dashboard.

The console should provide:

• Secure admin login, eventually using NIP-98 once merged from SoB !
• Live dashboard for relay health, EPS, active connections, subscriptions, and system resources.
• Visual settings.yaml editor that validates changes and applies them through the existing hot-reload path without requiring relay restarts.
• Quick moderation actions for pubkeys, IP addresses, event kinds, rate-limit bypass lists, and admission-fee whitelists.
• Event search and inspection without SQL knowledge, starting with structured relay filters and later using NIP-50 when implemented.
• Admission/payment operations views for sats earned, pending invoices, failed callbacks, paid admissions, and payment processor health.
• Webhook management for admission and payment notifications to generic HTTP, Discord, Slack, and Telegram targets.
• Groundwork for relay operations NIP-89 to manage start/stop/restart any stats/logs for deployed services.

This will be shipped over 8 PRs by me + combining Sob NIP-50/98/89 PRs, Dashboard PRs, Metrics PR by other contributors

CC: Cameri approved this final desgin:

Phase 1: Admin backend foundation

Authenticate the relay operator before any admin data is exposed.

• Temporary admin password login until NIP-98 Sob lands :)
• Add admin config settings
• Add protected admin router mounted only when enabled.
• Add admin auth middleware with a replaceable auth interface.
• Add GET /admin/health.
• Add GET /admin/session or equivalent.
• Add unit tests for disabled-by-default behavior and auth.

Phase 2: Live metrics

Give operators a fast read on whether the relay is healthy
related work: #439 #464 #468
related issues: #144

• Add cluster-aware runtime counters where possible.
• Add lightweight health checks for DB and Redis.
• Add live updates through WebSocket or server-sent events.
• Avoid heavy DB polling for metrics that can be tracked in memory.
• EPS, Accepted/rejected events, Active WS, CPU/RAM load, Worker Count/Health

for reference:

Phase 3: Settings editor

Safely edit relay configuration from the browser
related issues: #229 #197 #199 #344

• Read and validate current settings.
• Schema-aware editing for common settings.
• Preview diffs.
• Atomic write to .nostr/settings.yaml.
• Timestamped backup before each write.
• Audit log entry for every applied change.
• Use the existing hot-reload behavior where possible.

Phase 4: Moderation

Review abusive activity, Whitelist/Blacklist
related issues: #226 #124

• Add admin endpoints for existing whitelist/blacklist capabilities.
• Add views for rejected events, top pubkeys, top IPs, and rate-limit hits.
• Top publishing pubkeys.
• Top client IPs.
• Rate-limit hits.
• Duplicate/spam-like activity indicators.
• Ban/unban pubkey.
• Whitelist/unwhitelist pubkey.
• Whitelist/unwhitelist IP for rate-limit bypass.
• Edit event kind whitelist/blacklist values.

for reference:

Phase 5: Event Search and Inspection

Inspect stored relay events without SQL.
related work: #262

• Integrate NIP-50 once SoB lands :)
• Search by event id.
• Search by author pubkey.
• Search by kind.
• Search by tag filters.
• Search by created-at range.
• Search with a result limit.

Phase 6: Payments and admissions

Operators can view revenue and admissions status.
related issues: #342

• Total admission fees recorded.
• Pending, paid, expired, and failed invoices.
• Recent admissions by pubkey.
• Payment processor health.
• Callback failure history.
• Manual invoice lookup.
• Admission whitelist management.

for reference:

Phase 7: Webhooks and Notifications

Notify operators when important relay events happen

• Discord/Telegram/Slack/Generic HTTP target.
• Per-event enable/disable controls.
• Test delivery button.
• Retry policy.
• Delivery history.
• Admission invoice created/paid/failed.
• Settings changed / relay restart

Phase 8: System, Logs, and Operations

Operators can view relay logs

• NIP-89 once merged from SoB :)
• Read-only recent logs or log tail.
• Worker health.
• Relay uptime.

Security requirements

• Admin console must be disabled by default untill NIP-98.
• Never expose secrets from .env, payment processor credentials, NWC URLs, or private keys.
• Validate every settings change before writing.
• Require audit records for all mutating admin actions.
• Use timing-safe comparisons for token or webhook secret checks.
• Require HTTPS or trusted reverse proxy guidance for remote admin access.