[marknadal]

@timanglade, congrats to you and your former team! Always awesome to launch, good job.

Full disclosure, I work on a competing product (MIT licensed, https://github.com/amark/gun ) and do a lot of testing on distributed systems.

You guys say it is offline-first with conflict-resolution. However your documentation ( https://realm.io/docs/realm-object-server/#conflict-resoluti... ) states the "Last update wins". This is contradictory for two reasons:

A) Either you mean last write wins relative to the server. But an offline update is going to get sent late (on reconnect), which would make it "last" and lead to weird problems.

B) Or you mean last write wins relative to the time stamp of the client. But this does not account for wall clock drift. What happens if the client's clock is intentionally set 2 years in the future? In a distributed system, everybody has a different "last".

The demo video, while very well done, uses a drawing app which does not really demonstrate real conflict (ie, if 2 users draw over the same space, it becomes a z-index rendering issue, which could be solved with conflict resolution but isn't a good example of conflict).

[timanglade]

See the full answer from Realm’s founder/CEO here: https://news.ycombinator.com/item?id=12590753

[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!