Conflicts

“Conflict handling” in datadata is not one mechanism but a layered stance: the server orders everything, guards detect collisions, text merges itself, and sessions let a human (or agent) decide.

Layer by layer

1. Server ordering. Every accepted change gets the document’s next sequence number. There is no distributed disagreement about history — the folder’s server is the authority.
2. Guards. A write can demand that the document (or just the values it touches) hasn’t changed since the writer last saw it. A failed guard rejects the write cleanly — conflict detection without locking.
3. CRDT text. Inside Yjs fields, concurrent edits always converge; there is nothing to detect or resolve.
4. Three-way preview. The session client holds a base snapshot for every staged document. When the live head moves, conflicts are derived — base vs. head vs. staged — and presented for resolution before commit. Nothing is auto-merged behind your back.

What this is not

datadata does not do operational transformation, and does not use CRDTs for structured data. Two writers blindly racing on the same field get last-write-wins ordering from the server unless one of them used a guard — the system favors explicit, reviewable conflict handling over silent merging. Why we landed here, and what it costs, is covered in Design decisions.

Gaps & open questions

Conflict presentation is still evolving: the three-way preview gives you the data, but patterns for resolving (field-level pick-and-choose vs. restage-from-head) are being worked out in the apps. See Open questions.