Relay DHT protocol
libp2p protocol ID: /meshline/kad/1.0.0
This protocol defines connections, identity authentication, and resource operations in the public-relay overlay, allowing eligible public relays to publish, replicate, and query fully verifiable DHT resources. Clients do not act as DHT nodes. Account routes are the only resource type registered by Protocol 1.0. Messages, contacts, profiles, chat history, and private keys MUST NOT be written to the DHT as this resource.
A DHT peer's public relay MUST have a Registry record whose status is active, and its current RelayDescriptor must bind its relay_id, Peer ID, and dialable addresses. Remote peers, routing tables, caches, and lookup paths are not roots of user trust. Every storage node and querying node MUST independently verify the key, resource type, signatures, validity period, and ordering of candidate records.
Protocol contents
| Part | Contents |
|---|---|
| Connections and identity authentication | Overlay candidate discovery, Noise extension, and relay eligibility verification |
| Overlay and node maintenance | Peer eligibility, joining, routing-table maintenance, security, and persistent node state |
| Account route publication and resolution | Joint signing, DHT replication, iterative resolution, caching, and republication |
| Core objects | Resource-key derivation, AccountRoute structure, signatures, revision, and candidate selection |
| Message format | Protocol ID, message framing, protobuf subset, common fields, and rejection behavior |
| DHT operations | Messages and processing rules for node lookup, resource retrieval, and storage |
Operation index
FIND_NODE: find eligible peers closer to a target key;GET_VALUE: retrieve and validate resource records;PUT_VALUE: validate and persist resource records.
Conformance requirements
Compatible implementations must follow the conformance testing boundaries and cover:
- Connections and identity: under connection authentication, verify outbound connections to known relays, candidate connections with only a Peer ID and address, and inbound connections from unfamiliar relays. The latter two must authenticate using only the handshake descriptor and Registry. Under the overlay maintenance rules, verify loss of eligibility, Peer ID rebinding, and removal of old entries.
- Messages and operations: under the message format and DHT operations, verify length prefixes, payload limits, rejection of invalid messages, multi-node PUT/GET, and FIND_NODE candidate validation.
- Route validation: under the core objects, verify network and account binding, both signatures, resource keys, complete-object size, time boundaries, version rollback prevention, and same-version conflicts. Invalid higher versions MUST NOT advance the known version.
- Storage and recovery: under the route lifecycle and version and conflict rules, verify republication, caching, expiry, cleanup, migration, node restart, and recovery from network partitions. Version lower bounds and unresolved conflicts MUST remain retained. After the highest-version route expires or conflicts, resolution requires a higher, conflict-free valid route.