The promise
Driftless never silently throws away your edits. When two devices change the same file at the same time, both versions are kept — you decide afterwards which to keep, with nothing lost in the meantime.
Concurrent edits keep both copies
Suppose two devices both start from the same version of a file and each makes a different change. Whichever reaches the server first keeps the original filename. When the second device tries to save, the server sees the file has already moved ahead of the version that device started from and refuses the out-of-date write. The second device then preserves its own edit under a conflict name:
report.sync-conflict-20260624-143022-laptop.txtThe conflict copy is then synced like any other file, so it appears on your other devices too. You end up with both versions side by side and can merge or delete at your leisure. Because the server is the single arbiter, this holds even when both devices save at almost the same instant — there is no race window in which one edit could quietly overwrite the other.
An edit always beats a delete
If one device deletes a file while another edits it, the edit wins: the file is restored from the edited version rather than disappearing. Removing a file should never override someone's active work.
Renames travel as moves
When a file is renamed or moved on the server — for example by a future on-demand client — other devices apply it as a local move: the file keeps its identity and history, and its content is not transferred again. The same keep-everything rules extend to renames: if a device was editing the file at its old name while it was renamed elsewhere, the renamed original appears under the new name and the local edit stays under the old one, so both survive as separate files. A rename also beats a delete, the same way an edit does.
Identical changes do not create clutter
If both sides happen to end up with byte-identical content, there is no real conflict, so no conflict copy is made — the matching version is simply adopted. The same applies the first time a device syncs a folder that already contains files identical to the server's, which makes it safe to pre-seed a new device from a backup.
Version retention and cleanup
Every save is recorded as a new version. The server keeps the most recent N versions of each file and prunes older ones as new saves arrive; N is configured in the admin (default 10). History stays bounded with no manual housekeeping.
A background garbage collector then reclaims storage: once a chunk of data is referenced by no remaining version, its bytes are removed from disk. Chunks uploaded within a recent grace window are left untouched, so a sync in progress is never disturbed.
Retained versions are not yet browsable or restorable from a client — that history view is still to come. For now the kept versions are the safety net behind the conflict rules above, and storage simply stays bounded in the meantime.