I finally sat down and wrote about how can vector clocks and repository update cloks be used to prevent accidental overwrites in case there are conflicts. Together with nat piercing is one of the two most desirable features to have.
It’s here:
In case anybody wants to have a look and give some feedback.
Sure. So far given the amount of nodes a syncthing cluster might have, I don’t see a compeling reason why it wouldn’t work. Do you see some blockers on the algorithm?
I don’t think there’s a theoretical problem here, but there are practical issues around interpreting the meaning of vector clocks when two devices have different opinions on what devices are part of the cluster, or when the cluster members change. At least unless each clock is kept as a set of (device, value) tuples which I think gets too inefficient - but maybe it wouldn’t, coding it up and trying it out would be interesting. Even then, you’d have to decide what it means to compare two clocks {A: 1, B: 42, D: 12} and {A: 1, B: 42, C: 23}.
In that case there’s a conflict as D did modifications concurrenly with C, I would create a conflict file like file_conflict_d12 or file_conflict_d23 depending on the configuration, or last write wins if the user specified that.