| > Without offline support AND you're doing real time updating of data, then conflict resolution is not a real world practical concern. I disagree with this. There are many real-world cases where keywise lww does the wrong thing. The article I linked up-thread covers many of them. Even a simple counter does the wrong thing. This is where robust conflict resolution really matters in these systems, not the long-time offline case people often ask about. You need robust conflict resolution to make correct software and maintain invariants in the face of write/write systems. > A backend dev cannot make a general case algorithm that knows that two end users want to keep or throw away in a conflict, because this is completely situational - users could be doing whatever. And if you push the conflict resolution to the end users, then you are asking a lot of those users. They need to be technically inclined and motivated people in order to take the time to understand and resolve the conflict. Like with git users. I agree completely. In my opinion the ideal offline-first write/write UI has never been built, but the team at Ink & Switch are closest: https://www.inkandswitch.com/patchwork/notebook/ I think the perfect UX in many cases is that syncs goes ahead and tries to land the offline writes, but the user has a history UI where they can see what happened. Like how many collaborative apps do today. But importantly in this UI the app would represent branches and merges. But unlike Git's fine grained branch/merge points, in this UI it would literally represent points where people went offline and made changes. Users could then go back and recover the version of their data from when they were offline, or compare (probably manually in two tabs) the two different versions of the data and recover. This does still ask users to compare and resolve conflicts in the worst case, but it is not a blocking operation or one that is final. The more common case is the user will go ahead with the merge and sometimes find some corruption. They can always go back and see what went wrong after the fact and fix. This seems like the right tradeoff to me of making the common case (no conflict) easy and automatic but making the uncommon but scary case at least not dangerous. There also needs to be clear first-class UX telling users that they're going offline and what will happen when they come online. I'm looking forward to someday working on this, but it's not what our users ask about most often so we're just disabling offline writes for now. |