Hacker News Reader

Comment by josephg | Hacker News Reader

Yeah. Text based OT is pretty simple to implement, too. It’s about 200 lines of code, plus a simple network protocol. It’s fast and relatively straightforward to code up, and unlike text CRDTs it’s pretty fast by default.

I use it as my standard test when trying out a new programming language. It was unexpectedly ugly in go because of go’s lack of enums & unions, and that’s one of the big reasons I never got in to programming Go.

View on HN

Operational transforms are one of those interesting technologies I’ve wanted to learn by implementing but haven’t made the time yet. I also didn’t realise it could be implemented in that little code.

Can you recommend any learning resources for implementing an OT? (Ideally typescript, python, or rust)

I haven’t explored this space in a while, but I have a couple of examples that could be helpful. A Clojure library of mine [0] has a decent README with some background reading on how to use operational transform.

I also reimplemented it in a surprisingly tiny amount of OCaml [1] which was a fun way to learn that language :)

[0]: https://github.com/jahfer/othello [1]: https://github.com/jahfer/othello-ocaml

This single file shows the entire set of OT transformations (retain, insert, delete):

https://github.com/Operational-Transformation/ot.js/blob/mas...

and this is a good post outlining the basics of OT, from the creator of CodeMirror:

https://marijnhaverbeke.nl/blog/collaborative-editing-cm.htm...

> Yeah. Text based OT is pretty simple to implement, too. It’s about 200 lines of code, plus a simple network protocol.

Just for clarification, while OT for plain-text (linear model) might be simple to implement, OT for typical rich-text editors (like Google Docs) that need to rely on a tree-structured data model is a whole different story: https://ckeditor.com/blog/lessons-learned-from-creating-a-ri....

nah, that’s not true at all. have a look at ‘rich-text’[1] which allows for transforms on metadata in a separate stream from the main content. it’s the same basic algo used for OT on plain text.

(i was the cto at a startup which used this to create a multi-user text editor with rich text support in 2015ish)

1: https://github.com/ottypes/rich-text

What's not true at all? That more powerful rich text editors need to rely on a tree structure?

yes. that is not true. you can build a rich text editor with simple ot. no tree necessary.

I agree. Yes, you can. Quill is the example here.

Actually, back in 2015 when we started prototyping CKEditor 5, we started with this approach as well. Our goal from the beginning was to combine real-time editing capabilities with an engine capable of storing and rendering complex rich-text structures (nested tables, complex nested lists, other rich widgets, etc.). We quickly realized that a linear structure is going to be a huge bottleneck. In the end, if you want to represent trees, storing them as a linear structure is counterproductive.

So, we went for a tree model. That got many things in the engine an order of magnitude harder (OT being one). But I choose to encapsulate this complexity in the model rather than make it leak to particular plugins.

In fact, from what I remember, https://github.com/quilljs/quill/issues/117 (e.g. https://github.com/quilljs/quill/issues/117#issuecomment-644...) is a good example of issues that we avoided.

I also talked to companies that built their platforms on top of Quill. One of them ended up gluing together countless Quill instances to power their editor and overcome the limitations of the linear data model but is now looking for a way to rebuild their editor from scratch due to the issues (performance, complexity, stability).

So, yes. You can implement a rich-text editor based on a linear model. But it has its immediate limitations that you need to take into consideration.

Well, interestingly josephg (parent commentor) was part of the team that made the original gdocs editor. And I guess he worked on the Google Wave OT implementation.

Thank god I didn't question what josephg wrote regarding the text-based OT :D

I'm actually part of the team that built real-time collaboration for CKEditor 5. As the article says, we use a tree-structured representation for rich-text data and decided (many years ago) to go with OT. My guess always was that GDocs also uses a tree structure as the internal data model or that at least Google Wave did. I think I based this on a comment from a Google employee who summed up their OT implementation as hard to stabilize, even over many years.

I know it's possible to kind of represent rich-text data in form of a linear structure. This makes the implementation of the OT much much simpler. But then the editor itself becomes much more limited or you need to combine multiple instances of its model to represent more complex data. E.g., AFAIK Quill (mentioned in the other comment) does not offer stable tables implementation. Something that wasn't that big of a deal for us.

Google Docs actually uses a flat array representation of the whole document. Tables/lists and other structures are encoded using control-characters in the plain string. This makes index calculations for OT a bit easier.

How do I know? I work on Zoho Writer - a google docs alternative and we use the same technique :)

Glad to meet you. Huge fan of CKeditor's modular architecture of the editor. Making something with that level of customization and supporting realtime collaboration is not an easy feat at all!

What are your thoughts on CRDT generally? Will CKeditor ever look into adopting CRDTs in the future?

Reply on news.ycombinator.com