Lies I was Told About Collaborative Editing, Part 1: Algorithms for offline editing
Posted by hausdorff_spaces@reddit | programming | View on Reddit | 9 comments
scratchisthebest@reddit
Very damning that users saw the crowning feature of CRDTs at work and thought it was data corruption.
I guess CRDTs are good at resolving conflicts across a string of characters, but people obviously don't see documents as a string of characters, they see em as words, sentences, paragraphs, pages, chapters... deleting one character to fix a typo is a fundamentally different operation from deleting a sentence, in people's heads, so modeling these abstractly as "delete 1 character" and "delete 100 characters" is a poor approximation.
and of course words and sentences carry semantic meaning which CRDTs have no idea about. I think i would prefer seeing an "edit conflict!" interface over a crdt algorithm silently putting nonsensical prose into the middle of the document without me noticing
epukinsk@reddit
I don’t think it quite rises to the level of “damned tech” because of this…
The behavior is pretty intuitive in a collaborative editing scenario:
Alice selects a line
Bob sees Alice’s selection and places his cursor within her selection
Bob types the letter “u”
Alice presses delete
Only “u” remains
… as a scenario playing out in realtime, it makes sense. Alice sees that Bob typed “u”. Bob sees that Alice deleted the line out from under him. No “merge conflict” editor needs to open.
If either of them presses “Undo”, which they are likely to do, the CRDT can unwind the change and give the other user back exactly what they expected.
This is all valuable, important, “correct” stuff which CRDTs provide.
Do CRDTs provide intuitive results in an offline mode? No. An offline editor probably needs to fallback to something like Myers diffs and have a merge conflict editor of some type, where you can pick a winner.
That doesn’t mean CRDT is a cursed tech, it’s serving a critical role for the collaborative editing mode.
hennell@reddit
>There are a few reasons to be optimistic about this. One is that we already have one widely-adopted UI for merging documents:
git!As long as they take the ideas but not the terms. "Do you want Alice or Bobs edit for this line?" might work as a UX. "Merge 'ours' or 'theirs'?" will get people murdered.
aueioaue@reddit
Please use spoiler tags for git PTSD triggers.
Reverent@reddit
Oh no, it's almost like source control has been battling the concept of merge conflicts for 30 years and can't magically interpret differences of opinion.
Short answer is you give weight either to what came before or what came after and then the battle comes to reduce opportunity for the conflict to exist in the first place.
Eezelle@reddit
I'm so surprised there are no distributed systems zealots saying "duh, we've been saying this all along!"
Own_Anything9292@reddit
I’m now really excited to pitch my Paxos based offline collaborative note editing app
hausdorff_spaces@reddit (OP)
It is kind of funny to think about it like a databases problem! If I told you I had two completely separate write replicas of some database, each accepting totally divergent writes, and then later we were going to merge them together using CRDTs or OT, or some other magic, I think everyone would have a good chuckle about that. But somehow if one of those replicas happens to be a text editor in the browser (or similar) a lot of people are like "yes this makes complete sense." Somehow these thoughts do not register as conflicting to a lot of people!
CanvasFanatic@reddit
Some people say it don’t be like that but it do be.