Edits, Versions, and Conflicts
What happens when both sides write.
Convergence, not merging
KeibiDrop synchronizes files, not lines. It never merges the contents of two versions, because for most files (images, video, archives, project files) a merged result would be garbage. Instead it guarantees a simpler property: after edits stop, both computers hold the same bytes for every file, and no version disappears without a trace.
Each save announces a new version of the file to the peer. The newer version wins the file's name on both sides. On a real internet link, an edit reaches the other computer in well under a second (measured numbers).
When a conflict file appears
If both computers save the same file at nearly the same moment, one of them is the newer version and wins the name. The other is not discarded. It is renamed to a conflict file:
report.docx report.conflict-20260801-104512-123456789.docx
The stamp is the UTC time of the preserve. Exactly one conflict file appears per collision, and it syncs like any file, so both computers end up holding both versions. Whichever side you are on, you can open the two files, compare, and decide. Deleting the conflict file when you are done also syncs.
The practical guide is How to handle conflict files.
Why nothing is lost silently
The dangerous case is not the obvious one. Because KeibiDrop streams content on demand, your computer can know about a peer's new version without ever having downloaded its bytes. If you then overwrite that file, a naive sync would conclude you built on the peer's version and drop it. The only copy in the world would be gone.
KeibiDrop's rule closes this: a save only claims to supersede versions whose bytes this computer actually held. Overwriting a version you never fetched preserves that version as a conflict file on both sides. The rule set is small enough that it is checked by exhaustive model checkers, which enumerate every ordering of writes, deliveries, and fetches at this scale and find no history where content is lost silently.
Turn-taking is the happy path
The common real workflow, one person edits, the other picks up later, produces no conflict files at all. Editors that save through temporary files and renames, editors that write in place, autosave storms, and command-line tools all converge cleanly; this is tested with the real save patterns of vim, GIMP, LibreOffice, sqlite3, and ffmpeg, in both directions.
Conflict files appear only when both sides genuinely race on the same file. If you see many of them, the fix is workflow, not settings: agree who edits what, or take turns. See also the per-tool guides, for example editors and video and audio projects.
What is still open
- There is no file locking between peers, and none is planned at the filesystem level. Databases and other always-open files follow the hand-off pattern.
- An end-of-transfer checksum verification pass is a planned addition.
- These guarantees are stated for two peers. More than two is a later release and a different algorithm.