The Sovereign Client: Why Our Browser Does the Heavy Lifting

The Sovereign Client: Why the Browser Does the Heavy Lifting

In a world where SaaS usually implies "we process your data on our servers," we’ve made a distinct architectural choice: the most critical code in our stack runs in your browser, not on our infrastructure.

For most, the "cloud" is an engine. For us, the cloud is a blind vault. This isn’t a constraint of modern web tools; it’s a deliberate security feature designed by engineers who have spent two decades watching "secure" perimeters crumble.

The Stack: Built for Zero-Trust

Our architecture leverages a refined, hardened stack designed for the 2026 threat landscape:

• Frontend: React 18 + Vite. We utilize concurrent rendering to ensure heavy cryptographic operations don't freeze the UI.
• Styling: Tailwind CSS, keeping the footprint light and the UI predictable.
• Cryptography: libsodium-wrappers (WebAssembly). This is our core engine.
• Infrastructure: Distributed Edge Functions + Managed Database.

By treating the backend as a high-performance routing layer, the server's job is strictly restricted: it stores opaque blobs and routes them to authorized users. It has no "eyes." It cannot peek at the contents because it lacks the keys, which never leave your local environment.

Why We Reject the Native Web Crypto API

A common question from other engineers is: "Why bundle a WASM library like Libsodium when the browser has a native Web Crypto API?"

The answer lies in Cryptographic Rigidity. The native Web Crypto API is a "greatest hits" of legacy and standard algorithms (AES-GCM, SHA-256), but it lacks the primitives required for a truly modern, resilient vault:

1. Argon2id: The GPU Killer

Web Crypto primarily offers PBKDF2 for key derivation. In 2026, PBKDF2 is a liability; it is computationally "cheap" for attackers to parallelize on modern GPU clusters. We use Argon2id via Libsodium because it is memory-hard. It forces an attacker's hardware to dedicate significant physical RAM to every single guess, making brute-force attacks mathematically and financially infeasible.

2. XChaCha20-Poly1305: Implementation Safety

While AES-GCM is the standard, it is notoriously "brittle." If a nonce is ever reused, the security of the entire stream can collapse. We opted for XChaCha20-Poly1305 because it features a 192-bit nonce. This makes nonce-collision practically impossible even when generating them randomly—a critical safety net when encryption happens across thousands of different user browsers simultaneously.

3. Cross-Platform Determinism

Native browser implementations can occasionally vary or lack support for specific curves. By shipping libsodium-wrappers as a WASM binary, we ensure that the exact same audited, constant-time code runs on Chrome, Safari, Firefox, and mobile engines. Bit-for-bit consistency is non-negotiable when sensitive data is locked behind those bits.

The Result: Privacy by Mathematical Necessity

By moving the "Intelligence" of the app to the client, we’ve removed ourselves as a target. If an attacker breaches our database, they don't find a treasure trove of credentials. They find a desert of high-entropy noise.

We’ve built a system where we don't have to ask for your trust, because we’ve made it physically impossible to betray it. This is how sensitive SaaS should be built in 2026: The server stores the lock, but only the user ever holds the key.