How it works

A vault with nowhere else to be.

Your devices carry a change to each other, and that is the whole of the journey. These are the five mechanisms that make that work, in the order a password meets them.

Sealed before anything carries it

Each login, its title included, is sealed with XChaCha20-Poly1305 under a vault key of its own. Your master password opens that key through Argon2id at 64 MiB and three passes, and every ciphertext is bound to its own file name, so only an intact blob in its right place opens.

Devices talk only to each other

The safe reaches your other devices at the addresses a pairing gave it. Discovery of every kind is switched off and it serves no API, so a stranger has nothing to ask.

The vault name is the membership secret

A safe is named by 128 random bits, and a peer is admitted by a hash of that name. The name travels only inside a pairing code, so your safe is reachable by the devices you added and invisible to everything else.

Step by step

From a typed password to a second device holding it.

Sealing

A login is sealed before the engine sees it

The master password opens a vault key through Argon2id at 64 MiB and three passes. Each entry, its title included, is sealed under that key with XChaCha20-Poly1305 and bound to its own file name. What the engine then carries is a named blob it cannot read, and what a stranger would find on the disk is the same.

Pairing

A device joins because you carried a link to it

Adding a device shows a QR code and a pairing link holding the library name — 128 random bits — and the vault key. A phone scans it. A computer that cannot scan shows a code of its own instead, and the phone sends the link back sealed with a one-time key taken from that code, which the computer is waiting for on its own port.

Finding

Nothing asks a directory where you are

The node knows the addresses the pairing link gave it, and talks to those. Discovery of every kind is switched off, and it serves no HTTP API. Wi-Fi, Ethernet or a Tailscale address — the pairing screen switches between them so you can pick the one that reaches.

Syncing

A sync is a catalogue, then the bytes you lack

Devices exchange hashes, and each then pulls the members it is missing from the devices it is paired with. That runs every five seconds while the app is open, and immediately after a save.

Removing

A device is removed once, anywhere

Removal is written into the vault, sealed with the vault key, so only a device that can open the vault can remove one — and it syncs like any other entry. Each remaining device honours it at its next unlocked sync, and the node keeps its own copy beside the library so a removed device stays refused while the vault is locked and across a restart.

When two devices disagree

The rule lives in the data.

One entry, one file: An entry is a single file and an edit is a new version of it, so a change rewrites one thing rather than the whole safe.
Two devices, one answer: Edit the same entry on two devices while they are apart and each keeps a version. The later change wins, and the next save on either device settles both into one.
Deletes travel like edits: A delete is a new version marked as such, so it travels and settles by the same rule.
Hashes first, then what you lack: Devices compare lists and each pulls only what it is missing. That runs every five seconds while the app is open, and at once after a save.
Change the password anywhere: The vault key stays as it is, so your other devices keep reading their entries and take the new password the next time they catch up.

Underneath

The engine runs inside the app.

The same Unidatum engine that runs clusters is linked into this app and started in its own process. A vault is a library of files in its catalogue, which is SQLite; documents and SQL would need DuckDB, and a password safe needs neither.

On Android the library sits in the app's no_backup directory, which Auto Backup always skips, so the vault stays out of Google's copy of the phone.