Search selfstore
v1.8.21

selfstore vs Automerge

TL;DR: Same relationship as Yjs: Automerge merges concurrent edits and keeps their history, selfstore gives the result an encrypted home the user owns. Automerge alone if you need history; both if you also need the backup.

What Automerge is

A JSON-document CRDT with a compact binary format, a Rust core compiled to WASM, and something Yjs does not emphasise: history. An Automerge document keeps its changes, so you can ask what a document looked like before, and attribute who changed what. automerge-repo adds the networking and storage adapters around it.

If your requirement is “never lose a concurrent edit, and let me travel back”, this is the tool, and selfstore does not attempt either.

What selfstore is

The loop around whatever your data is: an IndexedDB working copy, portable encrypted ZIP backups on an open spec, durable homes on storage the user already owns, no server. Its own merge is last-write-wins with no history at all - an overwrite is final locally, which is stated plainly in the limits.

They compose

An Automerge document saved with Automerge.save() is bytes, and bytes are what a selfstore file holds. Store each change (or each saved document) under the id of its own content and selfstore’s union-by-id merge carries every device’s copy through to the other side, where Automerge folds them back into one document. The reasoning is identical to the Yjs page, which carries the worked example.

Automerge selfstore
Solves Concurrent edits + history Durability, portability, destinations
History / time travel Yes No, keep dated backups instead
Local persistence An adapter you add Built in
Encryption Yours to build Built in, AES-256-GCM + Argon2id
User-holdable backup The document itself A spec’d ZIP of the whole app
Size on the wire Compact binary Whole-state, no delta sync

Use Automerge alone when

Use both when