selfstore vs Jazz
TL;DR: Jazz is a platform: CoValues, per-value permissions, auth, real-time sync, end-to-end encryption - and a sync server, hosted or self-run. selfstore is a library that stops at the storage loop and needs nothing hosted.
What Jazz is
An ambitious, coherent framework. Your data is CoValues - collaborative maps, lists and streams built on a CRDT layer - which replicate between clients and a sync server, encrypted so the server holds only opaque blobs. Permissions are enforced by cryptography rather than by a backend’s opinion, and it ships auth, including a local-first mode with self-signed identities.
If you are building something with several PEOPLE in it - shared spaces, per-object access, real-time presence - Jazz has thought about problems selfstore has not.
What selfstore is
Much less, on purpose. There is no framework here: no CoValues, no reactive document graph, no auth. There is a store, an encrypted file format, a merge, destinations, and the screens to connect one.
The structural difference is the server. Jazz’s model needs a sync server to be the meeting point, hosted by them or by you. selfstore’s meeting point is storage the user already owns - their disk, their Drive, their WebDAV, their bucket - so there is nothing to host, nothing to pay for, and nothing that can be switched off later.
| Jazz | selfstore | |
|---|---|---|
| Scope | Framework (data, auth, permissions, sync) | Library (the storage loop) |
| Real-time collaboration | Yes | No - carry a CRDT if you need it |
| Permissions | Per-value, cryptographic | Group members share one store |
| Auth | Built in | Not its job |
| Server | Required (hosted or self-run) | None |
| The artefact | State on the sync server | A spec’d ZIP the user holds |
Use Jazz when
- Several people collaborate in real time, with per-object permissions.
- You want auth, sync and data as one coherent thing, and running (or paying for) a sync server is fine.
Use selfstore when
- The app is one person’s - or a small group’s - and its data should live on their own storage.
- “No server anywhere” is a promise you want to be able to prove, not a deployment choice you might revisit.