Protocol / Identity
A locator, not a profile.
Your Vault ID exists to find encrypted state. It is deliberately not an account record, recovery address, or identity layer.
Account email
None
No inbox becomes a recovery path
Required PII
0 fields
No phone, name, or profile
Recovery model
User-held
Your passphrase is the boundary
01Choose Vault ID
02Create passphrase
03Derive local key
04Locate encrypted state
Design ruleMinimize what infrastructure can know. Make the unavoidable trade-offs visible.
01 / PURPOSE
The ID points to a vault without describing the person behind it.
A Vault ID is closer to a storage locator than a username. It lets the app find the encrypted material associated with a vault, while avoiding the usual account fields that turn into a profile over time.
No email loginNo account profileNo recovery address
02 / BOUNDARY
Possession of the ID alone does not unlock anything.
The Vault ID is not secret enough to treat as a password. Unlocking still requires the passphrase, which is stretched inside the browser before any vault material can be decrypted.
ID is not a keyPassphrase requiredBrowser-side unlock
03 / FAILURE MODE
No account also means no reset button.
SEES cannot verify an identity it never collected. That is intentional: account recovery would create a privileged path around encryption, so the product makes the trade-off explicit.
No reset emailNo support overrideNo escrow key
Continue the protocolSeal
Need the complete threat model?Read security