DEV Community

Cover image for Why We Built a Zero-Knowledge, Zero-Egress File Transfer Engine (And Killed the 3 GB Memory Crash)
Alex Vance
Alex Vance

Posted on

Why We Built a Zero-Knowledge, Zero-Egress File Transfer Engine (And Killed the 3 GB Memory Crash)

If you have ever tried to send a 2.5 GB video file, confidential legal brief, or raw asset archive over traditional transfer tools, you’ve hit the same wall:

  1. Browser tabs crashing with Out-Of-Memory errors because the app blindly buffers everything into RAM via FileReader.readAsArrayBuffer().
  2. Artificial download speed throttling down to 1 MB/s unless you hand over a credit card.
  3. The "Server-Side Encryption" lie: services claim your data is safe, but they hold the master keys. Their engineers, scrapers, and ad engines see every raw byte.
  4. Dropped Wi-Fi at 98%? Start all over again from 0%.

We got tired of this broken decade-old model. So we built LimeShare — an open, zero-knowledge, zero-throttle file transfer engine that runs entirely inside your browser.

Here is the engineering breakdown of how it works, how it achieves fixed $O(1)$ memory consumption, and why it changes file sharing for good.


The Architecture: Moving Cryptography to the Edge of the Browser

Traditional platforms take your unencrypted file, ingest it on their servers, inspect it, compress it, and stick it into legacy object stores.

LimeShare flips this model completely:
[ Sender Browser ]

├─► 1. WebCrypto AES-256-GCM (STREAM framing, 4MB chunks, O(1) RAM)
├─► 2. Master Key (K) placed EXCLUSIVELY in URL Hash (#)

├──────────► Edge Coordination Layer - Zero data inspection, tokens only

└──────────► Distributed Zero-Egress Storage - Encrypted payload chunks


Recipient ◄───────┴─ (Direct streaming decrypt in RAM → Zero disk temp files)

1. In-Browser STREAM AEAD Framing

Instead of reading multi-gigabyte blobs into memory, LimeShare implements a sequential chunking stream engine. Files are processed in strict 4 MB frames:

  • Each frame is authenticated and encrypted via client-side AES-256-GCM.
  • Frames use a deterministic 12-byte nonce construct: [7-byte random prefix] || [4-byte counter] || [1-byte finality flag].
  • A 32-byte authenticated container header locks the exact plaintext length. Truncation or segment-swapping attacks are cryptographically rejected before a single decrypted byte hits the user's filesystem.

Result: Transferring a 3 GB file consumes a flat <50 MB of working RAM, eliminating mobile Safari and Chromium tab crashes completely.

2. True Zero-Knowledge via RFC 3986 URL Hashes

The link structure looks like this:
https://limeshare.org/d/{transferId}#1.{MasterKey}.{Token}

Under RFC 3986, anything following the # (hash fragment) is never transmitted to the server. The encryption key is generated locally, lives strictly in client memory, and is parsed exclusively by the recipient's browser.

The coordination layer receives only an opaque cryptographic blob. If our servers were audited or seized, all that exists is unreadable mathematical noise.

3. Zero-Account Resumable Upload Engine

Network interruptions shouldn't force you to restart an upload from zero.
LimeShare pairs an ephemeral device key with IndexedDB to store session chunk states locally. If your connection drops at 99%, picking the same file immediately calculates the missing byte offset, re-aligns the frame counter, and resumes without losing previously transmitted chunks. No login or tracking cookies required.

4. Client-Side Streaming ZIP64

Ever wonder why services take minutes to prepare a "Download as ZIP"? They are packaging your unencrypted files on their servers.

LimeShare implements a Client-Side ZIP64 Streamer:

  • The recipient’s browser requests the encrypted chunks asynchronously.
  • Chunks decrypt on the fly inside an isolated memory buffer.
  • A streaming zip generator packs decrypted data directly into the filesystem output stream (via the native File System Access API or Service Worker Streaming Sink).
  • Server CPU usage for packaging: Zero. Server visibility: Zero.

5. LimeDrop: Direct Browser-to-Browser Pipe

For users on the same Wi-Fi network or direct routing paths, LimeShare can bypass remote storage entirely via WebRTC DataChannels.
Files stream peer-to-peer at full LAN throughput (50–100+ MB/s) with an automatic 15-second fallback to encrypted cloud edge if strict corporate NATs interfere.


Built for Real-World Workflows

We didn't design this as an academic crypto demo; we built it as a battle-tested daily driver for professionals who cannot afford leaks or downtime:

  • For Video Editors & Designers: Send 3 GB ProRes cuts, 4K footage, or multi-gigabyte PSDs with zero compression, gigabit unthrottled downloads, and instant in-browser media previews decrypting straight into canvas/video elements.
  • For Lawyers & Compliance Officers: Absolute Zero-Knowledge confidentiality. When a transfer expires, LimeShare generates a Cryptographic Certificate of Destruction verifying exact byte purge timestamps for NDA audits.
  • For Privacy Advocates & Whistleblowers: No emails, no phone numbers, no tracking scripts, no log retention.
  • For Marketers & Media Buyers: Distribute high-value campaign packs, creative variations, and webinars without third-party ad banners distracting your clients.

Try It Live

LimeShare is live in production. No signup forms, no paywalls for basic transfers, no invasive full-screen advertising:

👉 Test the transfer speed & crypto: limeshare.org

We’d love to hear your thoughts on the stream sink implementation, WebCrypto performance across mobile viewports, and our browser container framing in the comments below!

Top comments (0)