A CID (content identifier) is a self-describing hash that names a block by its content. It is the canonical form of a reference.

This page defines the cid value type, an alias of link used wherever a Hypermedia blob points at another blob. Its formal schema is attached as the schemaDefinition in this document's metadata, so the app can show it.

A CID packs a version, a codec and a multihash into one value, so the name says how to decode the bytes and how to check them. Hypermedia blobs are CIDv1 with the dag-cbor codec (0x71). Files are dag-pb (0x70) with raw (0x55) leaves. In text a CIDv1 is base32: a dag-cbor blob starts with bafyrei… under SHA-256 and bafy2bza… under BLAKE2b-256, and SHA-256 raw and dag-pb blocks start with bafkrei… and bafybei…. In DAG-CBOR a CID is tag 42, and in DAG-JSON it is spelled {"/": "bafy…"}.

Two hash functions are in use for the same codec. The Seed daemon names the blobs it creates with BLAKE2b-256. The SDK, CLI and apps use SHA-256. Both are valid names for the same bytes and the daemon accepts either on ingest, but they are different names: a Ref that points at the SHA-256 CID of a Change does not reach a copy stored under its BLAKE2b CID. So publishers must supply an explicit CID for every blob that another blob references. A version string is the CIDs of the head Changes, sorted and joined with .. See Signed Blobs and URLs.

See also

Signed Blobs: encoding, CIDs and the hash rule for publishers.

link: the kind a CID is stored as.

blob: the envelope whose bytes a CID names.

Files: dag-pb and raw CIDs.

URLs: version strings made of CIDs.