DHT Binding
Use the real DhtHandle adapter or an explicitly selected local test backend.
WeftDhtStore<K> takes Arc<K> where K: DhtKv. The trait has async put(Vec<u8>, Vec<u8>) and get(Vec<u8>) -> Result<Option<Vec<u8>>>. InMemoryDhtKv is an in-process backend, not a running DHT node.
| Record | Exact key pattern |
|---|---|
| Manifest | /weft/v1/manifest/{root} |
| Chunk | /weft/v1/chunk/{chunk_id} |
| Availability | /weft/v1/availability/{root} |
Use the associated manifest_key, chunk_key and availability_key helpers rather than duplicating key construction.
With the dht Cargo feature, live::store_from_handle(weave_dht::DhtHandle) creates the implemented adapter over an existing live handle. connect_with_bootstrap and connect_primary_trio are standalone connection helpers; live connectivity still depends on reachable bootstraps and current service state. Do not invent a weave_dht::Node adapter when the actual API is DhtHandle.
The SDK can supply its shared network handle. Starting a local Weft store or an in-memory KV instance does not start the network. FailClosedDiscovery is deprecated and always returns unsupported; it is not a production discovery backend.
Publication writes chunk records, then the manifest, then availability. There is no atomic transaction across these keys. Availability is a provider claim and cannot guarantee durable storage, remote reachability, signature authority or successful later retrieval. Use the real signing flow and fetch checks.
