Read a context's changes after a position

A context's changes after a position, in commit order. Each entry is a pointer naming the kind of change, the thing changed (subject), the acting entity, the time and the act. No entry carries content: read the subject through its own endpoint, under your own standing. A subject you can no longer read is still pointed at, and its own read refuses it. A change to one of a resource's content blocks names the resource as its subject and the block as block.

Omit after to start: the answer has no entries and a through at the present, never a tail of history. Hand through back as after to resume. A position is opaque and is valid only for the context it was issued for. Every answer says how far it looked (through) and whether more exists (has_more).

This is a change hint, not a cache-invalidation guarantee. The feed never announces an admin act, such as an erasure or a scrub. A consumer that mirrors content must periodically re-read the subjects it holds and drop whatever is refused: that re-read is how erased or scrubbed content leaves a mirror.

The consumer contract.

Record through before reading the bodies an answer points at, never after. A change that commits between the bodies read and a later through is behind the recorded position, and is lost. A change seen again after an early through costs one redundant re-read.

An edge entry names the edge (kb_edges and the edge id), not its endpoints. To learn which resources it touches, read the edge.

An edge appears in the feed of its own home context, not in its endpoints' contexts. An edge's home is its source's home when the edge is asserted. A later move of the source leaves the edge where it was, so an edge asserted before a move stays in the old context's feed. An edge homed elsewhere that touches a resource homed here is not in this feed.

resource_departed is a deletion or a move, and does not say which. Treat it as "re-resolve this resource": it may still exist in another context you can read.

A scrub of a property is not announced. Re-read the properties you hold on the same periodic cadence, not only on a feed hint. Re-read open_meta keys with GET /api/resources?ids= and sections=open-meta. GET /api/resources/{id}/facets covers facet asserts only: a key inside open_meta, whatever its name, is not a facet assert, and that read returns no row for it.

GET /api/resources?ids= (up to 256 ids) is the cheap periodic sweep: it returns updated, body_hash and body_storage, and with sections=open-meta the open_meta tier, for exactly the ids you can still read, and leaves out the rest, without downloading a body.

{ "entries": [ { "act": "693918ad-8953-41e1-96e4-6badbeea0fc6", "actor": "b4172a54-df0e-4918-8f0c-143e6e6d9830", "block": "2521afcc-965b-4a33-b154-400abd5695f5", "kind": "string", "occurred_at": "2019-08-24T14:15:22.123Z", "subject": { "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "table": "string" } } ], "has_more": true, "through": "string" }

Read a context's changes after a position

Request

Responses