Thank you @bminer, Yjs indeed doesn’t use locking. It is an eventual-consistent “database” that synchronizes without central coordination. The whole concept of time is problematic in decentralized, eventual-consistent databases.
Most CRDTs implementations don’t rely on the concept of physical time (as in time based on a unix timestamp; or a GMT timestamp). Mostly, they have a relative understanding of time, based on Lamport Timestamps. In Yjs, and many other CRDTs, LWW means that when concurrent writes happen, one of the writes will win. It doesn’t necessarily have to be the one that was created “before” based on our physical experience of time. Once clients synchronize, their relative clocks are in order and we can, once again, detect whether a client performed an action concurrently.
The reason for this is that it is impossible to synchronize time-clocks. Some computers around the world have broken time devices, or are simply desynchronized with NTP servers. NTP servers broadcast a fairly accurate timestamp (based on physical time) to computers and try to keep them more-or-less in sync. However, this is unreliable and doesn’t always work. It’s normal that clients are desynchronized by a few seconds. So a decentralized last writer wins implementation based on physical time is likely to favor clients that don’t synchronize with NTP servers, which is a huge problem. Hence, we use the relative concept of time instead because it is impossible to synchronize time.
The last time I explained this people cited some article from how Amazon synchronizes their times. Note that these are huge server-farms that are located very close to each other through a reliable network connection. This can’t be done with consumer computers that are often located at places with bad internet access.