
“Stateless” sync using version vectors - archagon
http://archagon.net/blog/2018/09/03/good-spirits-persisting-data-statelessly/
======
allenu
I solved a similar problem in my to-do app by just having a journal of diffs
per each device. To "sync" you just upload your device's journal to a shared
file store (say, Dropbox) and then download all the other devices' journals.
You merge all the diffs to get the "latest" state of the database. Conflict
resolution is last write wins, but at the individual property level (two
devices can update a to-do task and update different properties).

This actually works perfectly fine for my needs because a single user is not
likely to be modifying two tasks across two devices at the same time. It may
actually work for this project as well (since it's single user). You can check
out the code here:
[https://github.com/allenu/slouchdb](https://github.com/allenu/slouchdb)

~~~
maxxxxx
"Conflict resolution is last write wins, but at the individual property level
(two devices can update a to-do task and update different properties)."

Depending on your use case property by property conflict resolution works
great but it can also go horrible wrong with some data. Do you have timestamps
on each property?

~~~
heavenlyblue
I would assume every diff has a timestamp. And since you can diff properties
separately then it works correctly.

I would be curious about another scenario: what about several devices
generating a new password for a website? Or instead - creating a note with the
same name?

The one that is going to be saved is the last one - that is true. But it
implies there's some transparent data loss in the background (you could still
get those from the log, of course).

How do you deal with those "soft" conflicts in the UI? Is there any learning
curve for the user to accept that any changes could be rolled back? How do you
display that so that the user wouldn't assume the data was lost?

~~~
Normal_gaussian
With respect to the notes of the same name - you can key the items with a
generated id and "namespace" the keys with a journal specific id to avoid
conflicts. In this way two notes having the same name is 'ok' as they have
different keys.

It would help to have a user guided merge feature that can be manually
triggered by combining items (not just on conflict)

~~~
allenu
This is exactly what I'm doing with my solution.

------
CGamesPlay
If I'm imagining this correctly, it's a lot like a Redux application flow, but
with partially ordered Actions and a last-write-wins conflict resolution. I
need to take a deeper look at the CRDT explorations link, but is this close to
a fair analogy?

