rich-text

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

Is there a sharedb compatible OT type definition? Like how https://github.com/ottypes/rich-text exists for Quill? https://quilljs.com/docs/delta/ Also is it possible for third party plugins to add new operations (defining their own conflict resolution against the existing types)?

As a long-time user of Quill, I must say: Congratulations to jhchen and everyone else who worked on the project. I use Quilljs because it's a great implementation of a modern-thinking WYSIWYG text editor. The underlying parchment[0] library helps a lot to separate out the data model from the rendered view (instead of relying on contenteditable to handle your data model, like many other classic rich text editors do). My users type stuff in Quill, and my front end shoots data in the rich-text[1] format back to the back-end. I have a small (and not great, but functional for my needs) library [2] I wrote to convert rich-text back into HTML, so we never actually store user-entered HTML entities in our database (which helps a lot for things like protecting against XSS attacks, and since rich-text is just a JSON object, I can do interesting data

I use quill in my big internal CMS / forum mashup project that's not (quite) ready to share yet. It's pretty rad. There's a related library [0] that is the rich text specification for operational transforms. By wiring the OT stream into a websocket, I can get pretty decent multi-user simultaneous editing on the cheap. It's not perfect - I don't properly handle some cases with simultaneous edits to the same region, but it's good enough to prevent locking and clobbering in a multi-author environment. It also means I have per-keystroke autosave and the ability to reconstruct who typed what in a given document on my site, which is important to some of my users. The module system is reasonable for adding in extensions as well. I personally don't miss access to tables, since really most of the time tables are misused anyway (for structured pres

Hi! Awesome post. I've been working on a similar project based on the quill editor [1], which is in turn based on the rich-text OT library [2]. Initially, I thought to wire this all up using the sharejs project [3], but never could quite grok that codebase. Instead, I've been working on a similar system to one you describe, with changes applied in order based on sequential version number, and concurrent updates forced to "rebase" against earlier changes (not yet open-sourced). A question: > Because applying changes in a different order might create a different document, rebasing isn't quite as easy as transforming all of our own changes through all of the remotely made changes. Can you explain more about how you arrived this conclusion? From my understanding, a correct transform function should allow exactly this, according to transformat