Dashboard — Internal System Observability Tool
Status: ⚠️ Internal tool — not distributed to the public. The Dashboard is a telemetry/observability consumption layer for the whole IFM system (audio, transport, relay, discovery). It is used by IFM developers and operators during development and operations. It is never shipped to end users.
Architecture home: Observability.
Scope — What the Dashboard Is (and Is Not)
- Is: an internal observability layer that consumes the observability interface of running IFM nodes and renders live, system-wide views — node status and health, connections, relay activity, audio metrics, traffic, logs.
- Is NOT: a relay product, a "relay dashboard", or part of the Relay. The Relay is distributed forwarding infrastructure; the Dashboard only observes it (and everything else).
- Observes only — the Dashboard never sends control commands and never participates in the runtime data path (audio, transport, relay, discovery). Nodes continue operating normally if the Dashboard is unavailable.
- Observer node on the Rust core — the Dashboard runs a real
ifm-corenode (AppKind::Dashboard) that joins the REAL network through the rendezvous like every app, then reads the mesh telemetry plane (/ifm/telemetry/v1), the discovery plane (station records + relay announcements), and its own transport view. Being in the mesh is what lets it watch the remote network; it never broadcasts, tunes, or announces, so it cannot affect it. - Built on the Rust core — telemetry is produced by
ifm-core(the protocol's single source of truth) and consumed by a Rust/Tauri backend. The SDK is not involved. - Not distributed — internal tooling, not part of the public product matrix (see Distribution for what is distributed).
Responsibilities
- Discover and track all running IFM nodes via the observability interface (read-only snapshots)
- Show node status and health — CPU, memory, network, gossip, DHT, audio pipeline
- Monitor connections and peers — per-peer state, RTT, transport mode
- Monitor relay activity — pool membership, forwarded packets, uptime (read-only)
- Monitor audio/stream state — Opus encode/decode health, jitter buffer, VAD, mic level
- Monitor frequencies — active frequencies, listener/broadcaster counts
- Provide historical observability — retained packet logs, connection history, replay
- Provide debugging/diagnostic info — packet captures, topology snapshots, node introspection
See Observability for the full architectural constraints (no runtime dependency, observes only, telemetry interface, passive).
Architecture
The Dashboard is an observer node: it joins the real mesh through the rendezvous (same remote entry as every app — LAN only under IFM_LAN=1), then reads the protocol's own planes. Its only outbound traffic is its own small telemetry frame (like every node's). A node with no dashboard runs identically; a crashed dashboard has zero effect on the mesh.
Quick Start
bash
# 1. Run any IFM node(s) — desktop apps (station/relay/listener) or headless
# nodes. They join the mesh through the rendezvous by default and publish
# telemetry automatically.
# 2. Build + run the dashboard:
cd packages/ifm-dashboard
bun install
bun run tauri dev
# The dashboard's observer node fetches the rendezvous manifest, joins the
# real mesh, and shows live telemetry from every node it hears.Implemented Today
The packages/ifm-dashboard Tauri app runs an observer node on ifm-core that joins the REAL mesh through the rendezvous and shows live:
- the observer's own mesh state (node id, transport, peers, relay pool)
- per-node telemetry cards: P2P health (latency, jitter, loss, upload, role, path), health counters, frequencies, peers, relay plane, audio, packets
- signed station records and relay announcements from the discovery plane
- a live topology graph (React Flow): mesh nodes, peers, relay pool
- ranked candidate paths per node (Path Manager, best-first)
Design Spec — System-Wide Panels
The long-term dashboard observes all nodes via the observability interface. The panels below are the internal capability roadmap.
1. Mesh Topology
Real-time peer graph with geographic intelligence
- Force-directed graph (D3.js / Canvas) — peers as nodes, connections as edges
- Layout modes: geographic (GeoIP), logical (connection strength), hierarchical (bootstrap → regional → edge)
- Node encoding: size = bandwidth, color = health, border = transport (QUIC/WebRTC/TCP), label = peer ID + region
- Edge encoding: width = traffic volume, color = latency, pulse = packet flow direction
- Controls: pan/zoom, search, filter by region/transport/state, time-travel slider
- Peer detail drawer: connection history, per-frequency traffic, transport fallback history
2. Frequencies
Registry of all known frequencies
- Columns: name, namespace, channel, type (public/protected/hidden), listener count, broadcaster count, bandwidth, codec, bitrate, last activity
- Sort/filter/search/export CSV; bulk actions
- Frequency detail: per-frequency traffic, connected peers
3. Traffic Analytics
Deep-dive packet flow analysis
- Real-time charts (500ms update): packets/sec and bytes/sec in/out, stacked by type (voice/text/video/control/plugin)
- Aggregation windows: 1m, 5m, 15m, 1h, 24h (pre-aggregated in node)
- Breakdown tables: by frequency, by peer, by type, by TTL, by hops
- Anomaly detection: auto-flag spikes (3σ), new frequency bursts
- Export: CSV (current view), PCAP (raw packets)
4. Health Monitoring
System + node metrics with thresholds (per observability topic node.health)
| Gauge | Source |
|---|---|
| CPU % | node.health.cpu_percent |
| Memory % | node.health.memory_bytes / total |
| Network In/Out | node.health.network.* |
| Connections | node.health.network.connections |
| Gossip Hit Rate | node.health.gossip.hit_rate |
| Gossip Cache | node.health.gossip.cache_size |
| DHT Routing Table | node.health.dht.routing_table_size |
| Audio Encoders | node.health.audio.encoder_active |
| Audio Decoders | node.health.audio.decoder_active |
- Threshold config per gauge (warn/crit), notification channels
- SLO panel: availability (99.9%), latency p50/p95/p99, peer churn rate
5. Peers
Operational peer view (node.peers)
- Peer ID, region, state, latency, bandwidth in/out
- Per-peer detail, blocklist management
- Read-only: the dashboard observes; operational actions belong to node tooling
6. Relay Activity
Relay pool and forwarding health, read-only (node.relay)
- Pool membership, forwarded packet counts, uptime
- Per-frequency relayed traffic, counters, live feed
- This is observation of the Relay — not a relay product itself
7. Alerting
Threshold + anomaly alerting with notification routing
- Rule examples: peer churn >10/min, gossip hit rate <70%, CPU >85% sustained, bandwidth saturation >90%
- Channels: webhook, email, in-app, SSE stream (
alerts.stream) - Alert feed: live streaming list, acknowledge/silence/dismiss, history, searchable/exportable
8. Historical Replay
Time-travel debugging
- Timeline scrubber + synchronized panels at selected timestamp
- Playback controls (0.25x–5x), loop range, event markers
- Export: snapshot (JSON), video (WebM), report (PDF)
- Use cases: post-mortem, capacity planning, cascade debugging
Data Flow
HTTP polling
- Request/response polling for state that changes at known intervals (snapshot poll every 1–2s; topology 1s, frequencies 2s)
- SSE push is a future option for high-frequency data:
packets.stream(500ms aggregates),metrics.stream(2s),alerts.stream(immediate),logs.stream
Replay Engine (Local-First)
- Browser stores recent aggregated metrics in IndexedDB; node retains longer history
- Timeline scrubber reads local buffer (instant) → falls back to node history RPC
Key User Flows
- Daily operations check — open dashboard → scan health gauges → check alert feed → topology stable → traffic balanced → done in 30s
- Incident response — alert fires → click → health tab highlights gauge → filter topology by region → peer table shows state → monitor recovery → replay to incident start → export report
- Capacity planning — replay last 7 days → watch traffic peaks → health at peak → plan relay/edge capacity
- Frequency lifecycle — create/announce frequency → station tunes → listener count climbs → traffic row appears
Responsive Breakpoints
| Breakpoint | Width | Layout |
|---|---|---|
| Mobile | < 640px | Single panel, bottom tab bar; topology = peer list |
| Tablet | 640–1024px | 2-col: main panel + sidebar (alerts/health) |
| Desktop | 1024–1440px | Full multi-panel grid |
| Wide / Ops Wall | > 1440px | All panels visible + SLO panel, replay minimap |
Implementation Phases
- Foundation — Vite + React + TypeScript scaffold, Rust observability client, routing/tabs ✅
- Core panels — nodes, health, peers, frequencies, relay, audio, packets ✅
- Mesh telemetry integration — observer node joins the rendezvous and reads the telemetry plane + discovery records ✅
- Historical replay — IndexedDB storage, timeline scrubber, synchronized panels, exports
- Advanced — geographic layout, anomaly detection, SLO panel, multi-node federation view, mobile polish
- Hardening — themes, accessibility, performance, E2E tests, runbooks
Related Docs
- Observability Architecture — the dashboard's architecture home
- Relay — the distributed product the dashboard observes (not to be conflated)
- Station App — broadcaster studio (content originates here)
- Listener App — end-user consumption
- Demos — the three demo apps
- SDK API —
IFM.observeRelay()observer API (web demo observer — the desktop Dashboard uses the Rust-core mesh telemetry plane instead) - Real-Time Media Transport & P2P-First Mesh — telemetry requirements (per-stage latency, live-edge offset)