dig-node-control-interface
The canonical client ⇄ dig-node CONTROL interface contract. One ecosystem definition of the
management/query surface a client (the CLI dign, the browser extension, dig-app, hub) uses to
control and query a running dig-node — config, cache config, peer status, subscriptions, peer
connect/disconnect, and other node-control operations — so the client side and the node side can
never silently drift. Transport-agnostic: rides the dig-ipc-protocol local session, or
loopback-mTLS + a signed control token over HTTP/WebSocket for clients that aren't on the local pipe.
- License: Apache-2.0 OR MIT
- Spec:
SPEC.md(normative) — this README is the at-a-glance interface reference.
[]
= "0.1"
Status: skeleton (epic #1110, T1). This is the provisioning commit — the repository, CI/release plumbing, and module layout only. The full method catalog (this section is where every control method, its params/result types, and its error code would be listed for LLM/agent lookup, per the ecosystem's dig-
<x>-protocol convention) lands in T2 (tracked asdig_ecosystem#1147). Check back there, or re-read this README once T2 merges, for the real interface reference.
Boundary
dig-rpc-protocol— node ⇄ node peer wire.dig-ipc-protocol— app ⇄ node local session/signing envelope (the transport this catalog rides over, for local clients).dig-node-control-interface(this crate) — the control METHOD CATALOG carried inside that authenticated channel, or over loopback-mTLS for remote-transport clients.
See SPEC.md §1 for the full boundary statement, and the superproject SYSTEM.md for how this crate
fits the wider cross-repo contract map.
Consumers (planned)
dig-node (server-side dispatch), the CLI dign, dig-chrome-extension, dig-app, hub — all consuming
this one control contract once T2 lands, per epic #1110.