They really are a theoretical model of how distributed, convergent, multi-master systems have to work. IE the DT in CRDT could be a whole datastore, not as just an individual document.
(Wish I could remember who on HN alerted me to this. I had read the paper but didn't grok the full implications).
Regardless, thanks very much for linking the paper! Right up my alley.
https://pages.lip6.fr/Marc.Shapiro/pubs.html#CRDTs
The original paper would be https://hal.inria.fr/inria-00177693/
(We have a central server and the app works offline so the algorithm from the linked article doesn't apply in our case.)
Even scale-ups with thousands of users will have people working on different parts of the document tree in practice. The client doesn't need to receive every keystroke for people editing somewhere far away in the document tree. Those updates can be sent in batches every once in a while.
If 10.000 people decide to edit the exact same location in a document then performance will degrade. The client will start to lag behind if it can't keep up with the stream of updates (cpu or internet bottleneck) but eventually it will process everything and all clients will end up with the same state. We have two channels. One for state updates (soft real-time) and one for UI hints ("hard" real-time) and other user actions that aren't CRDT mutations.