What is a CRDT?

Device A                    Device B
   |                           |
   |  Edit: add "milk"         |
   |                           |  Edit: add "eggs"
   |                           |
   |  ---- sync ---->          |
   |  <---- sync ----          |
   |                           |
   |  Result: ["milk", "eggs"] |  Result: ["milk", "eggs"]

Each edit is recorded as an operation (not a snapshot). Operations include metadata like timestamps and device IDs. When devices sync, they exchange operations and replay them in a deterministic order. The math guarantees that no matter what order operations arrive, every device ends up with the same result.

Thumper-Run uses the Loro CRDT library — a high-performance Rust implementation that supports rich data types (maps, lists, text, trees).

• Works Offline — Changes queue locally. When you reconnect, everything syncs automatically.
• No Conflict Dialogs — Multiple devices can edit simultaneously. No "file is locked" or "choose which version to keep".
• No Central Server Required — Devices can sync directly (peer-to-peer) or through a relay. The server is just a mailbox — it doesn’t understand your data.
• Your Data Stays Yours — Private E2EE for CRDT data is a planned design. Current relay-assisted sync is server-assisted and does not guarantee that the relay only handles opaque ciphertext.

Here is a concrete example showing how CRDTs resolve simultaneous edits without conflicts.

Scenario: Shared Shopping List

Device A adds "milk" while Device B adds "eggs" at the same time, both offline:

Device A (offline)          Device B (offline)
   list: ["bread"]            list: ["bread"]
   |                           |
   | insert("milk", pos=1)     | insert("eggs", pos=1)
   |                           |
   list: ["bread", "milk"]     list: ["bread", "eggs"]
   |                           |
   |  ---- reconnect ---->     |
   |  <---- reconnect ----     |
   |                           |
   Both:  ["bread", "eggs", "milk"]    (sorted by device ID)

The CRDT assigns each operation a unique ID based on the device and a logical clock. When operations conflict (both insert at position 1), the CRDT uses a deterministic rule — in this case, sorting by device ID — to produce the same order on every device. No data is lost; both items appear in the list.

What About Real Conflicts?

True conflicts (Device A sets color to "red", Device B sets it to "blue") are resolved by last-writer-wins using the logical timestamp. The later write wins, but the earlier write is preserved in the operation history and can be inspected via the timeline view.

Document Sizes

Sync Performance

• Initial sync of a new device: typically < 1 second for settings and preferences
• Incremental sync (after edit): < 100 ms over WebSocket
• Offline queue: operations are batched and sent in a single message on reconnect
• Storage overhead: CRDT metadata adds ~20–30% on top of raw data size

For protocol details including the 5 sync modes (local, catalog, triple CRDT, temporal auth, encrypted), see the Platform Architecture → CRDT Sync Protocol section.