foldkit-durable

The authoritative server journal for local-first Foldkit state.

Clients edit optimistically and retry when the network is unreliable. The server still needs one place that says which operations committed, in what order, and what state that order produces. A Journal is that place: for each document it keeps an ordered operation log, the current snapshot, and a cursor into the log, on SQLite.

append is the commit boundary. It decodes, validates, authorizes, reduces, assigns the next sequence, and persists the operation with the new snapshot in one transaction. Send the same operation twice and it is answered, not applied again.

It is the server half of replicated Foldkit state. foldkit-sync is the client half, and hands the journal its codecs and reducer so the server never restates the application.

Is this the right package?#

Use it when several clients or devices write one server-owned document and need an authoritative order, idempotent retries, a snapshot for newcomers, and compaction that cannot change what the history means.

Do not use it as a database for arbitrary queries (it is an operation journal), for multi-master ordering (one journal decides), or as a job scheduler (the recovery loop is one your application chooses when to run). It also does not promise exactly-once execution at an external provider; see external effects.