3D Mobile Backup Sync Conflict Resolver

Edit offline

Connectivity

Merge strategy

Vector clock A

[0,0]

Vector clock B

[0,0]

Conflicts resolved

Fast-forward syncs

Sync log

Ready. Edit both devices while offline, then reconnect.

How it works

Each device keeps a version vector [cA, cB] — one counter per device, incremented only by its own edits, forming a causal history rather than a wall-clock timestamp.

dominates(X, Y): every component of X ≥ Y, and at least one is strictly greater
X dominates Y  → Y is stale, fast-forward it to X
neither dominates → edits are concurrent → CONFLICT

Fast-forward — one vector clock dominating the other means no data was lost; the packet you see fly through the hub simply replays the newer state onto the stale device.
Vector-clock conflict — when neither vector dominates, both devices made an edit the other never saw before syncing: a genuine concurrent write.
CRDT merge — the counter is a G-Counter merged by element-wise max (nothing is ever lost); the color register blends both concurrent values instead of discarding one, shown as the two packets fusing at the hub.
Last-write-wins — the edit with the later physical timestamp overwrites the other outright — cheaper, but it can silently drop a causally later edit if device clocks skew.

Real-world relevance: this is the same structure behind Dynamo/CouchDB version vectors and CRDT engines like Automerge or Yjs that power offline-first mobile sync.

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.