You state “I will explain later” a number of times. It would be better to hold off introducing the topic until it is more contextual to the reader. It breaks the flow of your writing.
The text could be broken up into more paragraphs.
You could use some more headings to break up sections:
1. What is a CRDT 2. What problem do they solve and some simple examples. 3. State based solutions 4. Operator based solutions 5. Join-semi lattice 6. Putting it all together.
In your second join-semilattice diagram it’s not obvious that the two blue nodes are being merged into the green.
The pseduo code you’ve included for the g-counter, 2p-set and or-set are quite unintuative imo.
I’m probably not your target audience but I read a lot of academic writing now and I think this could be better.
Content is great though, didn’t know what a join-semi lattice was before hand so thanks a lot!
And like somebody else said in comments, most articles on CRDTs assumes the audience are math people. I'm working on a series of blog posts that slowly uncover how real-time collaboration algorithms and data-structures work – with all the necessary math concepts explained in simple terms first. Will publish them out as soon as they take a good shape.
Good luck with your articles, where can I read them once you have published them?
Great that you learned something. The CRDT papers don't explain the join-semilattice that much, it's only mentioned briefly, even though it's important in order to understand the theory behind CRDTs.
CRDTs are just a way to send to send data between parties so that all parties end up with the same thing after receiving all messages, even if they receive them out of order. The way the messages are encoded is the math part, ensuring that you can keep applying these functions to your existing state to always get to the final state. That's where the associative/commutative requirements come from.
Note that there are operation-based (sending how something should be updated) and stated-based (sending what it should be updated to) CRDTs and they have different semantics and use-cases.
CRDT are a type (e.g. a String, a Vector, an Integer) that has limitations with how it can be mutated.
For example, you can create an Integer CRDT that can only be `increased` and `decreased`, or a String CRDT that can only have characters `inserted` and `deleted` at given positions.
These limited mutating capabilities are chosen so that there never can be any conflict.
I used CRDT to create a collaborative graph tool using the 2P2P-Graph. There is a pretty good Wikipedia page about CRDTs, which I recommend you read. It can definitely be applied to many use cases were the datatypes such as counters, sets, maps, sequences, etc are used.
