3 ms·
Couldn't agree more. I just developed a local-first read later software using CRDT technology. aka https://hamsterbase.com/ https://hamsterbase.com/ 1. all
by hamsterbase 3y ago
Couldn't agree more.
I just developed a local-first read later software using CRDT technology. aka
https://hamsterbase.com/ https://hamsterbase.com/
1. all data is stored locally, one page corresponds to one CRDT file. CRDT file is a single source of information
2. use sqlite as cache for query and full text search.
3. use the version of CRDT as the file name. It is guaranteed that there will be no duplicate file names and never file content changes. Only files are deleted and added.
In this architecture
Users could synchronize their data with any intermediate media. Such as hard disk, iCloud, http interface, webdav. It is guaranteed that there will always be no conflicts.
- wg0 3y agoThese ideas seem pretty doable for a single user note taking app but as soon as you include another collaborator, you've a whole another problem of different levels of conflicts, CRDTs and what not. Becomes lot more harder when you have some 100 agents in the field, taking orders on their mobile devices and you have to do full double entry book keeping even when offline.
- mgkimsal 3y agoAnd... you've got a large list of customer, contact and historical info to allow access to. Sending that down to people so they have it locally becomes at least a bit of a privacy/security concern.
- hamsterbase 3y agoThis solution is suitable for processing documents. For example, figma uses a technique similar to CRDT. It is not suitable for processing orders.
- preseinger 3y agoif two different users modify the same version of the same document in different ways, how do you resolve that conflict without losing information?
- hamsterbase 3y agoI have recorded all the operations of a document. Each operation has an id . When the document is loaded into memory, it has a unique uuid as the agent id. If the current version is hash(a1 b2 c3) If two people edit the document at the same time the name will become hash(a1 b2 c3 e4) hash(a1 b2 c3 d4 d5) After merging, the document name will become hash(a1 b2 c3 d4 e4 d5) a1, b2 is "Lamport timestamp" https://en.wikipedia.org/wiki/Lamport_timestamp https://en.wikipedia.org/wiki/Lamport_timestamp the full version (a1 b2 c3 e4) is “vector clock” https://en.wikipedia.org/wiki/Vector_clock https://en.wikipedia.org/wiki/Vector_clock
- preseinger 3y agoif d4 and e4 are conflicting edits, then how do you resolve them? say (a1 b2 c3) is "abc" -- (a1 b2 c3 d4 d5) is "abxx" and (a1 b2 c3 e4) is "aby" what is (a1 b2 c3 d4 e4)? it isn't "abxxy" or "abxy" or "abxxy" or anything else, because d4 and e4 are concurrent/conflicting updates, which have no single well-defined resolution (without additional information) meaning, this is a conflict if you just say that this resolves to (a1 b2 c3 e4) then this is LWW but you've lost the information in d4 and d5, so whoever was agent d has written information that was good for a little while, but then ultimately lost after merge, right? so this isn't consistent in any useful way?