4 ms·

After studying [3], I came to the conclusion that the specific CRDTs they attempted to use for Xi editor might be too low level to be useful in building a text

After studying [3], I came to the conclusion that the specific CRDTs they attempted to use for Xi editor might be too low level to be useful in building a text editor directly, but that this is not an intrinsic shortcoming of CRDTs. Rather, the kind of automerging behavior of the CRDTs they used didn't match the design needs of the editor. (btw, check out chronofold, designed for text: https://arxiv.org/abs/2002.09511v4 https://arxiv.org/abs/2002.09511v4 ) Anyhow, I've come to see CRDTs as very low level primitives that can assist in creating decentralized applications. Their strength is not that they automagically solve the inherently subjective problem of merging asynchronously edited, divergent data. That problem is more of a design problem that needs to be solved on a case by case basis. The strength of CRDTs is in that they have extremely well defined behavior and aren't fundamentally reliant on a central coordinator or leader. Of course you can design in a leader if you want, or multiple leaders. But that has nothing to do with CRDTs. So I imagine them being more useful in composing higher level data structures and smooth interfaces for users to make inherently difficult decisions about merge conflicts themselves. My favorite kind of CRDTs are "delta state CRDTs". They're very cool. I wish the paper about them was easier to understand.

Taek 6y ago
"The strength of CRDTs is in that they have extremely well defined behavior and aren't fundamentally reliant on a central coordinator or leader." Very much agree with this. Coordination is a super hard problem in distributed systems, and becomes enormously more difficult if you assume adversaries actively trying to interfere with your system. Good distributed systems engineering is heavily focused on eliminating complexity and solving for every possible error case. CRDTs have a low number of error cases and allow nodes to interact together in clean, non-complex ways. Distributed systems engineers like reaching for CRDTs as a tool because they can take your engineering costs down by an order of magnitude.
raphlinus 6y ago
That's actually a reasonable position. We solved some problems, and had ideas for others (for example, overloading "priority" to position the cursor after things like inserting whitespace for indentation), but had a list of other things we wanted to do, including "soft spans" (issue #244 in the repo) that we never quite figured out how to do. Ultimately, I'm not very smart, and someone who is could probably figure out how to map all these other code editing problems to CRDT data structures. Once that's done, the result should be compelling, because CRDT lets you take advantage of low-latency local connections rather than requiring everything to get serialized on a central server. It's research I would love to see being carried forward.

Taek 6y ago

"The strength of CRDTs is in that they have extremely well defined behavior and aren't fundamentally reliant on a central coordinator or leader." Very much agree with this. Coordination is a super hard problem in distributed systems, and becomes enormously more difficult if you assume adversaries actively trying to interfere with your system. Good distributed systems engineering is heavily focused on eliminating complexity and solving for every possible error case. CRDTs have a low number of error cases and allow nodes to interact together in clean, non-complex ways. Distributed systems engineers like reaching for CRDTs as a tool because they can take your engineering costs down by an order of magnitude.

raphlinus 6y ago

That's actually a reasonable position. We solved some problems, and had ideas for others (for example, overloading "priority" to position the cursor after things like inserting whitespace for indentation), but had a list of other things we wanted to do, including "soft spans" (issue #244 in the repo) that we never quite figured out how to do. Ultimately, I'm not very smart, and someone who is could probably figure out how to map all these other code editing problems to CRDT data structures. Once that's done, the result should be compelling, because CRDT lets you take advantage of low-latency local connections rather than requiring everything to get serialized on a central server. It's research I would love to see being carried forward.