Peritext: A CRDT for Rich-Text Collaboration(inkandswitch.com)
inkandswitch.com
Peritext: A CRDT for Rich-Text Collaboration
https://www.inkandswitch.com/peritext/
7 comments
Source code (in TypeScript) here: https://github.com/inkandswitch/peritext
How is this different than something like yjs?
(Author here)
Yjs is an impressive project and probably the most production-ready text CRDT library out there today.
One of our goals was to write down a clear spec for how a rich text CRDT should behave separately from any particular algorithm, as a resource for people working on tools in this space.
In the process we also found some examples where we felt Yjs didn’t maximally preserve intent. One of them is documented in the paper in the section about control characters, and Peritext handles that case differently.
Also, as an implementation note, our prototype sends incremental changes to the Prosemirror editor, whereas I believe yjs sends changes that replace the entire document, which can break the behavior of other plugins [1].
[1]: https://discuss.prosemirror.net/t/offline-peer-to-peer-colla...
Yjs is an impressive project and probably the most production-ready text CRDT library out there today.
One of our goals was to write down a clear spec for how a rich text CRDT should behave separately from any particular algorithm, as a resource for people working on tools in this space.
In the process we also found some examples where we felt Yjs didn’t maximally preserve intent. One of them is documented in the paper in the section about control characters, and Peritext handles that case differently.
Also, as an implementation note, our prototype sends incremental changes to the Prosemirror editor, whereas I believe yjs sends changes that replace the entire document, which can break the behavior of other plugins [1].
[1]: https://discuss.prosemirror.net/t/offline-peer-to-peer-colla...
Do you feel you’ve been able to solve some of the issues [0] the Xi editor project had with collaborative editing via CRDT?
[0]: https://github.com/xi-editor/xi-editor/issues/1187#issuecomm...
[0]: https://github.com/xi-editor/xi-editor/issues/1187#issuecomm...
Are there plans to make Peritext production-ready like Yjs, or is this more of a sketch for people to build their own collaborative rich text editor integrations?
Eventually we plan to integrate this algorithm into the Text type of Automerge [1], which is a more production-ready CRDT.
[1]: https://github.com/automerge/automerge
[1]: https://github.com/automerge/automerge
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.