The schema is a string of exactly 59 characters matching ^bafyrei[a-z2-7]{52}$. The rules that give it meaning:

Derived, never chosen. The creating Node blob carries no id. Its own CID, computed over its DAG-CBOR bytes with SHA-256, is the node id. Every later Node blob for the node carries that CID in id. This is the same shape as a Change and its genesis: the first blob has none, every successor names it.

One hash for ids. The daemon stores blobs by BLAKE2b multihash and the SDK by SHA-256, and both are valid names for the same bytes in storage. A node id is always the SHA-256 form, so every peer derives the same id for the same creating blob whatever its store uses.

Unforgeable. To claim an id you must present a Node blob whose CID is that id. A later Node blob naming an id whose creating blob a peer has not seen is stashed until the creating blob arrives; the id is a dep link, so authority-first fetching retrieves it before anything that depends on it. Authority to update is then evaluated against that node, authority to create against the parent.

Never reused. A tombstoned node keeps its id forever. There is no generation counter because an id has exactly one life.

The space root. The root's creating Node blob is deterministic: signed by the owner with ts 0, kind space, no id, no parent, no name, and heads naming the owner's deterministic genesis Change. Anyone can compute it from the owner's key, so the root id needs no lookup, and the bare URL hm://<owner> is an alias for hm://<owner>/<rootId>.

Node ids appear in the mutable URL of a resource, hm://<space>/<node-id>, and in full-context links as the n query parameter next to a pretty path; see Placement. Because an id always matches the pattern above and a name never may, a URL's first segment is unambiguous.

The identity of a document is its path, and the identity of a comment or contact is a TSID derived from timestamp and blob bytes. A document's path changes on every move and a TSID is a different scheme per type. Both become the node id. For migrated documents the migration treats the earliest Ref blob for a path and genesis as the creating blob, so a migrated document's id is that Ref's SHA-256 CID and every peer agrees on it; each HM24 generation at a path becomes its own node sharing the name. For migrated comments and contacts the first blob of the TSID is the creating blob.