Part of Stem. This page defines the link record. Links are never signed; the indexing peer derives them from blobs it has verified.

A link says: this blob refers, in this way, to that blob or that resource.

Fields

field	type	required	meaning
`source`	CID	yes	The blob the link was read from.
`kind`	link kind	yes	What the link means.
`blob`	CID	no	The target blob, when the link names a blob.
`node`	node reference	no	The target resource, optionally at a version, when the link names a resource.
`anchor`	string	no	Block id, range or field path inside the source.
`fragment`	string	no	Block id or range inside the target.

Exactly one of blob and node is set.

Rules

Links are the only thing downstream code reads. The sync layer fetches the targets of dependency and authority links before applying a source and the targets of presentation links afterwards; the retention layer keeps targets of retained links while their source is kept; the audience layer maps each blob to the nodes whose state it belongs to by walking dep and file links from each node's heads, which is how a blob gets its readers; the citations and backlinks API lists reference links by target; notifications fire on mention and target links. A link whose target blob is not held creates a placeholder, as today. A link to a resource is resolved to the node by id, so a move never breaks it.

Today (HM24)

blob_links(source, type, target) for CID edges and resource_links(source, target IRI, type, is_pinned, extra_attrs{a, f, v}) for IRI edges. The two tables merge into one record with the nine kinds, and the IRI target becomes a node reference.

Example

{
  "source": {"/": "bafyreicommentsnapshot000000000000000000000000000000000000"},
  "kind": "target",
  "node": {"space": {"/": {"bytes": "7QEE...Starlight"}}, "node": "bafyreiujzdegxdncf32epf3dhodzdocis2jhtlgmxgedn73u55xtplpft7", "version": "bafyreib3nq5mkq2w7e4w3slkz2n7m7xq6x4hw4x2x3vl6tz2cmkfnq5a3e"},
  "fragment": "b7[0:12]"
}

Fields

Rules

Today (HM24)

Example

See also