Module wire 

The DHT RPC wire — the four request/response messages, type-tagged JSON, framed as a u32 big-endian length prefix + JSON body (the same uniform framing dig-nat uses for its control messages).

The four methods (RLY-style, aligned to the L7 peer-network wire)

Method	Request	Response	Purpose
find_node	{ type:"find_node", target:<64hex key> }	{ type:"nodes", nodes:[Contact] }	the k peers this node knows closest to target
find_providers	{ type:"find_providers", content_key:<64hex> }	{ type:"providers", providers:[ProviderRecord], closer:[Contact] }	providers held locally + k closer peers if none
add_provider	{ type:"add_provider", record:ProviderRecord }	{ type:"add_provider_ok" }	store the record (announce to the k closest)
ping	{ type:"ping", nonce:uint }	{ type:"pong", nonce:uint }	liveness (echoes the nonce)

A Contact on the wire is { peer_id:<64hex>, addresses:[{host,port, kind}] } — the same address shape as the L7 dig.getPeers peers and a ProviderRecord’s addresses, so a returned contact drops straight into a PeerTarget for dig_nat::connect.

Framing (encode / decode): a u32 big-endian body length, then the JSON body, bounded by MAX_FRAMED_BODY to guard against a malicious length prefix. This is byte-identical to the dig-nat control framing so a node speaks one framing across the peer network.

Enums

DhtRequest

A DHT RPC request — one of the four methods, discriminated by type.

DhtResponse

A DHT RPC response, discriminated by type. Each variant is the reply to the correspondingly named DhtRequest.

Constants

MAX_FRAMED_BODY

Maximum length-prefixed body — guards against a malicious length prefix forcing a huge allocation. Provider lists at k = 20 with a handful of addresses each are well under this.