What CRDTs, distributed editing and the speed of light means to your writer friends
summary
Explains why Operational Transforms require a central server (Google Docs style) and fail for three+ peers because TP2 is unsolvable for typical OT implementations, then shows practical CRDT alternatives: a fast ordered-sequence CRDT called LSEQ that uses exponential trees (branch factor ~10), immutable IDs, no tombstones and O(log n) edits, plus a note on a JSON-CRDT paper (Scala reference impl, no robust JS port) and a browser demo using mDNS for peer discovery.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:21Digital Nomads
- 3:37Tools
- 7:49Resolving conflicts
- 10:27Alex and Beth
- 22:29Tricks
- 22:46Notation
- 25:00Tombstones
- 26:30CRDTs
- 29:20Tree Structures
- 40:19Communication
- 44:23Collaborative Editor
related talks
33mDoes the network seem thin up here? Collaborating with mountaintop mesh networks
29mCRDT: Conflict-free Data Types for Collaborative Editing and Offline-First
22mHappily Ever After: A CRDT Fairy Tale
13mHow to make a real-time collaborative text editor in 5 easy steps!
32mCRDT and other new ideas for client-server communication
23mBuilding Offline and Real-Time Applications - The Magic of CRDTs
36mCRDTs Illustrated
34mUsing CRDTs Beyond Text Editors