Hacker News new | ask | show | jobs
by immibis 434 days ago
Text editing CRDTs fall in the category of things that are technically possible, in an incredibly useless way - just like it's possible to automatically "resolve" every Git merge conflict by randomly splatting the conflicting lines around in the file.
3 comments

Most collaborative text editors use CRDTs, OT, or a derivative nowadays. For the most part, the paradigm works fine: changes aren't just "randomly splatted" around the file but appear in their expected causal context. Strange things can happen when paragraphs are deleted or moved around, but this is more of a UI problem than an intrinsic limitation, and I'm not sure what alternative you're thinking of other than locking or throwing up a horrible "pick a version" dialog box.
It's more of a UI/UX problem than a hard limitation. For uses cases that require collaboration with offline editing, the person that last merges might be given a split view to sync their changes.

Again, syntactically possible, semantically harder, but it depends on your use-case plus additional constraints (eg max offline time). Maybe not a fully automatic system, but still very useful.

CRDTs with LLM suggested conflict resolution might just be the thing.

Next best thing is keeping conflicts unresolved, but marked as such as a first-class citizen of the document content (see pijul, jj).

But then you don’t get convergence which is a requirement and LLMs will be just as good for Git as they will be for CRDTs.
I postulate they may handle written language quite well, within reasonable bounds. Re convergence, turns out it's much more convenient to let conflict resolution be deferred.
You can get convergence with the same mechanism that OT uses for compaction: assign a special server role that does it.