No Account. No Server. Your Documents.
A document vault should have a simple answer to a simple question: who can read the documents? In Varsha, the answer starts with the architecture. The vault lives on the device. There is no account to create and no document server to trust. That choice removes an entire class of dependency, but it also removes the comforting fiction that somebody else will recover everything for you.
Encryption is a boundary, not a slogan
The public Varsha engine uses WebCrypto. It derives an AES-256-GCM key from the passphrase using PBKDF2 with SHA-256 and 310,000 iterations. The key is non-extractable in the WebCrypto API. Each sealed value gets a fresh 12-byte random initialization vector. The stored representation contains the vector and ciphertext, not a plaintext copy of the document record.
Those details matter more than a lock illustration. They identify where the protection actually happens. They also identify its limit: encrypted storage does not make an unlocked device, a compromised browser environment, or a weak passphrase safe. I would rather describe that boundary precisely than imply that a cipher name solves every threat.
No reset is part of the product
The README states the trade-off plainly: no account, no reset. If the key comes from the passphrase and there is no server holding a recovery path, forgetting the passphrase is not a support ticket somebody can quietly fix. A local-first product has to make that consequence understandable before a person trusts it with important papers.
That is why backup belongs beside encryption in the design, not in a settings corner somebody discovers after losing a device. Varsha exports an encrypted bundle that can move to another device. The documented merge rule is newest wins. Portability is useful, but it is still the owner who has to keep the bundle and the passphrase.
Separate the engine from the drawer
The vault engine is plain TypeScript with a storage adapter. The browser uses IndexedDB; tests can use an in-memory adapter. The React interface is a client of that engine, not the place where the storage contract is invented. That separation makes it possible to test the document behavior without needing the whole interface to be running.
Search, expiry reminders, attachments, and export are the practical side of the same decision. A private archive that cannot find a certificate when it is needed is still a bad archive. Varsha searches titles, numbers, and notes, and highlights documents expiring in the next 30 days. Privacy and usefulness have to survive in the same product.
The quiet benefit of static files
The web app can be deployed as static files. Compute and storage stay on the device, and the offline app shell is part of the public repository. The hosting layer serves the application rather than becoming a permanent dependency for opening the vault. The result is less infrastructure to operate, but more responsibility to communicate the limits honestly.
Local-first is a transfer of ownership. Done badly, it transfers the risk without explaining it. Done properly, it gives the person a usable vault, a portable encrypted backup, and a clear understanding of what nobody else can recover. That is the standard worth building toward.
Public source
Project and architecture: https://github.com/yethikrishna/varsha_v1 . Implementation details above come from app/src/engine/vault.ts in that public repository. This is an architecture note, not a claim of an independent security audit.