Many
Stores

Everything of S1 lives under one directory on the instance that runs it. The server keeps only mirrors (the catalog) and its own instance data (shares, devices, settings).

The artifacts plugin saves a new version. It writes the content as a blob first, then commits a document that names the blob's hash. The order is the whole trick.

An export reads the log at some head, say 42, and copies every file in blobs/. Any blob a record up to 42 refers to was written before that record, so it is in the directory. The session does not have to stop. An import replays the log into a fresh session.sqlite, copies the blobs and checks their hashes.

Derived data rebuilds itself

The artifacts plugin also keeps a full-text index over artifact contents, in its own SQLite file under derived/artifacts/, because searching documents one by one is too slow. The index holds nothing of its own: every row can be recomputed from the artifact documents and the blobs they name. So it is never exported or synced. A routine compares the index with the documents whenever the object starts and fills in whatever is missing:

const Artifact = defineState("artifact", {
  schema: obj({ title: str(), type: str(), versions: arr(obj({ blob: str(), size: int(), at: int() })) }),
  version: 1, keyed: true, persist: true,                         // key = artifact name
  initial: () => ({ title: "", type: "text", versions: [] }),
  checkpointWhen: () => true,
});

host.serve(ArtifactStore, (_, self) => {                          // local, input-less
  const artifacts = self.state(Artifact);
  const blobs = self.get(SessionBlobs, {});                       // app layer: the session's blob store
  const info = self.get(SessionInfo, {});
  const index = self.open(async () => openIndex(join(info.init.value.dir, "derived/artifacts/index.sqlite")),
    (db) => db.close());

  self.routines.loop("catch-up", async (ctx) => {                 // the index repairs itself
    for await (const name of artifacts.keys()) {
      const a = await artifacts.get(name);
      if (a && index.value.versions(name) !== a.versions.length)
        index.value.put(name, a.versions.length, await blobs.read(a.versions.at(-1)!.blob, ctx));
    }
  });

  return {
    save: async ({ name, title, type, content }, ctx) => {
      const bytes = utf8(content);
      const blob = await blobs.put(bytes, ctx);                   // 1. content first
      await self.tx(ctx, async (tx) => {                          // 2. the document naming it
        const a = await tx.draft(artifacts, name);
        a.title = title; a.type = type;
        a.versions.push({ blob, size: bytes.length, at: Date.now() });
      });
      const version = (await artifacts.get(name))!.versions.length;
      index.value.put(name, version, content);                    // 3. derived, best effort
      return { version };
    },
    search: ({ query }) => index.value.search(query),
  };
});

The same routine covers three situations without any special code:

Both cases work because nothing ever changes in place: a blob is final when written, and a derived index has no data of its own. history.sqlite breaks both assumptions. Its rows change in place, and they are the only copy.

Suppose every store ships its own changes to the desktop as it pleases: session.sqlite in batches of commits, history.sqlite as a stream of its own. The agent edits x.ts; the edit is recorded in both stores.

The fault is not in either store. Each one is consistent on its own. What is missing is an order across stores: which change of history.sqlite happened before which commit of the log.

The session gets one counter, kept in memory by p3's sync layer on the driver. Every store, in the transaction that commits a change, takes the next position and writes the change with that position into its own outbox. Positions increase across all stores of the session, so they order everything.

After the edit the two outboxes look like this:

The sync layer cuts a batch at a position P: every change of every store with a position up to P. A replica applies a batch in position order, store by store as the positions say. After applying a batch it holds exactly the state the driver had at P, for all stores together. The bad states of the previous chapter cannot happen: a replica has position 8 only together with position 7.

Cutting needs one rule. The counter hands out position 12 to a store whose transaction has not committed yet, while position 13 already committed elsewhere. A cut at 13 would miss 12. So the counter remembers the positions it handed out that are not committed yet, and a cut goes only up to just below the smallest of them. A transaction that fails gives its position back as a gap; gaps are fine, order is what counts.

A plugin store must turn its writes into change records. For JSONL that is the appended lines themselves. For SQLite it would be a burden on every plugin, except that SQLite has the session extension: it watches tables and turns whatever SQL ran into a changeset, a compact list of row inserts, updates and deletes. Another database applies it. node:sqlite exposes it. This ran on slayer with Node 24.4.1:

import { DatabaseSync } from "node:sqlite";
const laptop = new DatabaseSync(":memory:"), desktop = new DatabaseSync(":memory:");
// both: CREATE TABLE edits(id INTEGER PRIMARY KEY, path TEXT); CREATE TABLE outbox(pos INTEGER PRIMARY KEY, cs BLOB)

const session = laptop.createSession({ table: "edits" });
laptop.exec("BEGIN");
laptop.exec("UPDATE edits SET path = 'b/' || substr(path, 3) WHERE path GLOB 'a/*'");  // plain SQL
const cs = session.changeset();                                                      // 54 bytes for two rows
laptop.prepare("INSERT INTO outbox VALUES (?, ?)").run(7, cs);                       // same transaction
laptop.exec("COMMIT");

desktop.applyChangeset(cs);   // desktop now has b/x and b/y

So p3 could offer plugins a session SQLite as a store kind. The plugin opens it, writes SQL in transactions, and the wrapper does the rest: start a session on the plugin's tables, take a position before COMMIT, write the changeset to the outbox table, commit. The plugin never sees positions or outboxes.

Why not one shared outbox file for all stores? Because the change and its record must commit together. With a shared file, the plugin commits its rows, the process dies before the changeset reaches the shared file, and the changeset is gone: it existed only in memory. The rows are on disk and will never be shipped. Each store therefore keeps its outbox inside itself, in the same transaction as the change: an outbox table in a SQLite database, the record in session.sqlite's commit, the lines themselves in a JSONL file.

Export and import use the same pieces. An export takes a snapshot of every store at one cut position P (the log's export(), VACUUM INTO for each plugin database, the blob files, the JSONL files) and writes them into one archive with P in its manifest. An import restores each snapshot into a fresh session directory. Later changes, on a replica, continue from P.

Chord's part is small. Its storage (and Durable's) must be wrappable: the sync layer sees every commit's writes in order and gets a hook inside the commit to take a position and write the outbox record in the same transaction. And the storage needs export(), replay() and head(). The counter, outboxes, batches, store kinds and the session directory are p3's.

One consequence for an open question: ordering no longer needs Chord's documents to live in Durable's storage. If they had their own file, it would be one more store with its own outbox, ordered by the same counter. Sharing the storage would only save a file.