Re:Peritext: A CRDT for Rich-Text Collaboration
by samwillis on Wednesday November 24, 2021 @04:50AM
(#29328431)
I used Yjs for a project earlier this year and so will try to explain the main difference.
They way I see it there are two (or maybe more of a spectrum of) types of CRDT, from generic and to domain specific. Yjs actually has multiple different types, very generic types (Array and Map), slightly more specific types (XMLFragment and XMLElement), and then there is the Text type that covers both a generic plain text type but also has provision for rich formatting if needed. Peritext is basically a different method of implementing the Text type which aims to maintain a little more editor intent than Yjs currently does (although Yjs already dose a pretty brilliant job!).
For a full document, you need to represent both text elements with rich text formatting marks, but also block elements. With Yjs you would do this with the XMLElement type which as you would expect has attributes and can nest further XMLElements or Text within it. Peritext does not yet have support for block types.
So, although the most common use of Yjs is for collaborative rich text editing, it can be used for many other things such as 2D/3D drawing or even gaming.
Domain specific CRDTs aim to implement an algorithm that ensures when you merge two branches of a document the resulting document maintains intent and is a "valid" document, as in it would still match the "schema" of the final document type, for example valid html. I think this is what Peritext is trying to do for inline formatting.
Whereas with generic CRDTs you may find that when you merge two branches the resulting document is no longer "valid" and doesn't match your schema for the document. In this situation you you need to manually resolve any conflicts. With Yjs and Prosemirror, Prosemirror defines the schema of the document and will throw away any part of the document that does not match. In reality this if fairly rare occurrence but still needs some consideration when designing the document and how a user can interact with this (such as toiling different block types - and that sub elements those blocks support).
The reality is if you have lots of changes in close proximity it becomes much harder to maintain editor intent as the intents can conflict with each other. However this is mostly edge cases and the vast majority of documents won't have multiple people working in such proximity to each other. If they do they will find themselves with bigger problems like the actually grammar/language not being legible at all and loosing it meaning.
They way I see it there are two (or maybe more of a spectrum of) types of CRDT, from generic and to domain specific. Yjs actually has multiple different types, very generic types (Array and Map), slightly more specific types (XMLFragment and XMLElement), and then there is the Text type that covers both a generic plain text type but also has provision for rich formatting if needed. Peritext is basically a different method of implementing the Text type which aims to maintain a little more editor intent than Yjs currently does (although Yjs already dose a pretty brilliant job!).
For a full document, you need to represent both text elements with rich text formatting marks, but also block elements. With Yjs you would do this with the XMLElement type which as you would expect has attributes and can nest further XMLElements or Text within it. Peritext does not yet have support for block types.
So, although the most common use of Yjs is for collaborative rich text editing, it can be used for many other things such as 2D/3D drawing or even gaming.
Domain specific CRDTs aim to implement an algorithm that ensures when you merge two branches of a document the resulting document maintains intent and is a "valid" document, as in it would still match the "schema" of the final document type, for example valid html. I think this is what Peritext is trying to do for inline formatting.
Whereas with generic CRDTs you may find that when you merge two branches the resulting document is no longer "valid" and doesn't match your schema for the document. In this situation you you need to manually resolve any conflicts. With Yjs and Prosemirror, Prosemirror defines the schema of the document and will throw away any part of the document that does not match. In reality this if fairly rare occurrence but still needs some consideration when designing the document and how a user can interact with this (such as toiling different block types - and that sub elements those blocks support).
The reality is if you have lots of changes in close proximity it becomes much harder to maintain editor intent as the intents can conflict with each other. However this is mostly edge cases and the vast majority of documents won't have multiple people working in such proximity to each other. If they do they will find themselves with bigger problems like the actually grammar/language not being legible at all and loosing it meaning.