The data structure is a WAL storing all mutation events, each of which has a reference to another uniquely identifiable item (by some UUID:timestamp combo). Rather than treating each line as a uniquely identifiable object, I could treat each character as such.
Downside of the current implementation is that two people operating offline on the same line will see unpredictable results when they're able to sync again (basically it will just honour the most recent update event). The per-char change above would remedy that, I think!
> IIRC CRDTs do not work well for Google-docs type text editing because they cannot capture intent well.
Could you elaborate? Appreciate the discussion
https://www.tiny.cloud/blog/real-time-collaboration-ot-vs-cr...
Some teams also encountered engineering problems using them.
https://news.ycombinator.com/item?id=24186883
Done properly however, they can be magical.
http://archagon.net/blog/2018/03/24/data-laced-with-history/...
I hope that there are existing implementations of OpSets that perform well. I find the solution laid out in that paper to be really elegant and beautiful.