Fast & Reliable Conflict Resolution, Online or Off

Both full-state and delta-state are types of state-based CRDTs. The difference is in how much data actually gets replicated when a merge occurs. Full-state CRDTs must replicate the entire document every time any field changes, which wastes bandwidth when only one property updates frequently.

Delta-state CRDTs replicate only the differences (deltas) between states, dramatically reducing bandwidth. However, most delta-state implementations require buffering deltas per peer until delivery is confirmed, which doesn't work in ad-hoc meshes (like Ditto's implementation) where devices join and leave unpredictably.

Ditto developed a unique approach using version vectors and "diffs." When devices sync, they exchange version vectors, summaries of what changes each device has seen. By comparing version vectors, Ditto calculates on-demand the minimal state (the diff) needed to bring each peer up-to-date, without requiring per-peer buffers. This combines the bandwidth efficiency of delta-state with the flexibility of full-state CRDTs, making sync efficient even over Bluetooth LE and peer-to-peer WiFi.

To learn more, read this blog from our software engineer behind the implementation.

Both deltas and diffs represent changes in state, but they differ in how they're managed. Traditional delta-state CRDTs buffer deltas (the changes since the last sync) for each peer until delivery is confirmed. This requires tracking which peers have received which deltas—impractical when devices constantly join, leave, and reconnect.

Ditto's diffs are calculated on-demand by comparing version vectors between peers. Instead of maintaining buffers, Ditto determines exactly what data each peer needs at the moment of sync by checking what changes they haven't seen yet. This approach combines the bandwidth efficiency of deltas with the robustness of full-state CRDTs, without requiring memory overhead or known peer sets.

‍

CRDTs resolve conflicts at the data structure level with clear semantics that preserve user intent. Version vectors detect whether changes happened sequentially (one after another) or concurrently (at the same time).

For concurrent edits, different CRDT types use different resolution strategies: Registers use last-write-wins (the edit with the latest timestamp wins), Maps use add-wins (all concurrent changes to different fields are preserved), and Counters merge additively (both increments are kept). Unlike traditional "last write wins" which discards one user's work arbitrarily, CRDTs ensure predictable, meaningful outcomes that represent the original intent.

Learn more in the docs.

Operation-based CRDTs require exactly-once or causal delivery to every peer, meaning operations must be delivered in the exact order they occurred, without loss. This requires tracking which peers have received which operations and buffering them until confirmed. This is impractical in ad-hoc meshes where devices disconnect for arbitrary periods and the set of "all peers" constantly changes.

State-based CRDTs place minimal constraints on the network. They handle reordered messages, duplicate deliveries, and dropped packets gracefully. Devices can sync with any peer at any time, and changes propagate through the mesh even when devices never communicate directly. This makes them ideal for mobile environments with unreliable connectivity, frequent offline operation, and unpredictable peer membership.

‍

Causal consistency ensures that if one change depends on or happens after another change, those changes are always observed in the correct order—but concurrent changes (happening independently) can be seen in any order.

This prevents confusing scenarios where effects appear before their causes, while still allowing maximum flexibility for concurrent operations.

Learn more in the docs.

Strong consistency requires all devices to agree in real-time which is impossible when offline. Eventual consistency allows devices to converge over time but changes can appear in any order. Causal consistency ensures cause-and-effect relationships are preserved without requiring coordination. Ditto chose causal consistency because it provides logical ordering guarantees while working offline and in mesh networks.

‍

CRDTs use version vectors, intelligent timestamps that track every change on every device. When devices sync, they compare version vectors to determine what data each peer has already seen versus what's new.

The merge operations are mathematically proven to be idempotent (applying the same change multiple times has the same effect as once), commutative (changes can be applied in any order), and associative (grouping changes differently produces the same result). This means messages can arrive out of order, get duplicated, or be dropped and devices will still be able to converge to identical states without requiring coordination between peers.

‍

Each device maintains its own metadata database, a lightweight storage layer containing version vectors, sync state, and update history. When devices connect, they compare metadata to instantly determine what's new and calculate the minimal diff needed. This enables efficient sync without requiring per-peer buffers or centralized coordination.

Learn more in the docs.

Many CRDT systems maintain separate buffers for each peer, storing changes until they confirm receipt. This works for systems with known, stable peer sets, but breaks down in ad-hoc meshes where devices constantly join, leave, and reconnect. You'd need unlimited buffers for peers that might never return.

Ditto avoids this by calculating diffs on-demand from version vectors. Instead of remembering "what we sent to peer X," devices simply compare version vectors when they connect to determine what data each peer needs right now.

‍

Devices don’t wait for connection to WiFi, servers, or the cloud. They create a localized mesh network and sync directly with each other over Peer-to-Peer Wi-Fi (think Airdrop), Bluetooth Low Energy, or Local Area Network. If one connection drops, Ditto automatically reroutes through another channel or device within the network.

Encrypted at the transport layer using version 1.3 of the Transport Layer Protocol (TLS), clients and servers are mutually authenticated prior to transmission of API and peer-to-peer access credentials. The use of mutually authenticated TLS (mTLS) mitigates potential risks posed by outside attackers attempting to masquerade as a valid API endpoint or peer in the mesh network to steal information.

Additionally, Ditto workloads and services are tightly controlled in a containerized Kubernetes environment.

Ditto's Multiplexing technology seamlessly switches between active transports such as WiFi, Bluetooth LE, peer-to-peer WiFi connections, and cellular networks in real-time. Instead of hoping one network stays reliable, Ditto maintains multiple simultaneous connections and automatically selects the optimal path for every data transfer.

Learn more on the peer-to-peer mesh networking page.

‍