The first example also reveals the crux of the issue. The actual problem is that the merging intent is not mathematically solveable in a satisfying manner.
E.g. let's say two people edit the body element depending on the content of the Edit the best solution¹ could be to take both contents (in which order?), to just take one, to take neither or to merge them semantically into a new third thing.
Meaning there are two obvious ways of going for a better merging solution:
1. Retain the ambiguity (if there is one) and present it to the users and let them decide
2. Use an LLM to guess the intent of both edits and task it to resolve the ambiguity if resolveable
¹: with best I mean the the solution real humans merging text from two pieces of paper would chose
Yep, the combined intent of two people cannot be established automatically when they cannot see each other's changes or understand each other's reasoning. Figuring out the collaborative intent for conflict resolution would require mind-reading.
The right UX for scenarios where accuracy is essential is to let users know when they are offline. The offline-enabled approach is not suitable for a lot of situations.
As someone I trusted in source control once pointed out: often the source of a conflict may be social or political or miscommunication. As much as we all want technical solutions for sociopolitical problems, the real answer is still often communication and that any {source control; collaborative editing; etc} tool is only as good as its merge conflict UX is at communication between involved parties.
I think we've gone far enough down the road of "we can solve all CRDT merge conflicts through technical wizardry" that the next steps are "what is the right merge conflict UX when people should be communicating?" not just "what can we solve technically and never show the user?"
The first example also reveals the crux of the issue. The actual problem is that the merging intent is not mathematically solveable in a satisfying manner.
E.g. let's say two people edit the body element depending on the content of the Edit the best solution¹ could be to take both contents (in which order?), to just take one, to take neither or to merge them semantically into a new third thing.
Meaning there are two obvious ways of going for a better merging solution:
1. Retain the ambiguity (if there is one) and present it to the users and let them decide
2. Use an LLM to guess the intent of both edits and task it to resolve the ambiguity if resolveable
¹: with best I mean the the solution real humans merging text from two pieces of paper would chose
Yep, the combined intent of two people cannot be established automatically when they cannot see each other's changes or understand each other's reasoning. Figuring out the collaborative intent for conflict resolution would require mind-reading.
The right UX for scenarios where accuracy is essential is to let users know when they are offline. The offline-enabled approach is not suitable for a lot of situations.
As someone I trusted in source control once pointed out: often the source of a conflict may be social or political or miscommunication. As much as we all want technical solutions for sociopolitical problems, the real answer is still often communication and that any {source control; collaborative editing; etc} tool is only as good as its merge conflict UX is at communication between involved parties.
I think we've gone far enough down the road of "we can solve all CRDT merge conflicts through technical wizardry" that the next steps are "what is the right merge conflict UX when people should be communicating?" not just "what can we solve technically and never show the user?"