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.
Conversation
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
Thick clients with a sync-style model like Dropbox, Git, Craft, and Obsidian are easier to fit with this, although often still don't have a user-facing flat file format outside of explicit export.
2
3
Assuming we have 2 files:
1. Append-only log of user actions (fragments of it [not all] are loaded into memory when the user opened the app)
2. Reducer that converts those actions to a flat file with a pointer which last action id
Would you say this is achievable, no?
2
1
Indeed; this is what Orbit does.
Cool! I haven't checked Orbit but also working in this area with .
I was thinking to use iCloud Drive, stores a flat file to get "free" sync across user devices.
Those 2 points came to my mind but I'm not sure if it's feasible. Glad that it works with Orbit.