> Collaborative editing is too much to bite off at once. The semantics of edit conflicts are very app specific and high level. You can get a long way by just ho

> Collaborative editing is too much to bite off at once. The semantics of edit conflicts are very app specific and high level. You can get a long way by just hooking file IO in userspace. I've been working in the collaborative editing space for over a decade at this point. So (predictably) I think it should be a day 1 feature. In my mind realtime collaborative editing is one of the main motivating use cases for this whole system - its one of the things we can't do with traditional local file based software architecture. Based on my experience with collaborative editing I don't think you need a special app-specific conflict resolution strategy most of the time. I think about 95% of applications just need CRDTs for: - Tables with editable values. (Or, equivalently, collections of JSON objects). I think an MVRegister is the way to go here. - Text And then the longer tail of apps need: - Generic sequences (eg for the list of layers in photoshop) - Rich text documents - Text with conflicts (eg for Git) For editing regular data, MVRegisters are the star of the show. MVRegisters - aka Multi-Value Registers usually just store a single value. If two users concurrently set it to different values, when you do a read operation you can either (consistently) choose a single winner, or present the application with all of the conflicting values and let it choose how to resolve the conflict. Its the best of all worlds in my mind - because conflicts are rare in practice, and this lets application developers start simple and make their apps more complex over time as they desire. MVRegisters are also crazy simple to implement.