CRDTs?

Has the Syncthing team ever considered using CRDTs?

From that page: ‘CRDTs ensure that, no matter what data modifications are made on different replicas, the data can always be merged into a consistent state. This merge is performed automatically by the CRDT, without requiring any special conflict resolution code or user intervention.’

They are specifically designed for decentralised applications, and for gracefully handling conflicts, so seem to be a very good fit for Syncthing and opportunity to greatly streamline conflict resolution.

From some cursory research on CRDT libraries in Go: go-ds-crdt; Automerge has a Go library; Yjs exists too although it doesn’t seem to have properly fleshed-out Go bindings yet.

I don’t think they really bring us anything we don’t already have. The principle of a CRDT is that you build a data structure that can have certain properties (like, a counter or a set of integers, with rules for how to order updates), but we really have only one “data structure” that can have conflicts: a file. At that point a CRDT just provides primitives like “last write wins” or various virtual clock orderings, which is what we do with version vectors. At least that’s my understanding. Files that can be edited simultaneously on multiple devices don’t become “conflict free” no matter how we wrap them.

4 Likes

Concurrent move operations in a directory tree may also cause conflicts:

  1. Two replicas move the same directory/file to a different place → Which one is the correct one?
  2. Two replicas move directories such that after both operations are considered, there is a cycle in the tree → Only one of these move ops is allowed, which one?