Thinking about it more, I’ll provide another that people will not immediately appreciate.
Any and all networked video games with some form of rollback or correction. Best effort with a fallback to Rollback might actually be the “best” ie ergonomic experience for CRDTs that are most widely used.
Again, not academically a CRDT because technically game state is not perfectly replicated to every client. Each client only gets partial game state.
Additionally, game clients require low latency syncing, which could academically be considered “coordinating”. Even tho the client actually accepts and renders the input’s results locally probabilistically before any conflict resolution / rollback is returned to the client for correction.
Again people are likely going to be pedantic but with three post now, I’d like to hope, people might see the common theme:
The most popular, highly ergonomic, best implementations of CRDTs actually break the academic rules of CRDTs.
This is a relatively typical trap of an overly academic mental model. Most real world algorithms and data types are actually more creative than their academic “rulesets”. eg Timsort.
Especially if you’re building a product for actual use (as apposed to for review in a paper), then don’t fall into the over engineered/academic trap. Be creative, learn the academic rules, then intentionally break those rules, build what actually adds value and make it ergonomic rather than try to perfectly implement a concept that academics defined so stringently it’s only useful for other academics.
Meanwhile, a lot of people on these threads would say Automerge is not a CRDT. By definition Automerge.getConflicts means Automerge has conflicts and is not conflict-free.
I on the other hand prefer and applaud Automerge for breaking the rules! I hope it continues to see more success.
I think you are grossly misunderstanding what does and does not make a CRDT. The existence of conflicts is fine - they just need to be solved automatically and in an eventually consistent manner so that all clients come up into the same state once they’re all online. “Conflict-free” refers to there not being any unsolvable conflicts or ambiguity in solving those conflicts. That’s why git isn’t but automerge is:
> The values of properties in a map in automerge can be conflicted if there are concurrent "put" operations to the same key. Automerge chooses one value arbitrarily (but deterministically, any two nodes who have the same set of changes will choose the same value) from the set of conflicting values to present as the value of the key.
> Sometimes you may want to examine these conflicts, in this case you can use getConflicts to get the conflicts for the key.
Basically it’s saying may be you want to look at other “older” values that may have been observed even though the conflict was resolved (eg showing to the user previous copies of the values).
"The only case Automerge cannot handle automatically, because there is no well-defined resolution, is when users concurrently update the same property in the same object (or, similarly, the same index in the same list). In this case, Automerge picks one of the concurrently written values as the "winner", and it ensures that this winner is the same on all nodes"
"The object returned by getConflicts contains the conflicting values, both the "winner" and any "losers". You might use the information in the conflicts object to show the conflict in the user interface."
To me, this seems identical to how git works. Specifically git fetch (does automatic resolution storing all of the changes), vs git merge (showing the conflicts in the user interface).
Automerge is "conflict-free" by the definition of "conflict-free" used in CRDTs. i.e. conflicts are automatically resolved in the same way every time by the algorithm. The .getConflicts allows you a neat interface to inspect a concurrent change to the same value. There is no conflict, no failure to merge. It automatically merges as usual. If you choose to act on the information returned by .getConflicts then that is a new change, it does not alter the past.
If you fetch from a repo with a slightly different history for a named branch than what you have locally, git fetch will fail. Thus git fetch operations are not part of a CRDT.
Similarly, the order in which you synchronize (fetch or merge) from remote sources is order dependent and does not eventually converge to the same result (e.g. the commit hashes will diverge for a simple reason that the current time is part of the commit hash).
This is even more true for git merge which does not even attempt automatic conflict resolution if the same file is edited multiple times.
Automatic conflict resolution is a key requirement of CRDTs and another is that when nodes are brought online they are guaranteed to converge to the exact same state. This is demonstrably not true for git & trying to handwave it away doesn't change anything.
Not sure why you're trying to shoehorn git into the CRDT definition when it's its own thing.
> What I'm describing here is very similar to decentralized version control (e.g., git and mercurial). In git, you commit locally and eventually merge and push your changes into a remote repository. Unlike git, CRDTs don't have merge conflicts. Conflict resolution is handled by the CRDT algorithm itself. Although not exactly a CRDT, git will be a useful model to refer back to since it is something already familiar to most developers and incorporates similar concepts.
I rarely care about such trivial things as being wrong.
I do care about being intellectually honest. I haven’t once said that you or anyone else in this thread is wrong. If you really read everything Ive written, you’ll see I’ve always offered multiple perspectives.
In my words, your perspective has always been accurately shared. I care about that.
Meanwhile, our differences are philosophical. I’m not interested in your limited perspective. Just like you’re not interested in my broader perspective.
I’m not asking you to believe or say anything. You don’t like the additional perspective I’ve shared, ok, move on.
Any and all networked video games with some form of rollback or correction. Best effort with a fallback to Rollback might actually be the “best” ie ergonomic experience for CRDTs that are most widely used.
Again, not academically a CRDT because technically game state is not perfectly replicated to every client. Each client only gets partial game state.
Additionally, game clients require low latency syncing, which could academically be considered “coordinating”. Even tho the client actually accepts and renders the input’s results locally probabilistically before any conflict resolution / rollback is returned to the client for correction.
Again people are likely going to be pedantic but with three post now, I’d like to hope, people might see the common theme:
The most popular, highly ergonomic, best implementations of CRDTs actually break the academic rules of CRDTs.
This is a relatively typical trap of an overly academic mental model. Most real world algorithms and data types are actually more creative than their academic “rulesets”. eg Timsort.
Especially if you’re building a product for actual use (as apposed to for review in a paper), then don’t fall into the over engineered/academic trap. Be creative, learn the academic rules, then intentionally break those rules, build what actually adds value and make it ergonomic rather than try to perfectly implement a concept that academics defined so stringently it’s only useful for other academics.