One solution is to make it so that people see their literal keystrokes in real time. Then they solve the conflict themselves. Like, "stop typing into this text because bob is typing into it".

It's like Ethernet conflict resolution: just access the shared medium and detect collisions in real time.

▲

avemg 4 days ago | parent | next [-]

How will you know that Bob is typing into it if you're offline?

▲

kazinator 4 days ago | parent [-]

That's a fair question; we here being under a submission aout local-first apps, and al.

Of course, you know the answer: if you're offline, you're not online. Bob gets to type whatever Bob wants, and until you go online, you don't get to overtype anything.

▲

ongy 4 days ago | parent [-]

But the offline enabled property allows exactly that.

Both sides type offline and only sync later. Neither would like their change to just be discarded.

	▲	kazinator 3 days ago \| parent [-]
		I was responding only to the idea of having no conflict resolution: last edit wins (proposedin a great grandparent comment): https://news.ycombinator.com/item?id=45341335 "We have a local-first app. Our approach? Just ignore the conflicts. The last change wins." if you can see the edits being made in real time, keystroke by keystroke, that pretty much solves that problem. As for offline editing, either don't support it (then you're not local-anything obviously) or you can have some lame workflow like "the document was changed by another user ..."

▲

cyberax 4 days ago | parent | prev [-]

It's fine if you're talking about a text editor or an Excel table. And it's one of the few cases where CRDTs make sense.

If you have a CRM-like application with a list of users? Not so much.