Great new work from : inkandswitch.com/cambria.html
Local-first software is a great aspiration, but iterating on decentralized data structures is indeed a nightmare I've been living with as I build . Excited for these ideas on more predictable data evolution.
Conversation
I wonder how to test / formally model the consistency property you'd want the lenses to describe.
3
7
I've maybe made the problem needlessly hard on myself by using content-addressable identifiers for CRDT log structures (including their parent pointers). Did that so I could serialize to IPFS or similar, but it means I have to rebase the whole tree whenever the structure changes.
4
12
If you perform the conversion on read (and after validating the hash) as suggested in the article I think this should be fine?
1
The problem is the log’s parent ID, which is the hash of the parent’s contents at write time. You can’t run the lens on the ID; you need some complex version-specific lookup table.
1
Ah, so you hash the whole content. I was thinking of the git model where commits / change operations are hashed (including a pointer parent commits).
1
Ah, er, it does work like Git, where logs (i.e. commit operations) are hashed (including the parent pointer). The issue is that if you change the commit format, even for one commit, all the downstream hashes change.
1
I understand the need to rewrite children when changing parent but not the need to rewrite history. Wouldn’t you want to only change the format for new commits and leave history unchanged?
1
Replying to
Ah, I’ve been all tangled up. You’re right: you could leave history unchanged if you had lenses like this. I’ve been rewriting history to avoid migrations and adapters.