Determinism is the whole game
If two correct implementations can encode the same record into two different byte strings, they compute two different hashes, and the network silently splits. So every identity-bearing structure has exactly one legal encoding.
| Layer | Rule |
|---|---|
| Records | RFC 8949 core deterministic CBOR - shortest-form integers, definite lengths, map keys sorted bytewise on their encoded form |
| Signatures | Tagged COSE_Sign1 (RFC 9052, tag 18), EdDSA, exactly three protected headers, empty unprotected map, external_aad = h'' |
| Media | BitTorrent v2 merkle trees (BEP 52) - 16 KiB blocks, SHA-256, padded to a power of two with 32 zero bytes |
| Display | Typed lowercase base32, prefix-tagged. Display only. Identity is always the raw bytes |
Note the deliberate trap avoided: RFC 7049's canonical form sorted map keys by length first. RFC 8949 core deterministic sorts bytewise. Picking the wrong one produces a codebase that looks correct and hashes differently.
Verified against something that isn't us
A reference implementation agreeing with itself proves nothing. The Go node, an independent Python implementation, and unmodified third-party libraries all produce the same identity bytes:
- libtorrent 2.0.8 generates a byte-identical torrent info dictionary - the merkle construction is right, not just self-consistent
- cbor2 and pycose parse and verify our envelopes without special handling
- Boundary fixtures cover every block and piece edge: 0, 1, 16383, 16384, 16385, 32767 ... 524289 bytes
The full interoperability commitment is published so a third implementation can be written from the document alone.
The kid header is a hint
Key identifiers in signed envelopes exist so a verifier can find a candidate key quickly. They are never trusted on their own. A signature is valid because it verifies against a key the verifier already had reason to accept - never because the envelope named one.
Four identities
| Name | Answers | Changes when |
|---|---|---|
| rendition_file_root | Are these the exact bytes? | A single file's bytes change |
| manifest_hash | Is this the same described set? | Any rendition or metadata changes |
| bt_v2_infohash | Which swarm do I join? | The torrent's file set or piece length changes |
| upload_record_id | Who published this, when? | Never - it is a signed historical fact |
Re-encoding a video at a new bitrate changes the first three and leaves the fourth alone. That is the distinction one identifier cannot express.
Facts and claims are stored differently
A fact is something the bytes prove: this hash, this signature, this timestamp in this signed record. A claim is something an actor asserts: this is popular, this is safe, this is mine.
Facts are verified. Claims are attributed. Confusing the two is how a network ends up treating a confident assertion as evidence.