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 |
|---|---|---|---|
| yes | The blob the link was read from. | |
| yes | What the link means. | |
| no | The target blob, when the link names a blob. | |
| no | The target resource, optionally at a version, when the link names a resource. | |
| no | Block id, range or field path inside the source. | |
| 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]"
}See also
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime