Hacker News Reader

Comment by hem777 | Hacker News Reader

How about having the state 100% on server AND on client? No dragons, no problems.

Keeping them in sync is the dragon

CRDT is the dragon slayer

It's the sword that we needed! But it doesn't take us all the way. There are semantic conflicts that are difficult for CRDTs to solve alone.

What are the semantic conflicts you mean here?

As far as I can tell, CRDTs are the correct solution for syncing state between parties.

Merge conflicts that must be resolved by the user (i.e. when there is no logical way to determine the priority of two offline changes) are still an application specific problem, even with CRDTs. You can build structures that allow storing conflict resolutions in CRDTs, but getting them right is still like half the problem to solve.

Yes, sometimes it is hard to come up with the merge strategy that preserves user intent. I think the big one is rich text, where Peritext[0] looks like a good direction.

[0]: https://www.inkandswitch.com/peritext/

I have lack of imagination to think what kind of conflicts those would be, would you have examples?

In my experience there’s always a logical way to solve conflicts. And CRDTs can have any kind of conflict resolution algorithm, so it’s customizable per application. “Storing conflict resolutions”, eg. “a merge operation”, is not needed and unnecessarily complicates any CRDT.

This is the correct answer :)

How do you prevent sync issues?

One local DB/store for each app. Who is the correct sync?

Or is it first in first out?

CRDTs is how sync issues become non-issues. The “correct sync” is deterministically determined by the CRDT conflict resolution algorithm. There can be multiple DBs/stores per app or per user or per whatever makes sense. One big global DB/store broken down to millions of DBs/stores.

Then you get to deal with conflict resolution, which is a rare dragon that is kind of confusing and sometimes has to ask the user which state they'd like to keep.

Not if you assume the server is always right. Which is suitable for the majority of cases.

Another possibility is to assume the user is the authority and is always right. For example, if I post a tweet to my feed, I’m (or should be) the authority and always right.

Reply on news.ycombinator.com