How it works

Every device runs the same daemon and holds a local copy of the same KDBX vault. There is no canonical server. Peers exchange signed revisions and converge.

Direct connections are preferred. The optional services carry encrypted opaque data and hold no vault keys.

1. Register the vault locally

The CLI opens a supported KDBX4.1 vault and records its canonical path, key-file reference, and KeePass database UUID. Lattice validates supported features before it stores anything. If the vault uses a feature it cannot round-trip, initialization stops.

2. Establish membership

The first device initializes itself as the vault admin. Adding a device runs an invite and join exchange. The online flow uses the pairing rendezvous, a terminal QR code or exact manual code, and a separate out-of-band confirmation. The signed-file flow works when no rendezvous is reachable. Either way, membership is a signed document, not a shared password.

3. Exchange and merge revisions

Each edit becomes a signed revision that binds the vault, membership document, epoch, author device, sequence, causal parents, and changed records. Peers validate causal origins before version ordering, reject overlap equivocation and sequence-floor regression, and bound DAG and resource work before materializing a new KDBX.

Remote writes use an encrypted materialization journal. If the process stops mid-write, the next start completes or discards the write based on the recorded preimage and postimage. A source that matches neither generation leaves the vault degraded for manual recovery rather than writing a mix.

4. Connect however the network allows

Direct TCP and QUIC are tried first.
Local peers are found with mDNS. Known-good addresses are cached after a successful authorized sync.
Across networks, optional rendezvous servers introduce peers using epoch-scoped opaque namespaces.
AutoNAT confirms reachability, Circuit Relay v2 is the fallback, and DCUtR attempts a direct upgrade.

5. Catch up when devices are not online together

An optional mailbox service carries short-lived encrypted head hints. When mailbox and object storage are both configured, the daemon uploads encrypted revision bundles and supports all-devices-offline catch-up while a valid capability and retained bundle remain available. Mailbox-only notification still requires a reachable member to fetch vault data.

6. Fail closed and stay recoverable

Unsupported features, stale epochs, replays, tampering, and failed key confirmation stop the affected operation. Recovery uses admin-signed, target-encrypted packages, an offline admin identity backup, or a previously enrolled secondary recovery authority.