61–70 of 70 posts
CRDT is a different paradigm. Ideally we'd use it to replace client-server
I think we can. Following all the implications down the rabbit hole, you end up with a system architecture where there's no front-end, and there's no back-end. Since CRDTs are still kinda new for most people, the discussion hasn't really gotten there yet.
Earlier quoted context omitted.
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 pr…
> 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... .
(i was the cto at a startup which used this to create a multi-user text editor with rich text support in 2015ish)
Earlier quoted context omitted.
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 pr…
> 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... .
Earlier quoted context omitted.
You can have a LWW CRDT, but not every LWW is a CRDT. LWW CRDTs generally pick a winner based on causal order which is convergent , the C in CRDT, because every peer receiving the same ops in any order would pick the same winner. Picking a winner based on wall clock time order (as suggested in the article, and implemented by Notion) is not convergent; if peers used that algorithm to apply ops I they would not converg…
> ...based on causal order which is convergent, the C in CRDT... Doesn't the C stand for conflict-free? I suppose both are kind of getting at the same idea though.
You could add to the confusion by using C=Collaborative. (I personally prefer "collaborative data structures" for the more general concept of data structures that can be edited on multiple devices; CRDT is a mouthful and now also a buzzword.)
As someone who works on a CRDT library with opaque state [1], I agree that this is a big barrier to adoption. Features like partial loading, per-paragraph permissions, and accept/reject suggestions seem pretty easy to implement if each text char is just a row in your server's DB, but I would have trouble implementing them on top of e.g. Yjs.
For text editing, one idea is to separate the CRDT "positions" from the text itself, which you can then store as a map (position -> char) in your own data structures. I've made a simple (but inefficient) library along these lines [2] and would be interested in ideas for further development.
[1] Collabs - https://collabs.readthedocs.io
[2] position-strings - https://www.npmjs.com/package/position-strings
Earlier quoted context omitted.
> 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... .
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.
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.
Earlier quoted context omitted.
> 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
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 th…
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?