6 ms·

I don't have much experience in this area, but I'd be interested in an overview of how different pieces of sofware handle the concurrent / multiplayer editing p

by chubot 8y ago

I don't have much experience in this area, but I'd be interested in an overview of how different pieces of sofware handle the concurrent / multiplayer editing problem, like: - Etherpad - Google docs - Apache / Google Wave (open sourced: http://incubator.apache.org/projects/wave.html http://incubator.apache.org/projects/wave.html) - repl.it https://repl.it/site/blog/multi https://repl.it/site/blog/multi - figma https://www.figma.com/blog/multiplayer-editing-in-figma/ https://www.figma.com/blog/multiplayer-editing-in-figma/ (image editing rather than text editing) So is the gist of it that OT relies on central servers and they all use OT rather than CRDT? That was not entirely clear to me. Looking at the xi analysis, it sounds like "IME" is specific to a desktop application using X (?), so it doesn't apply to any of this web software. The rest of them seem like they do apply? Is the problem that you have to pay a "CRDT tax" for every piece of state in the application? I thought the same was true of OT. Don't you have to express every piece of state within those constraints too? repl.it doesn't seem to have a problem with syntax highlighting or brace matching (try it, it's pretty slick). So is it just that they paid that tax with a lot of code or is there something else fundamentally different about xi vs. repl.it ? Or maybe xi is going for a lot lower latency than web-based editors? recent thread about OT vs. CRDT that might be interesting: https://news.ycombinator.com/item?id=18191867 https://news.ycombinator.com/item?id=18191867

macintux 8y ago
Another OT/CRDT thread from just a few days ago: https://news.ycombinator.com/item?id=19845776 https://news.ycombinator.com/item?id=19845776
jahewson 8y ago
OT doesn’t have to depend on central servers, but it is much simpler and less resource-intensive to do it that way. This is what Etherpad, Google Wave and Google Docs do. As you say, both OT and CRDT come with a “tax” in that you must structure your application’ edits in a way that they can interpret. However, this is easier with OT for the text editing case, as OT uses position based addressing, whereas CRDT is identifier based (I’m assuming this is where the canonical IME issue mentioned comes from - somebody please correct me if I’m wrong).
- blattimwind 8y ago
  The interesting thing about OT is that almost every non-trivial editor uses that as its model, because it makes undo/redo very simple.
- raphlinus 8y ago
  xi-editor pioneers a hybrid where "identifiers" are actually the tuple of revision and position. The motivation is to buy back some of the performance edge that OT has because of its use of position. I think if you are going to do CRDT it's pretty compelling, but that's also somewhat orthogonal to the complexity concerns raised in my original post.
  - jahewson 8y ago
    Interesting - that’s definitely compelling. In a nutshell what exactly is the issue with IME?
    - raphlinus 8y ago
      Robert Lord's comments on the issue are probably the best explanation, written with the benefit of hindsight. [0]: https://github.com/xi-editor/xi-editor/issues/1187#issuecomment-491523739 https://github.com/xi-editor/xi-editor/issues/1187#issuecomm...
zamalek 8y ago
I'm pretty certain that these are OT: Etherpad, Docs, Wave. I've done quite a bit of investigation into these too and I'm convinced that OT is the mathematically inferior, but practically superior model (it is far easier to reason about, which is important because not everyone on your team might read compsci books). You can abstract OT/CRDT behind a step-locked view model, which should be fine for in-process. IME can be solved in this view model, too, by halting updates to the CRDT/OT between IME entries. The problem is that, with xi, this would necessitate implementing that view model in each front-end, so there's certainly the "CRDT tax" there. xi is a bit of an oddball.
raphlinus 8y ago
Just to answer the IME question, it refers to "Input Method Editor" and is an important problem to solve for all platforms, desktop, mobile, and Web. The API's for IME are often crufty and it's easy to get edge cases wrong. These days, lots of people care because emoji, but formerly it was something that English language speakers tended to ignore.
- hsivonen 8y ago
  An anecdote that goes against the conventional wisdom about IMEs vs. ”English” and emoji: Right now in Firefox and Chrome, the events that get fired are more correct if you enter emoji using the Windows 10 Pinyin IME’s emoji palette than if you enter emoji using the Windows 10 on-screen English keyboard’s emoji palette. Edited to elaborate: Keyboard APIs aren't well exercised for astral characters, but IME APIs deal with strings anyway.
antoncohen 8y ago
Figma has a blog post about it, they use Fractional Indexing. https://www.figma.com/blog/realtime-editing-of-ordered-sequences/ https://www.figma.com/blog/realtime-editing-of-ordered-seque...
- cgrand-net 8y ago
  Stern Brocot is a better way to do fractional indexing (pathological cases are not aligned with common uses cases like putting something to the front). https://en.m.wikipedia.org/wiki/Stern%E2%80%93Brocot_tree?wprov=sfti1 https://en.m.wikipedia.org/wiki/Stern%E2%80%93Brocot_tree?wp...
shereadsthenews 8y ago
I don’t think Google docs is distributed at all. I think all edits happen in a single process on a single machine. That’s why the limit of concurrent editors is so low.
- yorwba 8y ago
  It's distributed because there's communication with the clients going on, which requires some kind of coordination to achieve agreement on the result of two simultaneous edits.
  - taeric 8y ago
    I think the assertion is that the edits are not distributed. Instead, an intent to edit is sent to a central server which forces them to be serialized or rejects them. It is not merging distributed edits. I'm not sure if this is a) the assertion or b) correct/relevant.
    - jahewson 8y ago
      This is incorrect. Edits are made locally and sent to the server. The server merges the edit with any edits it received in the meantime from other clients. So the server serializes the rebased edits.
      - taeric 8y ago
        I'm not sure this is disagreeing with me. If a single central server/service is serializing and rebasing the edits, that is what I took the assertion to be. Decentralized world be the clients communicating their edits to each other. It can be confusing, as github is a centralized service for git, a decentralized protocol. So, much of the terminologies get blurred.
- jahewson 8y ago
  It’s distributed but it’s not decentralized. Concurrent edits are possible. This is how Google Docs is able to work offline.
DannyBee 8y ago
TL;DR CRDT is completely irrelevant to any of the highlighting/etc stuff Most highlighters are lexers. Advanced highlighters/folders are parsers. The lexing/parsing that is required for highlighting is easy to make incremental for all sane programming languages. for LL(star) grammars, adding incrementality is completely trivial (i sent patches to ANTLR4 to do this) for LR(k) grammars, it's more annoying but possible (tree-sitter does this) For lexing, doing it optimally is annoying, doing it near optimally is very easy. optimal incremental lexing requires tracking, on a per token basis, how far ahead in the character stream the recognizer looked (easy), and computing the affected sets (annoying) Most real programming languages have a lookahead of 1 or 2. Near-optimally requires tracking only the max lookahead used, and assuming all tokens need that max-lookahead. In a world where min token length is 1, that means you only need to re-lex an additional (max lookahead) tokens before the changed range. In a world where min token length is 0, it's all zero length tokens + (max lookahead) tokens before the changed range. This does not require any explicit per-token computation. Again for basically all programming languages, this ends up re-lexing 1 or 2 more tokens total than strictly necessary. Tree-sitter does context-aware on-demand lexing. i have patches on the way for ANTLR to do the same. The only thing CRDT helps with in this equation at all is knowing what changed and producing the sequence of tree-edits for the lexer/parser. The lexer only cares about knowing what character ranges changed, which does not require CRDT. The typical model for this kind of edit is what vscode's document text changes provide (IE For a given text edit, old start , old end, new start , new end) The parser only cares about what token ranges changed, which does not require CRDT.
- munificent 8y ago
  This is a great comment!
- chubot 8y ago
  Yeah I think I get what you're saying -- basically that if you have incremental algorithms then you don't need to take a dependency on CRDT or OT to make the UI updates fast? In other words, you can do things synchronously BUT still quickly, since you have an incremental algorithm. In any case, I basically asked that same question here: https://lobste.rs/s/jembrx/thoughts_on_why_crdt_didn_t_work_out_as_well#c_d57eds https://lobste.rs/s/jembrx/thoughts_on_why_crdt_didn_t_work_... I've seen Treesitter and am impressed by it, which I wrote a little about in that comment. ----- Since you speak of "sane" languages, I wrote a parser for an "insane" language by hand, with a principled regex-based lexer: How to Parse Shell Like a Programming Language http://www.oilshell.org/blog/2019/02/07.html http://www.oilshell.org/blog/2019/02/07.html In fact the first thing I tried was to use ANTLR to translate the POSIX shell grammar (which only covers about 1/4 of the shell language). This drove home the limitations of grammar-based approaches. I found its model of lexing to be very limited (along with insisting on materializing a parser tree rather than providing semantic actions in ANTLR v4). So it's good to hear that it's being updated for "context-aware lexing", and incremental lexing. Are you using ANTLR for IDE-like tools? I wasn't aware that it was good or commonly used for that kind of use case. ----- I briefly talked with the author of Treesitter on Github about his bash syntax highlighter with Treesitter, which is of course a parser and not just a lexer, and can be made incremental. I wasn't sure if the context-aware lexing mechanisms here could really handle the shell language: https://tree-sitter.github.io/tree-sitter/creating-parsers#lexical-analysis https://tree-sitter.github.io/tree-sitter/creating-parsers#l... I think his response was basically that it doesn't have to be 100% correct, which I agree with for an editor. Trading off some corner cases for speed is probably the right thing. But I have thought about what it would take make a parser for a "crazy" language incremental and 100% correct (which you would want for further semantic analysis). I wonder if you can write recursive descent parser in the Skip language and then get incrementality for free? The language is designed so that every algorithm can be made incremental, and it's not limited to pure functional constructs like other systems. Supposedly it goes to some lengths to provide you with a more imperative / mutable state modelk, so it should be able to express an "arbitrary" parser. http://skiplang.com/ http://skiplang.com/ In other words, instead of having different algorithms for making LL(star) and GLR parsing incremental, Skip might give you a more expressive model for the parser. A bunch of my blog posts are about the limitations of grammar-based approaches. ----- FWIW the style of context-aware lexing I use is explained here: When Are Lexer Modes Useful? http://www.oilshell.org/blog/2017/12/17.html http://www.oilshell.org/blog/2017/12/17.html And the other post lists the 14 different modes or contexts that the shell front end has: http://www.oilshell.org/blog/2019/02/07.html#toc_7 http://www.oilshell.org/blog/2019/02/07.html#toc_7 It's a very simple and powerful mechanism, but my parser only cares about batch mode for now. It's not clear to me how it differs in expressiveness from what Treesitter offers (or ANTLR). The current lexer mode basically depends on the control flow of the parser.
lewisjoe 8y ago
> So is the gist of it that OT relies on central servers and they all use OT rather than CRDT? You are right. I'd take shot at blowing out the why part. Practically, real-time collaboration apps can be categorized into two: #1 The document editors, which stores information on the cloud. I'll refer these as document editors henceforth. #2 The ones that doesn't need a thick server, except for broadcasting edits. Like plain text editors and code editors. I'll refer these as code editors for simplicity sake. Both have a slightly different set of problems. Document editors, usually have a slightly richer document representation schema (since most of them are rich text documents anyway). But they have the luxury of a central server. A central server means, now they have the power for good versioning, rollbacks to a consistent state, picking winners and ensuring ordering of edits when syncing large edits. Code editors, although their doc representation is usually arrays of characters (it could be strings, ropes, or whatever but essentially just a set of characters), these don't have the luxury of a central server that could decide a winner when concurrent edits take place. This means the clients have to be very intelligent and converge to the same representation no matter how out-of-order the edits arrive. Now coming back to the two algorithms camps - OT & CRDT: The general outlook is that, OT - while being simple, they have this classic TP2 problem that would make it harder to arrive at a consistent state eventually - without a help from a central server. The alternative is to have a complicated system, almost as complicated as CRDTs. (More about this can be read through the Internet. If anybody's interested I'll post links to stuff I've read through) CRDT - CRDT have (or maybe had?) a strong reputation of being efficient at arriving at a consistent state with out of order edits. They can do it, because basically no characters in a CRDT document is deleted anyway (they are just marked deleted and are termed tombstones). So no information loss, which means a clever algorithm can write a function to easily arrive at a consistent state at each site. This means, a central server is now only optional. If I didn't lose you until now, you'd have intuitively guessed why document editors, tended to always pick OT and code editors prefer CRDT over OT. This is complete oversimplifications and certainly there's a ton of things I left out for simplicity sake. Source: I'm in the business of building a powerful Google Docs alternative, a word processor that runs on the browser: https://writer.zoho.com https://writer.zoho.com (Zoho Writer)
- nused 7y ago
  > The general outlook is that, OT - while being simple, they have this classic TP2 problem that would make it harder to arrive at a consistent state eventually - without a help from a central server. The alternative is to have a complicated system, almost as complicated as CRDTs. Well this characterization isn't quite right. With regard to TP2, this is a solved problem, with or without using a server. Most of the conversations around TP2 seems to miss the crucial point that TP2 is not needed for convergence. CRDT academic literature has largely been responsible for propagating the notion that TP2 is a must for every OT system - without TP2, all is lost -- this is a myth. I wrote about it extensively here [1]. This article [2] gives an analysis of 7 coeditors based on OT, including the likes of Google Docs, showing that they avoid having to design transformation functions that require TP2. Some of the systems are fully de-centralized [3], others require a server. It is also worth making a finer distinction between systems that do need a central server -- there are "transformation servers" and "messaging severs". Google Docs, for example, demands that its servers perform some portion of the transformation logic. Many other solutions rely on using the server only for message transmission/serialization, thus the server side logic is significantly simpler. [1] https://arxiv.org/pdf/1905.01302.pdf https://arxiv.org/pdf/1905.01302.pdf [2] Achieving convergence in operational transformation: conditions, mechanisms, and systems.ACM CSCW (2014) [3] A generic operation transformation scheme for consistency maintenance in real-time cooperative editing systems ACM GROUP (1997)

by chubot 8y ago

macintux 8y ago

Another OT/CRDT thread from just a few days ago: https://news.ycombinator.com/item?id=19845776 https://news.ycombinator.com/item?id=19845776

jahewson 8y ago

OT doesn’t have to depend on central servers, but it is much simpler and less resource-intensive to do it that way. This is what Etherpad, Google Wave and Google Docs do. As you say, both OT and CRDT come with a “tax” in that you must structure your application’ edits in a way that they can interpret. However, this is easier with OT for the text editing case, as OT uses position based addressing, whereas CRDT is identifier based (I’m assuming this is where the canonical IME issue mentioned comes from - somebody please correct me if I’m wrong).

blattimwind 8y ago
The interesting thing about OT is that almost every non-trivial editor uses that as its model, because it makes undo/redo very simple.
raphlinus 8y ago
xi-editor pioneers a hybrid where "identifiers" are actually the tuple of revision and position. The motivation is to buy back some of the performance edge that OT has because of its use of position. I think if you are going to do CRDT it's pretty compelling, but that's also somewhat orthogonal to the complexity concerns raised in my original post.
- jahewson 8y ago
  Interesting - that’s definitely compelling. In a nutshell what exactly is the issue with IME?
  - raphlinus 8y ago
    Robert Lord's comments on the issue are probably the best explanation, written with the benefit of hindsight. [0]: https://github.com/xi-editor/xi-editor/issues/1187#issuecomment-491523739 https://github.com/xi-editor/xi-editor/issues/1187#issuecomm...

zamalek 8y ago

I'm pretty certain that these are OT: Etherpad, Docs, Wave. I've done quite a bit of investigation into these too and I'm convinced that OT is the mathematically inferior, but practically superior model (it is far easier to reason about, which is important because not everyone on your team might read compsci books). You can abstract OT/CRDT behind a step-locked view model, which should be fine for in-process. IME can be solved in this view model, too, by halting updates to the CRDT/OT between IME entries. The problem is that, with xi, this would necessitate implementing that view model in each front-end, so there's certainly the "CRDT tax" there. xi is a bit of an oddball.

raphlinus 8y ago

Just to answer the IME question, it refers to "Input Method Editor" and is an important problem to solve for all platforms, desktop, mobile, and Web. The API's for IME are often crufty and it's easy to get edge cases wrong. These days, lots of people care because emoji, but formerly it was something that English language speakers tended to ignore.

hsivonen 8y ago
An anecdote that goes against the conventional wisdom about IMEs vs. ”English” and emoji: Right now in Firefox and Chrome, the events that get fired are more correct if you enter emoji using the Windows 10 Pinyin IME’s emoji palette than if you enter emoji using the Windows 10 on-screen English keyboard’s emoji palette. Edited to elaborate: Keyboard APIs aren't well exercised for astral characters, but IME APIs deal with strings anyway.

antoncohen 8y ago

Figma has a blog post about it, they use Fractional Indexing. https://www.figma.com/blog/realtime-editing-of-ordered-sequences/ https://www.figma.com/blog/realtime-editing-of-ordered-seque...

cgrand-net 8y ago
Stern Brocot is a better way to do fractional indexing (pathological cases are not aligned with common uses cases like putting something to the front). https://en.m.wikipedia.org/wiki/Stern%E2%80%93Brocot_tree?wprov=sfti1 https://en.m.wikipedia.org/wiki/Stern%E2%80%93Brocot_tree?wp...

shereadsthenews 8y ago

I don’t think Google docs is distributed at all. I think all edits happen in a single process on a single machine. That’s why the limit of concurrent editors is so low.

yorwba 8y ago
It's distributed because there's communication with the clients going on, which requires some kind of coordination to achieve agreement on the result of two simultaneous edits.
- taeric 8y ago
  I think the assertion is that the edits are not distributed. Instead, an intent to edit is sent to a central server which forces them to be serialized or rejects them. It is not merging distributed edits. I'm not sure if this is a) the assertion or b) correct/relevant.
  - jahewson 8y ago
    This is incorrect. Edits are made locally and sent to the server. The server merges the edit with any edits it received in the meantime from other clients. So the server serializes the rebased edits.
    - taeric 8y ago
      I'm not sure this is disagreeing with me. If a single central server/service is serializing and rebasing the edits, that is what I took the assertion to be. Decentralized world be the clients communicating their edits to each other. It can be confusing, as github is a centralized service for git, a decentralized protocol. So, much of the terminologies get blurred.
jahewson 8y ago
It’s distributed but it’s not decentralized. Concurrent edits are possible. This is how Google Docs is able to work offline.

DannyBee 8y ago

TL;DR CRDT is completely irrelevant to any of the highlighting/etc stuff Most highlighters are lexers. Advanced highlighters/folders are parsers. The lexing/parsing that is required for highlighting is easy to make incremental for all sane programming languages. for LL(star) grammars, adding incrementality is completely trivial (i sent patches to ANTLR4 to do this) for LR(k) grammars, it's more annoying but possible (tree-sitter does this) For lexing, doing it optimally is annoying, doing it near optimally is very easy. optimal incremental lexing requires tracking, on a per token basis, how far ahead in the character stream the recognizer looked (easy), and computing the affected sets (annoying) Most real programming languages have a lookahead of 1 or 2. Near-optimally requires tracking only the max lookahead used, and assuming all tokens need that max-lookahead. In a world where min token length is 1, that means you only need to re-lex an additional (max lookahead) tokens before the changed range. In a world where min token length is 0, it's all zero length tokens + (max lookahead) tokens before the changed range. This does not require any explicit per-token computation. Again for basically all programming languages, this ends up re-lexing 1 or 2 more tokens total than strictly necessary. Tree-sitter does context-aware on-demand lexing. i have patches on the way for ANTLR to do the same. The only thing CRDT helps with in this equation at all is knowing what changed and producing the sequence of tree-edits for the lexer/parser. The lexer only cares about knowing what character ranges changed, which does not require CRDT. The typical model for this kind of edit is what vscode's document text changes provide (IE For a given text edit, old start , old end, new start , new end) The parser only cares about what token ranges changed, which does not require CRDT.

munificent 8y ago
This is a great comment!
chubot 8y ago
Yeah I think I get what you're saying -- basically that if you have incremental algorithms then you don't need to take a dependency on CRDT or OT to make the UI updates fast? In other words, you can do things synchronously BUT still quickly, since you have an incremental algorithm. In any case, I basically asked that same question here: https://lobste.rs/s/jembrx/thoughts_on_why_crdt_didn_t_work_out_as_well#c_d57eds https://lobste.rs/s/jembrx/thoughts_on_why_crdt_didn_t_work_... I've seen Treesitter and am impressed by it, which I wrote a little about in that comment. ----- Since you speak of "sane" languages, I wrote a parser for an "insane" language by hand, with a principled regex-based lexer: How to Parse Shell Like a Programming Language http://www.oilshell.org/blog/2019/02/07.html http://www.oilshell.org/blog/2019/02/07.html In fact the first thing I tried was to use ANTLR to translate the POSIX shell grammar (which only covers about 1/4 of the shell language). This drove home the limitations of grammar-based approaches. I found its model of lexing to be very limited (along with insisting on materializing a parser tree rather than providing semantic actions in ANTLR v4). So it's good to hear that it's being updated for "context-aware lexing", and incremental lexing. Are you using ANTLR for IDE-like tools? I wasn't aware that it was good or commonly used for that kind of use case. ----- I briefly talked with the author of Treesitter on Github about his bash syntax highlighter with Treesitter, which is of course a parser and not just a lexer, and can be made incremental. I wasn't sure if the context-aware lexing mechanisms here could really handle the shell language: https://tree-sitter.github.io/tree-sitter/creating-parsers#lexical-analysis https://tree-sitter.github.io/tree-sitter/creating-parsers#l... I think his response was basically that it doesn't have to be 100% correct, which I agree with for an editor. Trading off some corner cases for speed is probably the right thing. But I have thought about what it would take make a parser for a "crazy" language incremental and 100% correct (which you would want for further semantic analysis). I wonder if you can write recursive descent parser in the Skip language and then get incrementality for free? The language is designed so that every algorithm can be made incremental, and it's not limited to pure functional constructs like other systems. Supposedly it goes to some lengths to provide you with a more imperative / mutable state modelk, so it should be able to express an "arbitrary" parser. http://skiplang.com/ http://skiplang.com/ In other words, instead of having different algorithms for making LL(star) and GLR parsing incremental, Skip might give you a more expressive model for the parser. A bunch of my blog posts are about the limitations of grammar-based approaches. ----- FWIW the style of context-aware lexing I use is explained here: When Are Lexer Modes Useful? http://www.oilshell.org/blog/2017/12/17.html http://www.oilshell.org/blog/2017/12/17.html And the other post lists the 14 different modes or contexts that the shell front end has: http://www.oilshell.org/blog/2019/02/07.html#toc_7 http://www.oilshell.org/blog/2019/02/07.html#toc_7 It's a very simple and powerful mechanism, but my parser only cares about batch mode for now. It's not clear to me how it differs in expressiveness from what Treesitter offers (or ANTLR). The current lexer mode basically depends on the control flow of the parser.

lewisjoe 8y ago

> So is the gist of it that OT relies on central servers and they all use OT rather than CRDT? You are right. I'd take shot at blowing out the why part. Practically, real-time collaboration apps can be categorized into two: #1 The document editors, which stores information on the cloud. I'll refer these as document editors henceforth. #2 The ones that doesn't need a thick server, except for broadcasting edits. Like plain text editors and code editors. I'll refer these as code editors for simplicity sake. Both have a slightly different set of problems. Document editors, usually have a slightly richer document representation schema (since most of them are rich text documents anyway). But they have the luxury of a central server. A central server means, now they have the power for good versioning, rollbacks to a consistent state, picking winners and ensuring ordering of edits when syncing large edits. Code editors, although their doc representation is usually arrays of characters (it could be strings, ropes, or whatever but essentially just a set of characters), these don't have the luxury of a central server that could decide a winner when concurrent edits take place. This means the clients have to be very intelligent and converge to the same representation no matter how out-of-order the edits arrive. Now coming back to the two algorithms camps - OT & CRDT: The general outlook is that, OT - while being simple, they have this classic TP2 problem that would make it harder to arrive at a consistent state eventually - without a help from a central server. The alternative is to have a complicated system, almost as complicated as CRDTs. (More about this can be read through the Internet. If anybody's interested I'll post links to stuff I've read through) CRDT - CRDT have (or maybe had?) a strong reputation of being efficient at arriving at a consistent state with out of order edits. They can do it, because basically no characters in a CRDT document is deleted anyway (they are just marked deleted and are termed tombstones). So no information loss, which means a clever algorithm can write a function to easily arrive at a consistent state at each site. This means, a central server is now only optional. If I didn't lose you until now, you'd have intuitively guessed why document editors, tended to always pick OT and code editors prefer CRDT over OT. This is complete oversimplifications and certainly there's a ton of things I left out for simplicity sake. Source: I'm in the business of building a powerful Google Docs alternative, a word processor that runs on the browser: https://writer.zoho.com https://writer.zoho.com (Zoho Writer)

nused 7y ago
> The general outlook is that, OT - while being simple, they have this classic TP2 problem that would make it harder to arrive at a consistent state eventually - without a help from a central server. The alternative is to have a complicated system, almost as complicated as CRDTs. Well this characterization isn't quite right. With regard to TP2, this is a solved problem, with or without using a server. Most of the conversations around TP2 seems to miss the crucial point that TP2 is not needed for convergence. CRDT academic literature has largely been responsible for propagating the notion that TP2 is a must for every OT system - without TP2, all is lost -- this is a myth. I wrote about it extensively here [1]. This article [2] gives an analysis of 7 coeditors based on OT, including the likes of Google Docs, showing that they avoid having to design transformation functions that require TP2. Some of the systems are fully de-centralized [3], others require a server. It is also worth making a finer distinction between systems that do need a central server -- there are "transformation servers" and "messaging severs". Google Docs, for example, demands that its servers perform some portion of the transformation logic. Many other solutions rely on using the server only for message transmission/serialization, thus the server side logic is significantly simpler. [1] https://arxiv.org/pdf/1905.01302.pdf https://arxiv.org/pdf/1905.01302.pdf [2] Achieving convergence in operational transformation: conditions, mechanisms, and systems.ACM CSCW (2014) [3] A generic operation transformation scheme for consistency maintenance in real-time cooperative editing systems ACM GROUP (1997)