[marknadal]

Thanks, did not see that. Not all vector clocks provide conflict resolution though - actually, they can very much lack in this regard. For instance, you are much more likely to get two clients that increment to the same vector while offline than two clients getting the exact same millisecond timestamp.

Which would make the problem worse, not resolved. What type of vector are you using?

[simonask]

Simon from Realm here - just wanted to chime in and clarify some details on this. It would be more correct to say that we are using Lamport timestamps, with the addition of a globally unique ID for each client and some tracking of changeset ancestry. No two identical [timestamp, id] tuples will ever be produced in our system, so there is always an unambiguous way to decide which side "came first" in case of a causally unrelated conflict.

It's important to understand that most "conflicts" in our system are resolved without resorting to timestamps at all, which is possible due to the way we encode our changesets on the wire and the fact that we track their ancestry. It is only used in cases where we absolutely have to, i.e. when there is no causal relationship between two updates of the same property (in which case, the "later" timestamp wins).

Hope that answered your question. :-)

[eloff]

Is this documented somewhere? Understanding how sync works here and under what circumstances the timestamp is required to resolve conflicts is critical to understanding how to design correct applications based on this.

[jlu]

Thanks for the details, just wondering is the implementation mentioned here available to review somewhere? Is it included in the realm core repo?

[marknadal]

Awesome. Thanks!