Picture three situations that all look, from a distance, like the same problem.

The first: you write a note on your laptop, and you want it on your phone before you leave the house. Two devices, one person, the same self on both.

The second: you and a friend each keep your own private memory, and you have agreed to share a slice of it — a contact card, a shared space, the running thread of your relationship. Two different people, each sovereign, meeting at a negotiated edge.

The third: a group you belong to has a shared history — its membership, its content, its decisions — and every member needs to converge on the same picture, even though no one is in charge of holding the master copy.

From far away these all read as "keep two places in agreement." Up close they are three different trust relationships, and getting them confused is exactly how systems leak. The whole design of how we move data between machines rests on keeping them distinct while running them on one reconciliation engine underneath. We call the three faces device sync, peer sync, and group sync, and the rule we hold to is blunt: never conflate them. Different keys, different addressing, different authorization. Let us walk through each, then the engine they share.

The shape underneath: anti-entropy, not broadcast

Start with what every machine in this system is and is not.

Every app you use talks only to its own local daemon — a small program running on your own device — over a local connection. No app ever opens a socket to a remote machine. When two of these daemons need to agree, they talk to each other directly, peer to peer, over an encrypted transport with relays only to punch through firewalls.

And the engine they run is not a broadcast pipe. It is anti-entropy: a background process whose job is to notice that two sides have diverged and to reconcile them. Divergence is the normal, expected state. Two machines are almost never identical at any given instant, and that is fine. Convergence is an always-running reconciliation, not a guarantee that holds at every moment. This is the deepest design choice in the whole layer: the system is built to work on a local network with no internet, to keep going when every peer is unreachable, and to catch up whenever a peer reappears. Your records stay appendable and queryable even when you are completely alone. Replication is a property the system eventually gives you, never a thing you have to wait for to act.

That single engine — notice divergence, reconcile it — is what all three faces share. What changes between them is who is allowed to send you what, and how they prove it.

flowchart TD
  E["Anti-entropy engine
notice divergence → reconcile → converge"]
  E --> D["Device sync
lock: shared root seed,
per-device child keys"]
  E --> P["Peer sync
lock: signed bilateral
sharing agreement"]
  E --> G["Group sync
lock: verified per-message
membership"]

Face one: your own devices

The first face is the easiest to trust and the trickiest to get right.

Your devices are all you. They descend from the same root — a recovery phrase you and only you hold — but here is the part people expect to be wrong and isn't: they do not all hold the same key. Each device derives its own child key from that shared root. Same family, different members. A laptop and a phone are siblings, not clones.

So how do they recognize each other? When you add a device, the two prove they share the same root without ever transmitting it: each independently derives a sync key from the same place in the key hierarchy, and they confirm the match through a challenge-and-response plus a short numeric code you read across. Once that handshake passes, the engine runs per-device sync state between them, exchanging encrypted updates. The point of the child-key design is that no single device holds the keys to the whole kingdom, and adding a device never means copying the master secret onto a second machine.

Face two: two different beings

The second face is where two different people meet — and here the engine cannot assume a shared root, because there isn't one.

Peer sync begins with a deliberate ceremony, not an ambient discovery. There is no "see who else is on the network" broadcast; that was removed on purpose, because ambient discovery is noise and attack surface. Instead, one side generates an invitation, the other initiates, the first responds — a three-step handshake. When it completes, the two beings exchange their relationship cards and open sharing domains: scoped agreements about what data is allowed to flow. After that, the engine bilaterally exchanges chain heads and deltas between exactly those two — and only the data the domains permit.

The contrast with device sync is the whole point. Devices share a seed and trust each other wholly. Peers share nothing by default and trust each other exactly as much as a signed agreement says, no more.

Face three: a group

The third face is the many-to-many one, and it cannot work like the other two.

A group's shared history is broadcast through gossip — an epidemic protocol where each member relays to others, so a message fans out across the group without any central server holding the master copy. Gossip is efficient and serverless, which is exactly why it is dangerous: an open relay network will happily carry a forged or unauthorized message right alongside a real one. So group sync layers per-group membership authorization on top of the gossip. A message about the group is only accepted from a current, authorized member — verified per message, not merely "is this someone I have heard of." And the outbound side fails safe: if the system cannot confirm who is authorized to receive a broadcast — say a transient lookup error — it sends to zero peers, never to all of them.

Why one engine, and why the walls between them

It would have been reasonable to build three separate systems. We built one, because the reconciliation problem really is shared: notice divergence, order concurrent writes deterministically, apply both sides, converge. When two members write to the same shared history at the same moment, a single merge reconciler orders and applies both — the same machinery whether the two writers are your own two devices or two members of a group.

What is not shared is authorization, and that is where the walls go up. Device sync trusts a shared seed. Peer sync trusts a signed bilateral agreement. Group sync trusts verified membership. Same engine, three doors, each with its own lock. Confuse the doors and you have built a leak: a group key where a device key belongs, a peer's broadcast accepted as a group's. So the discipline is to keep the three faces architecturally separate even though one heart beats underneath all of them.

We will be honest about an edge that is not finished: the signed-checkpoint machinery that would let a peer snapshot an entire group history at a verifiable root, and detect tampering in one comparison, is designed but some of its helper pieces are not present in the running code yet. The everyday sync — the noticing and reconciling — works; the bulk-checkpoint accelerator is still ahead of us. We would rather you know that than imply it is all done.

The thing worth taking away is the shape, not the parts. Three relationships that look the same from far away are three different trust problems up close — and the way you keep them honest is to run them on one reconciliation engine while never, ever letting their locks be the same key.

Written by AI agents from real project logs; owned and edited by Mujo.