The Sovereign Client: Why Our Browser Does the Heavy Lifting

The Sovereign Client: Why Our Browser Does the Heavy Lifting

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

For most, the "cloud" is a engine. For us, the cloud is a blind vault. This isn't a constraint of working with 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 React's concurrent rendering to ensure that 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.
• Backend: Lovable Cloud (Postgres + Edge Functions).

By using Lovable Cloud, we treat the backend as a high-performance routing layer. It manages Postgres for structured, encrypted metadata and Edge Functions for global low-latency delivery. However, 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 RAM.

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 or a counter overflows, 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 the encryption is happening across thousands of different user browsers simultaneously.

3. Cross-Browser Determinism

Native browser implementations can occasionally vary in subtle ways 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 a user's life's work 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 Postgres instance on Lovable Cloud, 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 we believe all sensitive SaaS should be built in 2026: The server stores the lock, but only the user ever holds the key.