NAOMS · building block
Vault
A separate encrypted store for secrets such as keys and passwords.
The vault is an on-device encrypted store, separate from a person’s other data, holding secrets such as passwords and API keys, relationship cards with their attached verifiable credentials, and contribution tokens. It stays locked until the person unlocks it, and a newly paired device gets the vault’s encryption key during pairing rather than a password typed in blind.
What a person notices
- Passwords, API keys and other secrets stay in one place on their own device, separate from everything else.
- Unlocking the vault is its own step, distinct from unlocking the rest of the app.
- Adding a new phone or laptop hands the vault its key during device pairing, instead of typing a master password into a new device blind.
What you get as a developer
The vault is a separate, on-device encrypted store. Being separate from the rest of the app’s data is deliberate: it does not sync the same way, and it stays locked until the person unlocks it.
- 27 recognized secret types are supported out of the box: the common consumer categories (logins, API keys, payment cards, secure notes) plus a few vault-specific ones for MFA recovery codes and Android release-signing keys.
- A secret’s value is sealed before the write is even committed to the chain. Listing secrets returns metadata only (type, label, timestamps); reading the actual value requires the vault to be unlocked.
- The vault also holds relationship cards, the verifiable credentials attached to them, and personal tokens, all behind the same unlock, so a package doesn’t need four different secret stores.
- A newly paired device receives the vault’s encryption key directly during pairing (or through an explicit access grant), then sets its own local unlock password on first use, rather than the key ever being typed in and exposed.