a cid is the name the bytes give themselves - the fixed-size digest of a piece of content, used AS its identifier, so the name and the integrity check are the same object.
The pipeline that turns bytes into this name - and the invariant the name feeds.
Hand-authored SVG for this glossary, 2026. Pipeline stages verified against node.rs (canonical_bytes, line 133) and cid.rs.
Two kinds of identifiers, precisely, because the question "what database tracks these?" is correct for every other ID you have met. ISSUED identifiers - user IDs, order numbers, UUIDs, primary keys, DOIs - are assigned by an authority that must remember the assignment forever; the binding is stored knowledge, and losing the database voids every ID. DERIVED identifiers are computed from the thing itself: the binding is never stored anywhere because anyone can recompute it on demand. A cid is derived - the registrar is arithmetic, running identically on every machine with zero coordination. Storage still exists (prov-store shelves nodes BY cid) but as a warehouse, never a registry: fetched bytes are re-hashed by the verifier, so the store can lose or serve, but can never make a false binding true. Uniqueness is enforced by collision resistance instead of a uniqueness constraint - about 2 to the 128 work to forge a duplicate. If cids were issued, offline verification, anyone-can-serve, and no-global-authority would all collapse; the thin waist hangs on names that carry their own truth.
Etymology and backstory
"CID" as a term was popularized by IPFS around 2015 (their spec reads it as Content IDentifier), but the idea is decades older: name a thing by the hash of its bytes and nobody can swap the bytes without changing the name. Git has done this since 2005 - every commit hash is a content address. The intellectual root is Ralph Merkle's 1979 work on hash trees: build structures where each node commits to its children by hash, and one root hash authenticates everything below it.
Ecosystem
IPFS CIDs are elaborate self-describing strings (multibase, multicodec, multihash - prefixes that say which encoding and which hash function). Git uses raw SHA-1, now migrating to SHA-256. NDN names data hierarchically and signs the names. BitTorrent infohashes, Nix store paths, Docker image digests - content addressing appears everywhere infrastructure has learned not to trust its transport.
In codexproof
the cid is deliberately NOT an IPFS CID - it is the raw 32-byte BLAKE3 digest of a node's canonical bytes, presented with a b3- prefix in HTTP paths (the route test fetches /prov/b3-deadbeef). The central invariant of the whole paper: the 32-byte target of every typed PROV link IS the cid of its parent, so the lineage graph and the integrity commitment are one structure. cid.rs computes it; canonical_bytes in node.rs (line 133) defines exactly which bytes get hashed.