Engineering Client-Side Sovereignty: Inside Awesome Crate's Zero-Upload Browser Architecture
How Awesome Crate runs PDF editing, encrypted journaling, and 3D focus sessions entirely in your browser - no uploads, no accounts, no telemetry.
Most “free” web tools share a quiet price: your file takes a trip. You pick a PDF, an upload bar fills, and somewhere in a data center a queue of anonymous documents now includes yours - alongside passports, contracts, medical letters, and lecture slides people never meant to share with a third party. Even when the service is honest, you have accepted a new set of risks: retention policies you cannot inspect, logs you cannot delete, and breach surface you cannot see.
Awesome Crate (crate.anirone.com) started from a refusal of that trade. It is a suite of browser tools - a PDF workspace called PDF Stage, a focus timer called Timelapse, and an encrypted notebook called Secret Vault - built on one architectural commitment we call client-side sovereignty: when you use these tools, computation happens on your device, in your browser’s memory, and nothing about your documents or your keys travels to us. There are no uploads because there is no receiving end.
This article explains what that actually means in engineering terms: which browser primitives make it possible, where the performance comes from, and - just as importantly - where the honest limits of a local-first design sit.
What ships in the crate
Awesome Crate currently carries three independent applications, each usable without an account:
| Application | What it does | Core browser technology |
|---|---|---|
| PDF Stage | Invert dark slides for printing, create PDFs, add pages, text, and images, reorder, rotate, crop, apply grid and ruled page themes | WebAssembly, pdf-lib/pdf.js, Web Workers, IndexedDB |
| Timelapse | No-pause focus sessions with Pomodoro rounds or one unbroken block, streak tracking, shareable streak cards | WebGL 2.0 shaders, requestAnimationFrame timing |
| Secret Vault | Passphrase-encrypted diary and notes, portable .vault exports, image and voice-note attachments, optional self-destruct timers | Web Crypto (AES-GCM, PBKDF2), IndexedDB |
Alongside the full PDF Stage workspace there are eight single-purpose tools - invert color, create PDF, add pages, add text, page themes, add image, reorder pages, crop - for people who need exactly one operation done well rather than a full editor session.
None of these ask for your email. There is no sign-up wall, no watermark on output, no file-size paywall tied to a subscription tier. Your ceiling is your device’s memory, not our infrastructure budget - because there is no infrastructure doing the work.
The core architecture: zero-upload sandboxing
The conventional pipeline looks like this: your file is serialized over HTTPS, written to temporary storage on a server, processed by server-side binaries, and returned. Each hop adds latency, and each hop creates a copy of data you were told would be “processed and deleted.”
The local-first pipeline collapses all of that into one machine:
In the Awesome Crate model, the file you open is read directly into your browser’s memory using the File API. Parsing, transformation, rendering, and encryption all execute inside the browser sandbox - the same security boundary that already runs every web page you visit. When you export, bytes are handed back to you as a download from memory. The network is never involved in the document path.
Two properties fall out of this design almost for free:
- Absolute privacy by construction. We cannot leak, log, sell, or lose your documents in a breach, because they never exist anywhere except your device. This is a stronger guarantee than any privacy policy can offer - it is enforced by physics, not promises.
- Deterministic speed. Once loaded, operations run at the speed of your CPU and memory bus. There is no round-trip tax, no queue position, no throttling during peak hours.
There is also a practical consequence people notice quickly: once the application has loaded, it works offline. Airplane mode does not break a tool that never needed the network in the first place.
PDF Stage: heavy documents, quiet threads
PDF files are deceptively demanding. Behind a calm page of text sits a tree of objects, embedded fonts, color spaces, and compressed content streams. Deserializing a large document, rewriting its object graph after an edit, and serializing the result can occupy hundreds of milliseconds of pure CPU - enough to visibly stutter a user interface if it happens on the wrong thread.
The standard browser remedy is a Web Worker: a background thread with no access to the DOM, perfect for raw computation. The subtlety is moving multi-megabyte document buffers between threads efficiently. Copying them through postMessage(data) doubles memory pressure and triggers structured-clone serialization. Passing the buffer as a transferable object instead -
// Educational sketch: handing a document buffer to a worker thread.
const worker = new Worker(new URL('./pdf-worker.js', import.meta.url));
worker.addEventListener('message', ({ data }) => {
// data.output is a fresh Uint8Array ready for download
saveFile(data.output);
});
// The second argument transfers ownership of the buffer.
// Nothing is copied: the main thread simply lets go of it.
worker.postMessage({ buffer: fileBuffer }, [fileBuffer]);
- hands over ownership of the same bytes in constant time. The main thread stays free to render at full frame rate while the worker grinds through the object graph.
For the document engine itself we build on proven open-source foundations (pdf-lib for writing and structural edits, Mozilla’s pdf.js for parsing and rendering), compiled to WebAssembly where hot paths benefit from it. These are public, auditable libraries - the same primitives available to any developer. What Awesome Crate adds is the surrounding discipline: worker isolation, autosave to local storage so a refresh does not destroy your session, and interface decisions that keep the workflow honest - make a copy, inspect it, export when satisfied.
Where the speed actually comes from
It is tempting to print a benchmark table with dramatic multiples, but honest engineering starts with where the time goes. For any cloud tool, the total experience decomposes roughly like this:
| Phase | Cloud pipeline | Local pipeline |
|---|---|---|
| Hand-off | Upload entire file (seconds to minutes depending on connection and size) | Read from disk into memory (near-instant) |
| Queueing | Server-side job queues under load | None - your CPU is the queue |
| Processing | Server compute, throttled per tier | Your device compute, unmetered |
| Return | Download result | Immediate download from memory |
The upload and download phases alone often dominate the perceived latency of small operations - rotating ten pages should take milliseconds, but a cloud tool spends most of its time shipping bytes. Local execution deletes those phases entirely. What remains is real compute, which modern hardware handles comfortably for everyday documents: inversion, reordering, cropping, and page insertion on a typical lecture deck complete in well under a second on ordinary laptops.
The honest caveat cuts the other way too: on a weak device, your CPU is the ceiling. A five-hundred-page scan-heavy PDF will strain a five-year-old phone whether or not a network is involved. Local-first moves both the speedup and the hardware responsibility onto the same side of the equation - yours.
Secret Vault: cryptography that never phones home
Secret Vault protects notes and diary entries with AES-GCM-256, authenticated encryption available natively in every modern browser through the Web Crypto API. The design follows the standard zero-knowledge pattern:
- Your passphrase is combined with a random salt and stretched through PBKDF2 (the published Awesome Crate specification derives keys with 100,000 iterations) entirely on your device, producing an AES key that exists only in memory.
- Every entry is sealed with a fresh random nonce, so identical text produces different ciphertext each time.
- GCM’s built-in authentication tag means any tampering with stored ciphertext causes decryption to fail loudly rather than return corrupted plaintext.
- Exports are portable
.vaultfiles - self-contained encrypted envelopes you can copy to a USB drive or cold storage, attachments included.
Because key derivation and decryption happen locally, there is no reset route. If the passphrase is gone, the content is gone - for everyone, including us. That is not a limitation we failed to solve; it is the definition of the guarantee. The practical advice we give every user: choose a passphrase you can actually remember or store safely, and test restoring from an exported .vault file before you trust your archive to it.
One more boundary worth stating plainly: browser storage holds your active workspace, but it is not a backup. Clearing site data wipes local drafts. Export anything important.
Timelapse: focus rendered in real time
The third application attacks a different problem - attention. Timelapse is a no-pause timer: when a session starts, a small low-poly planet begins turning through a full day-night cycle, and the only way to watch the sun set over glowing city lights is to stay in the session. Pausing is deliberately impossible; abandoning a block means losing it.
Under the hood this is a compact WebGL 2.0 scene - procedural terrain, a custom daylight shader driving the solar terminator, Blinn-Phong lighting - running at negligible cost next to whatever work you are actually doing. Completed sessions build a tamper-proof streak, and each session ends with a shareable streak card. The design goal was ambience rather than gamification pressure: a clock you can feel in your peripheral vision instead of a countdown shouting at you.
The honest limits
A local-first architecture buys privacy and speed with real constraints, and we would rather name them than bury them:
- Device-dependent performance. Heavy documents stress weak hardware. We optimize continuously, but physics applies.
- Browser storage is ephemeral by default. Local drafts survive refreshes, not deliberate data wipes or private-browsing windows. Export early, export often.
- No cross-device sync. Sync requires servers; servers require uploads. Portable
.vaultexports and downloaded PDFs are the transport mechanism instead. - No account recovery. In Secret Vault, a lost passphrase is final. That is the contract working as intended.
These are not edge cases we hope you ignore - they are the visible edges of the design decision itself.
What lies ahead
Awesome Crate is the first platform in Anirone’s ongoing exploration of client-side computing. As browsers ship WebGPU, WebAssembly Garbage Collection, richer Origin Private File System support, and broader shared-memory concurrency, the gap between “web page” and “application” keeps narrowing - and the case for keeping computation on the user’s side of the network gets stronger every year.
The tools are live at crate.anirone.com. Try the offline test yourself: load a PDF, turn off your connection, invert it. Then decide whether software that never asks for your files feels different.
(c) 2026 Anirone. Dispatches from the digital craft laboratory.
Share this article
Link, preview card, or your favorite app
Instagram has no web share link — save the card, copy the caption, post them together.