Raph Levien posted a retrospective about using CRDT’s for collaborative editing in xi-editor here [1]. His conclusion is

“I come to the conclusion that the CRDT is not pulling its (considerable) weight. When I think about a future evolution of xi-editor, I see a much brighter future with a simpler, largely synchronous model, that still of course has enough revision tracking to get good results with asynchronous peers like the language server.”


To put it in a different perspective, plain text editing has well-solved CRDT patterns. But, semantic data-structures like rich-text or syntax trees is what's tricky and has unsolved challenges.

Peritext[1] is the only one that came close to solving rich-text, but even that one left out important aspect of rich-text editing like handling list & table operations as "work to be done later".

For people interested on why it's difficult to build CRDTs for richtext, here's a piece I wrote a year back: https://writer.zohopublic.com/writer/published/grcwy5c699d67...

Related HN discussion: https://news.ycombinator.com/item?id=29433896

[1] https://github.com/inkandswitch/peritext

This reminds me of Oracle’s SCN which blew my mind back in ~2009 when I moved up from mysql home gamer stuff to the corporate world.

> Even long edit histories barely compare to the memory savings Zed obtains from not being built with Electron.

I got a good chuckle out of this. Speaking of performance, I think it’s I nteresting that ms word and google docs are still using OT rather than CRDT. The goog version seems to work well but I have had nothing but frustration with ms word. Bad merges and weird states are typical, particularly from the fat client.

Anyone else interested in the background of OT vs CRDT might find this thread useful: https://news.ycombinator.com/item?id=18191867

Very cool use case for CRDTs! I've seen a bunch of different use cases from other products like https://liveblocks.io/ and https://electric-sql.com/. It's interesting how CRDTs are now taking hold so much for all these collaborative syncing scenarios. Wonder what's driving the proliferation now given they've been around for awhile?
Yeah CRDTs are pretty annoying for collaborative text editing, even Google Docs doesn't use them. Some companies have switched from CRDTs back to traditional methods.
Has Microsoft published anything about their pairing plug-in for VS Code?
This webpage crashed my iPad 6 Gen Safari when repeatedly scrolling down without reading (iPadOS 16.1.1). It’s probably just too little memory, but still, isn’t this just a blog post?
if everyone is in the same area one could/should just pretend the client is a terminal(?)



*Douglas Engelbart

(The picture has the name wrong. Maybe intentionally, as some kind of typo which one wants to edit out, hinting at multiple people editing a document?)

I'm developing a new type (AFAIK) of database that makes many types of real-time multi-player use-cases really easy to implement. The original idea came from implementing something called "rollback netcode" in multi-player video games, but the technique works for all types of applications.

Traditional databases (e.g. sql databases and key-value stores) treat the database as a blob of data. This makes multi-player updates very difficult, as reconciling differences in real-time is a hard problem, hence the invention of CRDTs. My new database, however, treats the data as a series of events. In the example of a text editor, the stream of events might be something like: User 1 connected, User 1 pressed key a, User 2 connected, User 2 pressed b, User 1 disconnected, etc.

In addition to the stream of events, application developers also provide an "engine" that converts the stream of events into a blob of data. The engine runs locally on each connected client. When a client connects to the database, they fetch the engine from the database server. The client then receives the stream of events from the database server in real-time. When a client generates an event, it gets inserted into the local engine immediately and also gets broadcasted to the server. The server then broadcasts the event to other connected clients.

The most important part that makes this work comes from a technique called rollback netcode. Events in the stream are ordered and undo-able. When a connected client generates an event, they insert it into their local engine immediately, but other clients are also generating events simultaneously. If all clients optimistically inserted events locally, the event order would differ across clients. To solve this, the engine automatically will undo events when new events come in from the server. The engine then applies the received event in its proper place and reapplies all the undone events on top. The result is that all users have a consistent view of the data.

The logic of an engine looks something like this:

1) When User X connected, set X's cursor position to offset 0.

2) When User X types a letter, insert text at User X's cursor offset and increase User X's cursor offset by 1. Also increment the cursor offset of all other connected users if their cursor offset is > User X's.

And that's it for a basic insert-only text editor. You can see that applying all the events in order yields the correct state. Adding a moveable cursor and the ability to remove text is also trivial. Basically just the opposite of 1 and 2 above. The whole engine can be implemented in like 100 lines of code and is very easy to reason about.

How do the editor CRDTs integrate with source control?
I wonder what happens when an edit can not be delivered to 1+ participant(s). Does an edit need aknowledgements from _all_ participants to be persisted? Is it just dropped?
As a Windows user, I'd be pretty concerned about the multiplatform story here. They say that this is MacOS only for now but they intend to eventually ship a Windows App, Linux App and web app.

It just sounds like a recipe for a Sketch situation where it's really just a Mac app and web (and other platforms) is a second class citizen.