3 ms·

Zero (zerosync.dev) uses transactional conflict resolution, which is what our prior product Replicache and Reflect both used. It is very similar to what multipl

Zero (zerosync.dev) uses transactional conflict resolution, which is what our prior product Replicache and Reflect both used. It is very similar to what multiplayer games have done for decades. It is described here: https://rocicorp.dev/blog/ready-player-two https://rocicorp.dev/blog/ready-player-two It works really well and we and our customers have found it to be quite general. It allows you to run an arbitrary transaction on the sever side to decide what to do in case of conflicts. It is the software equivalent of git asking the user what to do. Zero asks your code what to do. But it asks it in the form of the question "please run the function named x with these inputs on the current backend db state". Which is a much more ergonomic way to ask it than "please do a 3-way merge between these three states". Conflict resolution is not the reason why there has not been a general-purpose sync engine. None of our customers have ~ever complained about conflict resolution. The reason there has not been a general-purpose sync engine is actually on the read side: - Previous sync engines really want you to sync all data. This is impractical for most apps. - Previous sync engines do not have practical approaches to permissions. These problems are being solved in next generation of sync engines. For more on this, I talk about it some here: https://www.youtube.com/watch?v=rqOUgqsWvbw https://www.youtube.com/watch?v=rqOUgqsWvbw

probabletrain 2y ago
I think with good presence (being able to see what other users are doing) and an app that isn't used offline, conflicts are essentially not a problem. As long as whatever is resolving the conflicts resolves them in a way that doesn't break the app, e.g. making sure there aren't cycles in some multiplayer app with a tree datastructure. Sounds like Zero has the right idea here, I'll build something on it imminently to try it out.
- Sammi 2y ago
  Agree that if you don't have offline support, then conflict resolution is such a minor issue that you can just do "last write wins" and call it a day.
probabletrain 2y ago
> Previous sync engines really want you to sync all data Linear had to do all sorts of shenanigans to be able to sync all data, for orgs with lots of it – there's a talk on that here: https://www.youtube.com/watch?v=Wo2m3jaJixU&t=1473s https://www.youtube.com/watch?v=Wo2m3jaJixU&t=1473s
Sammi 2y ago
"It is the software equivalent of git asking the user what to do. Zero asks your code what to do." You are asking the dev what to do. You are _not_ asking the user what to do. This is akin of the git devs baking in a choice into git on what to keep in a merge conflict. It's hard to trust you guys when you misrepresent like this. I thought long and hard on whether to respond confrontationally like this, but decided you really need to hear the push back on this.
- aboodman 2y ago
  lol wut? I represented that we ask the dev what to do: > Zero asks your code what to do You agree that's what we do: > You are asking the dev what to do. You are _not_ asking the user what to do. I get that your actual issue is you don't think that what we do is "the software equivalent of git asking the user what to do". But like, I also said what we do concretely in the same paragraph. It's not like I was trying to hide something. This is a metaphor for how to understand our approach to conflict resolution that works for most developers. Like all metaphors it is not perfect. FWIW, there is nothing stopping a developer from having this function just save off a forked copy and ask the user what to do. Some developers do this. Also FWIW, Zero does not allow offline writes specifically because we want to educate people how to properly handle conflicts before we do. I see down-thread this is the majority of your concern.
  - Sammi 2y ago
    I assumed you were doing offline support yeah. I've heard a lot about local first development lately, so I guessed this what what you guys are tackling too. Without offline support AND you're doing real time updating of data, then conflict resolution is not a real world practical concern. Users will be looking at the same data at the same time anyways, so they generally see what data won out in case of a conflict, as they are looking at real time data as they are editing. IF you had offline support, and for other sync engines that do: There is a real and meaningful difference between a backend dev and an end user of the application choosing what to do in case of a conflict. 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.
lifty 2y ago
Is Zero based on prolly trees?
- aboodman 2y ago
  No. When we started the project we used prolly trees initially, but we don't need the content addressing feature for Zero and all the hashing was quite expensive. So now we just use a plain immutable b-tree: https://github.com/rocicorp/mono/tree/main/packages/replicache/src/btree https://github.com/rocicorp/mono/tree/main/packages/replicac...

probabletrain 2y ago

I think with good presence (being able to see what other users are doing) and an app that isn't used offline, conflicts are essentially not a problem. As long as whatever is resolving the conflicts resolves them in a way that doesn't break the app, e.g. making sure there aren't cycles in some multiplayer app with a tree datastructure. Sounds like Zero has the right idea here, I'll build something on it imminently to try it out.

Sammi 2y ago
Agree that if you don't have offline support, then conflict resolution is such a minor issue that you can just do "last write wins" and call it a day.

probabletrain 2y ago

> Previous sync engines really want you to sync all data Linear had to do all sorts of shenanigans to be able to sync all data, for orgs with lots of it – there's a talk on that here: https://www.youtube.com/watch?v=Wo2m3jaJixU&t=1473s https://www.youtube.com/watch?v=Wo2m3jaJixU&t=1473s

Sammi 2y ago

"It is the software equivalent of git asking the user what to do. Zero asks your code what to do." You are asking the dev what to do. You are _not_ asking the user what to do. This is akin of the git devs baking in a choice into git on what to keep in a merge conflict. It's hard to trust you guys when you misrepresent like this. I thought long and hard on whether to respond confrontationally like this, but decided you really need to hear the push back on this.

aboodman 2y ago
lol wut? I represented that we ask the dev what to do: > Zero asks your code what to do You agree that's what we do: > You are asking the dev what to do. You are _not_ asking the user what to do. I get that your actual issue is you don't think that what we do is "the software equivalent of git asking the user what to do". But like, I also said what we do concretely in the same paragraph. It's not like I was trying to hide something. This is a metaphor for how to understand our approach to conflict resolution that works for most developers. Like all metaphors it is not perfect. FWIW, there is nothing stopping a developer from having this function just save off a forked copy and ask the user what to do. Some developers do this. Also FWIW, Zero does not allow offline writes specifically because we want to educate people how to properly handle conflicts before we do. I see down-thread this is the majority of your concern.
- Sammi 2y ago
  I assumed you were doing offline support yeah. I've heard a lot about local first development lately, so I guessed this what what you guys are tackling too. Without offline support AND you're doing real time updating of data, then conflict resolution is not a real world practical concern. Users will be looking at the same data at the same time anyways, so they generally see what data won out in case of a conflict, as they are looking at real time data as they are editing. IF you had offline support, and for other sync engines that do: There is a real and meaningful difference between a backend dev and an end user of the application choosing what to do in case of a conflict. 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.

lifty 2y ago

Is Zero based on prolly trees?

aboodman 2y ago
No. When we started the project we used prolly trees initially, but we don't need the content addressing feature for Zero and all the hashing was quite expensive. So now we just use a plain immutable b-tree: https://github.com/rocicorp/mono/tree/main/packages/replicache/src/btree https://github.com/rocicorp/mono/tree/main/packages/replicac...