Local-first only means ownership if you can leave with an encrypted snapshot the cloud never had to hold. .nt2backup is that snapshot: portable vault profile sections and sealed payloads in a file you control.
Unlock, list, search, and settings should not fork into three products. NT² Vault keeps one vault UI and lets each shell own only what the platform must own: how durable files live on that device.
Salt, Key DID public material, sync cursors, and onboarding prefs are not one fat SQL row. They live as named vault profile sections—so backup, sync, and unlock can each touch only what they need.
A local vault is a real SQLite database on your device. When the product ships schema v60, launch-era vaults must upgrade in place—not force a wipe because the CREATE statement changed in the source tree.
Unlock is not a best-effort decrypt of everything you own. NT² checks a small local verifier first. Wrong password fails closed: the vault stays locked, and the UI stays honest.
A credential is a map of fields while you edit it. The moment those fields must survive a lock, a restart, or a replica, they need a portable ciphertext shape—not a JSON dump waiting for the next reader.
Encryption at rest is incomplete if the decrypted key handle outlives the unlocked session. NT² treats auto-lock as memory hygiene: non-extractable CryptoKeys, in-memory only, cleared on idle, refresh, and tab close.
A local-first vault needs a real relational engine on device. Putting that engine on the UI thread makes every page query compete with paint and input. NT² Vault runs SQLite in a Web Worker, behind typed messages and a single lock chain, so the list can stay responsive while the database stays honest.
A cloud can help deliver sealed packages without becoming the place where pending shares live as readable mail. Relay indexes ciphertext. Inbox stays on the device.
Opening the same vault in two browser tabs is normal. Letting both tabs write the same on-device SQLite file is not. NT² Vault elects one Writer and keeps every other unlocked tab as a follower.
A vault needs to know which files belong to which items, how large they are, and how to unwrap their keys. It does not need those encrypted bytes sitting inside the relational database that answers those questions.
Local search is not one query shape. Free-text wants a full-text index on titles and search text. Category, trash, archive, and similar filters want ordinary table predicates. The product switches strategy so the UI never has to ship the whole vault into memory to feel searchable.
A local vault can hold thousands of structured items without becoming a giant in-memory array. The durable store stays in SQLite. The UI holds only a paged window of lightweight list rows, rendered through a virtual list.
“Contact support to reset your password” sounds reassuring. For an encrypted vault, it also reveals who ultimately controls access. NT² chooses a harder promise: recovery material stays with you, not our help desk.
Sync does not have to turn a local vault into a cloud database. The edge can identify an account, store opaque replica frames, and deliver updates without learning what those updates contain.
SQLite wants a file. A privacy vault wants durable relational storage that stays fast as its item count, indexes, and encrypted attachments grow. Putting a SQLite virtual file system on IndexedDB can bridge those worlds, but it makes the bridge part of every database operation. For NT² Vault, the browser vault file belongs in the Origin Private File System.
One screen can make two security events look like a single login. We keep them separate because opening encrypted data and proving an identity to a server are different jobs with different risks.
A vault can encrypt everything with one key and still claim that its data is encrypted. We wanted a more useful boundary: each item and attachment gets its own content encryption key, while the vault key protects those keys.
A salt is not a secret. Still, where it lives changes who can assemble a password-guessing system. NT² keeps the KDF salt and password verifier with the local vault, so unlocking begins and ends on the device.
In the era of massive cloud-first applications, we often overlook a powerful alternative: the Progressive Web App (PWA). Why maintain a heavy, expensive, and potentially vulnerable server infrastructure when the modern browser is capable of running a full-featured, secure, and high-performance application entirely on the user's device?