Crate dig_peer 

dig-peer — the DIG Network peer client

DigPeer is the one client every consumer uses to talk to a DIG Network peer. You describe the peer once (PeerTarget) and get back a connected DigPeer; it drives dig-nat’s full traversal ladder (direct → UPnP → NAT-PMP → PCP → hole-punch → relayed, IPv6-first) under the hood, so the caller never chooses a transport. On top of that mutually-authenticated (mTLS) connection it exposes typed RPC over dig-rpc-protocol and seals directed calls end-to-end to the peer’s verified BLS-G1 identity (§5.4). DigPeer::disconnect tears the connection down cleanly.

dig-peer is the client mirror of dig-rpc’s server. It wraps a dig_nat::PeerConnection (point-to-point) — NOT dig-gossip, which is the mesh/broadcast layer. It is also not a ChiaPeer: DigPeer connects to DIG Network peers over dig-nat mTLS + dig-rpc-protocol; it pulls in zero Chia full-node protocol.

Reaching a SPECIFIC peer requires its peer_id (security)

DigPeer::connect takes a PeerTarget carrying the peer’s peer_id (SHA-256(SPKI DER)) and pins the mTLS handshake to it (via dig-nat / dig-tls). Chaining to the DigNetwork CA alone authorizes a DIG peer, never a specific one — so a caller that means to reach peer X MUST supply X’s peer_id, or a different CA-valid peer could answer in its place. This is enforced, not advisory: connect fails if the peer that answers does not present the expected peer_id.

Directed calls are sealed, fail-closed (§5.4)

Control RPCs that carry peer-specific content (getNetworkInfo, getPeers, announce) are DIRECTED: dig-peer seals their payload to the peer’s captured BLS-G1 key before sending, so an intermediary that terminates TLS (a relay) forwards ciphertext it cannot read. A directed call is refused (never downgraded to plaintext) if the peer presented no verified BLS-G1 key or no local sealing identity is configured — set one with DigPeer::with_sealing_identity.

Public-read/availability calls (health, getAvailability, byte-range fetch) carry public-by-nature, merkle-verified content and are NOT directed (§5.4 sensible-scope exemption): they ride mTLS unsealed.

Example

let target = PeerTarget::with_addr(peer_id, addr, "DIG_MAINNET");
let mut peer = DigPeer::connect(&target, &node).await?;
let health = peer.health().await?;
println!("peer status: {}", health.status);
peer.disconnect().await;

Re-exports

pub use error::DigPeerError;

pub use error::Result;

pub use seal::SealingIdentity;

pub use state::PeerState;

Modules

error

The dig-peer error taxonomy.

rpc

The peer-stream RPC framing — how a typed JSON-RPC call rides one mux stream.

seal

The §5.4 end-to-end seal applied to directed RPC — layered ON TOP of mTLS.

state

The DigPeer connection lifecycle.

Structs

AvailabilityItem

One item in a dig.getAvailability batch — a resource key at store, root, or capsule/resource granularity (inferred from which fields are present, per the L7 spec §9): store_id only → has_store; + root → has_root (the capsule store_id:root); + retrieval_key → has_resource. Hashes are 64-hex.

AvailabilityResponse

The peer’s answer to an AvailabilityRequest: one AvailabilityAnswer per queried item, positionally aligned with the request’s items.

DigPeer

A connected DIG Network peer — the client every consumer uses.

NodeCert

A peer’s mTLS identity certificate + private key, plus its derived peer_id.

PeerId

A peer’s stable network identity: the 32-byte SHA-256 of its TLS SPKI DER.

PeerTarget

A description of the peer to connect to.

RangeRequest

A byte-range request (dig.fetchRange, L7 spec §9) written at the start of a range-scoped stream. Identifies a resource (store_id + retrieval_key [+ root]) or a whole capsule (capsule: true, identified by store_id [+ root]) and the [offset, offset+length) range.