Expand description
ContentId — what a provider record is keyed by, at the granularities the L7
dig.getAvailability shapes use, mapped consistently into the crate::Key keyspace.
A DIG Node advertises the content it holds so others can find it. The unit of advertisement is a
ContentId, which matches the availability granularities of the peer network (L7 spec §9):
| Granularity | Fields | Answers |
|---|---|---|
ContentId::Store | store_id | “does a peer serve this store at all?” |
ContentId::Root | store_id + root | “does a peer have this generation (store_id, root)?” |
ContentId::capsule | store_id + root | the immutable capsule store_id:root (alias of Root) |
ContentId::Resource | store_id + root + retrieval_key | “does a peer have this resource within the capsule?” |
Keyspace mapping. Each ContentId hashes to a 256-bit Key via SHA-256 over a
canonical, domain-separated byte encoding (ContentId::to_key). The domain separation (a
one-byte tag per granularity) guarantees that a store key, a root key, and a resource key are
distinct points even when they share the same store_id — so a store-level provider record and a
resource-level provider record for the same store never collide in the DHT. The encoding is
canonical (fixed field order, raw 32-byte hashes) so every implementation derives the identical
key for the same content — a frozen wire contract.
Enums§
- Content
Id - A DIG content identifier at store / root(capsule) / resource granularity — the key a provider record is stored under and a lookup asks for.