A link has a source blob, a kind, and exactly one of a target blob (by CID) or a target resource (by node reference, optionally at a version). It may carry an anchor, the block or field in the source where it was found, and a fragment, the block or range in the target it points at.

The earlier Stem page asked whether everything can be a named link with a weight made of flags. The answer Stem gives is yes with the flags fixed per kind: a link's kind determines its flags, so peers that agree on the kinds agree on the flags, and no weight needs to travel. Weights remain a runtime convenience a daemon may compute for its scheduler and collector.

The columns mean:

Dependency. The target must be applied before the source has meaning. The fold follows dep and prev; a Change whose dep target is missing is stashed.

Authority. The target is evidence of the source's right to exist. Fetch serves proof targets before their sources, and the authority graph is built from them.

Placement. The target is where the source sits in the tree. parent links are what make a move one blob: children hold a parent link to an id, not to a name.

Presentation. The target is needed to render or validate the source fully. A reader following a scope with the files facet fetches file targets; the schema target is fetched to validate and to show typed attributes; embed targets are fetched for a full-fidelity rendering but a missing embed is a broken embed, not a broken document.

Reference. The target is mentioned. Citations and backlinks are the reverse direction of link, mention, embed and target.

Retained with source. A peer that keeps the source under its policy must keep the target: dependencies, proofs and files. Embeds, links and mentions are not retained; a peer that follows a document does not thereby follow everything it cites.

The earlier page's five flags map onto these columns: state dependency is dep and prev; retention is the last column; presentation dependency is schema, file and embed; ordinary dependency is link and mention; authority evidence is proof. Parent documents, which the board left open, are parent links from child to parent, and the reverse direction (children) is a derived fact on the parent, not a link.

Five kinds are structural and the handler emits them from the fields every blob of that type has: dep from Change deps and Node target.heads; prev from Node prev and Snapshot prev; proof from Node proof and Grant proof; parent from Node parent; schema from Node kind and Snapshot schema. No kind can switch them off.

Four kinds are content links and the handler finds them where the Kind descriptor's link rules say to look: a JSON Pointer into the state value, and the kind to emit for hm:// and ipfs:// references found there. The document kind's rules name the block tree: an Embed block or inline embed produces embed, a Link block or link annotation produces link, an inline embed whose text is the object replacement character produces mention, an Image, File or Video block produces file. The comment kind's rules name /target for target and /body for the same block rules as documents. The contact kind's rules name /subject for target. A third-party kind declares its own.

This is how a new kind arrives without a protocol change: its descriptor says where its references are, and the handler, sync, retention and backlinks work for it on the first day.

The board asked whether the runtime needs hyperedges, because a comment or an embed points at a resource at a version, and a version can be several heads. Stem answers with the record shape: a link to a resource carries a node reference whose version field is the sorted head CIDs joined with ., which is one string. The link is binary (source blob to node reference) and the version is a property of the edge. Nothing needs reifying.

Whether one physical blob may carry several labels (CID, a Git object id, a Nostr event id) is left open. Stem's reading stands: a label would be a fact about a blob emitted by a handler that recognised the foreign id, and the store would index labels so that a link written in a foreign namespace resolves to the local blob. No core kind needs it, and it is tracked in Open questions.

The shipping tables are described in Database structure.