Skip to main content

​
Source-Backed FiberOps

Week 8 ended with a direction. The project was FiberOps Dashboard: a read-only Fiber infrastructure dashboard focused on node health, channel state, routing confidence, payment diagnostics, alerts, and operator readiness. That was the planning bridge. It named the project, the hackathon category, the MVP boundary, and the risk of pretending a demo was more live than it actually was. Week 9 is where that bridge turns into product truth. The thesis for the week is: A Fiber infrastructure dashboard is only credible when every claim is tied to real evidence, and every missing source remains visible. That matters because FiberOps is no longer a mock-first idea. The current app direction is a self-hosted, read-only observability dashboard for real Fiber Network nodes. It connects to configured Fiber JSON-RPC, optional Fiber Prometheus metrics, optional Fiber WebSocket store changes, optional Fiber logs, optional CKB RPC, public Fiber routing data, and local SQLite persistence. It does not need funded credentials, private keys, or write access to prove the core read path. The important change is not just technical. It is ethical product design. A dashboard that fills missing metrics, events, channels, payments, or CCH rows with invented examples may look complete, but it teaches the operator to trust something that has no source. FiberOps should do the opposite.

​
What source-backed means

Source-backed does not mean every possible source is available by default. It means every rendered claim carries a source state:
  • available
  • unavailable
  • not configured
  • warning
  • source gap
Those states are different. A public testnet Fiber RPC can be available while Prometheus metrics are not configured. CKB RPC can prove funding transaction checks while WebSocket store changes remain absent. Public routing data can help with topology context while still being unable to prove private liquidity. CCH order lookup can be a warning when the connected node does not expose get_cch_order, unless the environment explicitly requires CCH proof. That vocabulary keeps the dashboard honest. It lets FiberOps say:
  • this channel row came from Fiber JSON-RPC
  • this funding status came from CKB RPC
  • this route context came from local Fiber graph rows or public routing data
  • this alert came from deterministic rules over real observations
  • this metric-backed claim is blocked because no metrics endpoint is configured
  • this event timeline is empty because no log path or WebSocket subscription is configured
That is a stronger product than a polished demo with hidden fixtures.

​
The collector boundary

The FiberOps collector boundary is intentionally read-only. The source map is now clear:
  • Fiber JSON-RPC supplies node info, peers, channels, payments, graph nodes, graph channels, invoice parsing, and optional CCH order lookup.
  • CKB RPC supplies chain health and funding transaction checks.
  • Public routing data supplies public topology context when local graph rows are absent.
  • Fiber Prometheus metrics can supply channel, peer, payment, gossip, and CCH tracker counters when configured.
  • Fiber WebSocket subscribe_store_changes can supply store-change timeline events when configured.
  • Fiber logs can supply redacted timeline evidence when an operator provides a readable log path.
  • Local SQLite stores the latest real observations and retained alert history.
The same boundary also says what FiberOps should not do in this release. It should not send payments, open channels, shut down channels, connect peers, rebalance liquidity, send BTC, receive BTC, or mutate operator state. That matters for two reasons. First, the hackathon category is infrastructure. A dashboard that observes, diagnoses, exports, and alerts is infrastructure. A hidden operator-action surface would be a different product with a different permission model. Second, read-only evidence is easier to trust. FiberOps can ask for a read-only Biscuit token when auth is available. It can report unsafe public RPC posture when a public endpoint is reachable without auth. It can keep the operator boundary visible instead of turning the dashboard into a control plane too early.

​
Diagnostics without replacement rows

Week 8 described the kinds of alerts FiberOps should have. Week 9 sharpens the rule: alerts can explain real evidence and real source gaps, but they cannot invent the missing operational object. If Fiber RPC reports a ready channel with zero outbound liquidity, the dashboard can emit a liquidity alert. If Fiber RPC reports a ready channel whose counterparty is missing from connected peers, the dashboard can emit a peer alert. If a payment has been inflight too long or failed with route text, the dashboard can emit a payment diagnostic. If metrics are not configured, the dashboard can emit a source coverage alert. It cannot emit a fake gossip rejection counter. If logs are not configured, it can say log evidence is absent. It cannot create settlement or watchtower events that did not come from a log line or WebSocket payload. This is the difference between diagnostic software and demo decoration.

​
The default environment is real but incomplete

The default public testnet mode is useful because it can show real Fiber and CKB data without paid infrastructure. It can use a public Fiber RPC endpoint, a public CKB testnet RPC endpoint, and public Fiber routing data. That is real evidence, but it is not a full hosted operator environment. The gaps are part of the product truth:
  • Fiber metrics need a configured Prometheus endpoint.
  • WebSocket store-change events need a configured subscribe_store_changes endpoint.
  • Fiber logs need a readable operator-provided log path.
  • Safe RPC posture needs localhost/private binding or read-only Biscuit auth instead of unauthenticated public HTTP.
  • CCH order proof needs a node or build that exposes get_cch_order; otherwise CCH stays optional.
Code can prove the collector architecture, read-only boundary, deterministic diagnostics, local persistence, source coverage reporting, diagnostic exports, health APIs, and default public testnet behavior. Only an operator-controlled environment can prove full metrics, WebSocket, logs, safe RPC posture, and CCH order coverage. That separation is the Week 9 line.

​
What to build locally this week

Run the Week 9 exercises from the FiberOps source-truth package:
The scripts are dry-run by default. They require no Fiber node, no funded wallet, no private key, and no credentials. They model the operational rules FiberOps now has to preserve. Read the scripts in order:
  • 33-source-backed-observation-model.ts
  • 34-fiberops-collector-boundary.ts
  • 35-diagnostics-from-evidence.ts
  • 36-hackathon-demo-truth-check.ts
Together, they mark the start of the hackathon build phase:
  • model source states without collapsing them into one generic error
  • map every data source into a read-only observation boundary
  • turn real observations into diagnostics without replacement rows
  • separate code-owned proof from hosted/operator infrastructure gaps
Week 8 asked what FiberOps should become. Week 9 answers with the first build rule: every confident claim needs evidence, and every missing source must stay visible.