I believe the merging operation of CRDTs is also required to be associative for convergence (besides commutative and idempotent). Also, wouldn't using grow-only sets with tombstone tags lead to the size of states to grow indefinitely over time, even if the size of the set itself remains constant?
You can implement a garbage collection to solve for this. I imagine one way would be to save the last sync from all your known users. If the last sync date for the known users is x date. In theory you can push a garbage collection message to all distributive clients to delete rows with tombstones with that dates prior to x date.
@Chris-cx6wl how to make sure you know all of your neighbors? You could, at some point in the future meet a neighbor that hasn't synced all of the state yet. This is the same problem faced by automerge and that's why they haven't figured out a gc algorithm yet
@14:40 how are y and z applied if the first message (x: 300) has a later timestamp? Wouldn't they all be ignored since 2019-11-05 is later than all the other messages?
Awesome talk but sad to see almost 5 years later and the industry is still headlong into housing your data for themselves. Makes sense but it’s an architecture that drives terrible impulses
I made a React library from that code. It's called Evolu. Thank you James for your enlightenment.
Nice!
Off-topic, but so nice to see how Revolut, N26 and others saw market fit in those manual budgeting apps.
why are the sleeping?
and why is it only very few noticing this?
Bean bags
I believe the merging operation of CRDTs is also required to be associative for convergence (besides commutative and idempotent). Also, wouldn't using grow-only sets with tombstone tags lead to the size of states to grow indefinitely over time, even if the size of the set itself remains constant?
You can implement a garbage collection to solve for this. I imagine one way would be to save the last sync from all your known users. If the last sync date for the known users is x date. In theory you can push a garbage collection message to all distributive clients to delete rows with tombstones with that dates prior to x date.
@Chris-cx6wl how to make sure you know all of your neighbors? You could, at some point in the future meet a neighbor that hasn't synced all of the state yet. This is the same problem faced by automerge and that's why they haven't figured out a gc algorithm yet
Agree, tombstones just kick the can down the road
@14:40 how are y and z applied if the first message (x: 300) has a later timestamp? Wouldn't they all be ignored since 2019-11-05 is later than all the other messages?
It looks at both the key and the timestamp
lying down totally helps understanding a complicated js talk!! 🤣
Awesome talk
nice talk!
Awesome talk but sad to see almost 5 years later and the industry is still headlong into housing your data for themselves. Makes sense but it’s an architecture that drives terrible impulses
"256 lines of javascript with no dependencies, because dependencies suck". What about that uuidv4()?
he literally addresses this in the talk - it depends on uuid and murmurkesh - hardly huge dependencies