OT and CRDT trade-offs for Real-Time collaboration
1–10 of 60 posts
Re: OT and CRDT trade-offs for Real-Time collaboration
#2this is a wonderful writeup! thank you!
I'm researching the same thing.
Any tutorial on OT implementation? Especially, I need to handle structured data, like json.
Re: OT and CRDT trade-offs for Real-Time collaboration
#3I’ve been doing a pretty deep dive on CRDTs and OTs to get the right user experience for our collaborative website builder[1]. I’m still not done with the implementation and subsequent testing (i.e., splitting text nodes, as mentioned in the post). But the core algorithm behind Automerge[2], formalized in the OpSets paper[3] is extremely promising. A good example of its power is the ability to do an atomic tree “move”, whilst preserving strong eventual consistency.
I'm so glad to see that the HN community cares about this problem space. Maybe I should finally write that blog post on CRDTs and how to implement them yourself following the OpSets spec.
Re: OT and CRDT trade-offs for Real-Time collaboration
#4this is a wonderful writeup! thank you! I'm researching the same thing. Any tutorial on OT implementation? Especially, I need to handle structured data, like json.
This article popped up on HN recently and is a great intro to CRDT implementation. It says OT is much more difficult.
http://archagon.net/blog/2018/03/24/data-laced-with-history/
Re: OT and CRDT trade-offs for Real-Time collaboration
#5At Mixcut.com (Building real time collaborative video editing) we use a combination of OTs and a variant/simpler version of CRDTs that provide the most coverage of the various features needed. The usage of low latency websockets to shuttle OTs and building completely around OTs is key.
It’s working great for us in beta, we’ve recently shipped multiplayer to our users and overall it’s very stable. With a lot more in store soon, please check it out!
Re: OT and CRDT trade-offs for Real-Time collaboration
#6There's one thing I'd add here, as advice to potential implementers of collaborative editing algorithms. Test the system rigorously, autogenerating concurrent workloads of all the operations (including undo), and also various delays. If this had been done early on, all the broken algorithms (some published with formal proofs of correctness!) would have been caught. A lot of the broken algorithms work under light loads - TP2 requires at least three concurrent edits, two inserts and one delete, to trigger.
Re: OT and CRDT trade-offs for Real-Time collaboration
#7There's one thing I'd add here, as advice to potential implementers of collaborative editing algorithms. Test the system rigorously, autogenerating concurrent workloads of all the operations (including undo), and also various delays. If this had been done early on, all the broken algorithms (some published with formal proofs of correctness!) would have been caught. A lot of the broken algorithms work under light load…
We're using property-based testing where we can, which I hope to cover in a future post
Re: OT and CRDT trade-offs for Real-Time collaboration
#8this is a wonderful writeup! thank you! I'm researching the same thing. Any tutorial on OT implementation? Especially, I need to handle structured data, like json.
The second post will cover which editor model we chose, and talk a little bit about the OT implementation details ;)
Re: OT and CRDT trade-offs for Real-Time collaboration
#9this is a wonderful writeup! thank you! I'm researching the same thing. Any tutorial on OT implementation? Especially, I need to handle structured data, like json.
This article popped up on HN recently and is a great intro to CRDT implementation. It says OT is much more difficult. http://archagon.net/blog/2018/03/24/data-laced-with-history/
That's included in my research links, yes :D
Re: OT and CRDT trade-offs for Real-Time collaboration
#10The only thing I remember from the CKEditor post from last year was that it took "42 man-years" to implement: https://news.ycombinator.com/item?id=18220020
I wonder if it's better understood now and can cost less R&D time.