Maybe someday automerge’s serialization format will be as durable and universal as SQLite’s, but in the meantime, it’s certainly not amenable to casual concurrent local access in some user script.
Conversation
Of course, SQLite leaves you to solve syncing. The typical approach is a write-only log of events (CRDT mutations or otherwise) which can be replayed across replicas. Snapshots of entity states are computed from queries across these events.
1
17
That’s the approach Orbit takes: simple event structures (simpler than CRDTs, sacrificing some of their key guarantees to reduce complexity), with well-defined merge operations, in a SQLite db. Users can write scripts to insert their own events if they like.
2
1
24
I’m still not satisfied with this. Reading/writing data yourself requires using Orbit’s libraries or a SQLite library and an understanding of the schema. I’d like to just expose the data as plaintext, but I’m not yet sure how to achieve that practically.
3
21
One approach is to define Git-style “plumbing” CLI primitives which offer plaintext-like I/O to your data structures. Another is to define a FuseFS layer, style.
1
13
Switching gears: another hard thing about implementing this type of data format is that web browsers demand their own implementation. kindly implemented an IDB-based Orbit backend. Excited about absurd-sql here:
1
19
Orbit’s cloud server has its own (third, ugh) backend implementation, which it uses to offer APIs, aggregate analytics (for my research), and services like study reminder notifications.
1
12
I see now why people don’t generally do this. It was a huge amount of work. I’m honestly pretty frustrated with myself for shaving this yak: too much time polishing my telescope, too little time looking at stars.
1
3
51
As it happens, Orbit’s implementations are quite general (i.e. they have almost no specific knowledge of Orbit’s structures), so perhaps they’ll be of use to others. See store-*, sync, and backend packages here:
4
34
Great report from the front lines—thanks for sharing!
One observation that makes is that web browsers aren't a good fit for local-first. They're fundamentally thin clients with throwaway local caches. Maybe that's part of the mismatch for Orbit?
3
11
Yes, I think this is roughly right. When using a web browser, I think the metaphor is that you're hitting the cloud API. When you're using the native apps, you're reading/writing some local file, which then gets synced to cloud. This is my instinctive interpretation…
Yes, and I feel that the model of "server is authoritative and does everything important, client is just a thin UI" works mostly great for use cases like ecommerce, ridesharing, weather, maybe social media.
1
2
The local-first approach is intended for document-creation programs. Writing tools, programming tools, photo/video editing, UI design, etc.
Anki clearly fits into this category, but Orbit feels like it might have better affinity with the thin client model?
8