It's astonishing to me how difficult it (still) is to design a syncable local-first data model.
I keep thinking I've found a decent way, then realizing its flaws, then despondently noticing that the flaws were already discussed in Ink & Switch's article: inkandswitch.com/local-first.ht
Conversation
I don't understand this, requirement 4 isn't a difference in degree it's a difference in kind. It dictates a diff based write log with a heuristic 3-way merge resolver.
Also if you discard the single source of truth assumption then you get git.
1
The authors conclude something similar w.r.t. requirement 4. You're right that Git seems like a reasonable conceptual model. Awfully hard to use it as a backend datastore for an app in practice, though. And you probably want indexing/querying features…
1
3
As long as the DB is fully recoverable by replaying the history of change nodes it doesn't matter what the datastore is. Indices are orthogonal side effects of the relevant history of changes / commands.
1
1
Replying to
This is totally true, but on a practical level, I've encountered enormous and persistent complexity in the details of constructing and maintaining snapshots by replaying events.
Replying to
Interesting, I would expect large space costs more than complexity costs. Have you talked to about this?
1
Storage is cheap; my attention and implementation time are extremely! :)
I haven't heard on this but always curious to hear more views.
1