dig_node_control_interface/
lib.rs

1//! # dig-node-control-interface — the canonical client ⇄ dig-node CONTROL interface contract
2//!
3//! This crate is the single source of truth for the management/query surface a client — the CLI
4//! `dign`, the browser extension, dig-app, or hub — uses to **control and query a running dig-node**:
5//! node configuration, cache configuration, peer status, subscription lifecycle, peer connect/
6//! disconnect, and other node-control operations. Both the node (the server side, dispatching these
7//! calls) and every client (the callers) depend on THIS crate rather than each maintaining a
8//! byte-identical copy of the method catalog, so the two can never silently drift.
9//!
10//! ## Boundary (the 6th directed-boundary contract crate)
11//!
12//! The DIG ecosystem draws its cross-process contracts as small, single-purpose crates rather than
13//! folding every wire shape into the systems that use them:
14//!
15//! - **dig-rpc-protocol** — node ⇄ node peer wire (PublicRead + Peer tiers).
16//! - **dig-ipc-protocol** — app ⇄ node local session/signing envelope (the pipe/transport + the
17//!   challenge/callback handshake a client authenticates over).
18//! - **dig-node-control-interface (this crate)** — the CONTROL METHOD CATALOG a client sends *inside*
19//!   that authenticated channel (or over loopback-mTLS + a signed control token, CLAUDE.md §5.3, for
20//!   clients that don't ride the local IPC session): the method names, parameter/result types, and
21//!   error taxonomy for config/status/peers/subscriptions/cache/wallet control operations.
22//!
23//! This crate is deliberately **transport-agnostic** — it describes WHAT a client can ask a node to do
24//! and what the node replies, not HOW the bytes travel. Consumers pick the transport (dig-ipc-protocol
25//! session, loopback HTTP/WebSocket, or a future channel) and carry these types over it.
26//!
27//! ## Status: skeleton (epic #1110, T1 of the cascade)
28//!
29//! This is the PROVISIONING commit: the repository, CI/release plumbing, and module layout exist so
30//! the contract can be designed and filled in without also bootstrapping infrastructure. The actual
31//! method catalog — request/response types, the control-error taxonomy, and the conformance KATs —
32//! lands in T2 (tracked as dig_ecosystem#1147). Until then [`control`] is an intentionally empty
33//! placeholder module reserved for that catalog.
34
35#![forbid(unsafe_code)]
36#![warn(missing_docs)]
37
38/// Reserved for the client↔node control method catalog (request/response types, error taxonomy).
39///
40/// Populated by epic #1110 T2 (dig_ecosystem#1147) — the reconciliation decision on migrating the
41/// `Control` tier out of dig-rpc-protocol, plus the exact method/type/error set this crate owns.
42pub mod control {
43    /// The crate's semantic version, exposed so consumers can assert compatibility at runtime
44    /// without re-parsing `Cargo.toml` (mirrors the pattern used by the sibling contract crates).
45    pub const CRATE_VERSION: &str = env!("CARGO_PKG_VERSION");
46}
47
48#[cfg(test)]
49mod tests {
50    use super::control;
51
52    /// The skeleton's only behaviour today: the crate reports its own version. This is a canary
53    /// that the crate builds, links, and exposes `control` as expected — the real conformance KATs
54    /// arrive with the method catalog in T2.
55    #[test]
56    fn crate_version_is_exposed_and_matches_cargo_toml() {
57        assert_eq!(control::CRATE_VERSION, "0.1.0");
58    }
59}
dig_node_control_interface/lib.rs

dig_node_control_interface/
lib.rs
