We have a local-first app. Our approach?

Just ignore the conflicts. The last change wins.

No, really. In practice for most cases the conflicts are either trivial, or impossible. Trivial conflicts like two people modifying the same note are trivial for users, once you have a simple audit log.

And impossible conflicts are impossible to solve automatically anyway and require business processes around them. Example: two people starting to work on the same task in an offline-enabled task tracker.

▲

moggers123 4 days ago | parent | next [-]

>Example: two people starting to work on the same task in an offline-enabled task tracker. Wouldn't this just mean both people are working on it?

I agree that this means humans intervening.. It sounds like there was a comms breakdown. But rather than doing a first-in-best-dressed, it sounds like accurately recording that both users are in fact working on the same thing is the best option since it surfaces that intervention is required (or maybe its intentional, tools insisting that only one person can work on an item at once annoys me). Sounds much better than quietly blowing away one of the user's changes.

In principle, local-first to me means each instance (and the actions each user carries out on their instance) is sacrosanct. Server's job is to collate it, not decide what the Truth is (by first-in-best-dressed or otherwise).

▲

cyberax 4 days ago | parent [-]

Sure. But then you need to notify users when they come back online that there's a conflict, so they can resolve what to do. You likely need to have a report on the frequency of such occasions for the managers, and so on.

These kinds of conflicts simply can not be solved by CRDTs or any other automated process. The application has to be designed around that.

> In principle, local-first to me means each instance (and the actions each user carries out on their instance) is sacrosanct. Server's job is to collate it, not decide what the Truth is (by first-in-best-dressed or otherwise).

This makes sense only for some applications, though.

And we have not yet started talking about permissions, access control, and other nice fun things.

	▲	evelant 3 days ago \| parent \| next [-]
		I’ve been experimenting with this, it’s a very interesting problem space! https://github.com/evelant/synchrotron Idea is to sync business logic calls instead of state. Let business logic resolve all conflicts client side. Logical clocks give consistent ordering. RLS gives permissions and access control. No dedicated conflict resolution logic necessary but still guarantees semantic consistency and maximally preserves user intentions. That’s the idea at least, requires more thought and hacking.
	▲	moggers123 3 days ago \| parent \| prev [-]
		I doubt you'll ever see this.. Oh well.. I probably should have been explicit in that I'm not arguing in favor of CRDTs, just that the adverse doesn't need to be "send it and accept the collateral". Draw The Rest Of The Owl energy here, but at least its a nice northern star.

▲

giancarlostoro 3 days ago | parent | prev | next [-]

Wouldn't it be less of an issue if you track the change history, and let users pick a specific historical version? Then it doesn't matter who wins, the end-user can go in and change it. Version control is one of the best parts about Google Docs.

▲

kobieps 3 days ago | parent | prev | next [-]

Who is the audience of your app? Is it an internal app for a company, or is it a public facing consumer app?

▲

cyberax 3 days ago | parent [-]

Public app used by professionals in the field, often with poor or no connectivity. Even having a local read-only copy of data is often helpful for them.

	▲	kobieps 3 days ago \| parent [-]
		Cool. Yeah in my experience last-write-wins is sufficient for 95% of use cases, and if you add audit trails to help resolve any disputes it gets you to 98%

▲

sakesun 4 days ago | parent | prev | next [-]

Just have audit log. No need to try solving every trivial cases. Make something useful.

▲

kazinator 4 days ago | parent | prev [-]

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.