We know now that the server reconciliation approach does work for text, so long as you assign each character an ID instead of trying to use array indexes: mattweidner.com/2025/05/21/t...
Posts by Matthew Weidner
I learned of this from the first paper on collaborative text editing (dl.acm.org/doi/abs/10.1...), which cites the idea but claims it won't work for text. Instead they introduce Operational Transformation, which led to a lot of academic work but is more complicated.
The report is "Computer-Based Real-Time Conferences" by Sunil Sarin and Irene Greif, dspace.mit.edu/handle/1721....
Fun academic find: the core idea of server reconciliation (a general approach to real-time collaboration that's simpler than Operational Transformation or CRDTs) already appears in an MIT tech report from 1985.
More on this simple path to collaborative apps, as an alternative to the Operational Transform / CRDT rabbit hole, in my recent DWeb Seminar talk: docs.google.com/presentation...
For many collaborative apps, though, you can get away with just serializing all users' ops. E.g., apply ops in the order a server receives them. This strategy appears in Replicache and in @tanstack.com DB (taking over from ElectricSQL v0's fancier CRDT-based strategy).
In essence, the authors found that text editing is hard - at least when you address each char by its ever-changing index instead of a fixed ID - but concluded that *collaboration* is hard, requiring partial-order thinking & fancy algorithms. That set the tone for a whole field.
(The paper is "Concurrency control in groupware systems", Ellis & Gibbs 1989. doi.org/10.1145/6754...)
From the ~1st collaborative text editing paper: if two users do "delete char @ index 7" concurrently, no serial ordering gives the correct answer. So the authors abandon serializability, leading to OT/CRDTs. But if you rephrase the ops as "delete char @ <per-char id>", both serial orders work!
It took almost two years…! The Fugue paper that @mweidner.bsky.social and I wrote about interleaving in collaborative text editing algorithms was finally accepted by IEEE Transactions on Parallel and Distributed Systems
paywalled: ieeexplore.ieee.org/document/111...
free: arxiv.org/abs/2305.00583
I made a guest post on @powersync.com's blog: powersync.com/blog/collabo...
It describes a demo we made of collaborative text editing on top of PowerSync's DB sync engine, using character IDs & totally-ordered updates in a DB table (w/o CRDTs).
Watch @mweidner.bsky.social talk about collaborative text editing without CRDTs or OT. youtu.be/5CFrpd0sG-g?...
"Collaborative text editing without CRDTs or OT"
Awesome talk from @mweidner.bsky.social on how you don't need CRDTs to build collaborative text editing.
Together with my last blog post (mattweidner.com/2024/06/04/s...), this should let you build central-server collaborative apps with *no* tricky CRDT or OT algorithms! (Though CRDT ideas are still helpful.)
I'll be talking about this approach at Local First Conf next week.
New blog post: "Collaborative Text Editing without CRDTs or OT". It describes what I hope is a simpler and more flexible approach to the hardest part of a collaborative app, text editing. mattweidner.com/2025/05/21/t...
I'd be interested to see those if you can find them.
I do wonder to what extent rebasing SNAFUs can be "solved" with cleverer mutations, or if you need to fall back on branches / version control for any amount of offline editing.
I heard about Jupyter's prototype collaboration using Yjs back in 2021 - neat that they are still making progress with it!
I look forward to talking about some new ideas from my work at Common Curriculum & CMU!
Screenshot of classification table from the blog post
My most recent blog post (from last summer): Architectures for real-time collaborative apps using a central server. It includes classic CRDT/OT approaches, why those might be overkill, and a classification table for existing apps/tools. mattweidner.com/2024/06/04/s...