Purpose
Peer discovery, mutable records, DID envelopes, local relay sessions, adapter registry, record stores, and handles. This page follows the real source shape for Weave Dht and explains the workflow a developer is likely to use first.Network contract
Document peer identity, topic selection, message framing, session lifetime, retry behavior, metrics, and what must be stable between releases. Any change here can strand peers, so examples should be exercised with at least two real processes.Primary types to know
AdapterRegistry— network/weave-dht/src/methods.rsAnnouncementState— network/weave-dht/src/weave.rsAnnounceOpts— network/weave-dht/src/weave.rsDhtClient— network/weave-dht/src/lib.rsDhtConfig— network/weave-dht/src/lib.rsDhtHandle— network/weave-dht/src/lib.rsDhtMethodAdapter— network/weave-dht/src/methods.rsDhtNode— network/weave-dht/src/lib.rsDhtNodeBuilder— network/weave-dht/src/lib.rsDidEnvelope— network/weave-dht/src/envelope.rsEnhancedDhtNode— network/weave-dht/src/enhanced.rsMarsAdapter— network/weave-dht/src/methods.rs
Example shape
Release-quality documentation checklist
- Every public type on the API Surface page has at least one sentence of behavior documentation.
- Every fallible operation lists errors and recovery guidance.
- Every networked example names the peer/session/topic lifecycle.
- Every storage example names durability, repair, and deletion semantics.