March 28, 2026
Encrypted tea, spilled
Building an E2E Encrypted Chat Application with LanceDB and Libsodium
Privacy fans cheer; skeptics ask if this chat’s database can keep up
TLDR: A new demo shows a truly private chat app where the server stores only scrambled messages using LanceDB and libsodium. Commenters love the privacy and low cost, but debate whether an add‑only database can keep up with chat speeds and the ongoing index housekeeping needed to keep it fast.
Seal, a new end‑to‑end encrypted chat demo, is serving hot privacy tea and the crowd is thirsty. The pitch: the server acts like a blindfolded mailman, storing only scrambled messages while your secret keys stay locked in your browser. Devs are buzzing over the one‑file database choice, LanceDB, plus trusted crypto from libsodium. Fans swooned over the "no servers to babysit" angle and the promise of cheap hosting, calling it “click‑deploy privacy.” The wow factor? A fresh encryption key for every message, like using a brand‑new lock every time you text.
But the comments lit up with practical worries. The loudest thread: can a mostly “append‑only” database keep pace with real‑time chat? One commenter asked point‑blank about index upkeep—the behind‑the‑scenes table of contents that keeps searches fast. Others fretted about encrypted images piling up, and whether browser‑stored keys survive refreshes without drama. On the lighter side, memes flew: “the server is just a USB stick with Wi‑Fi,” and “blind mailman delivers the gossip he can’t read.” The split is clear: privacy purists are clapping for a server that can’t snoop, while performance hawks want proof it won’t crawl when group chats and attachments hit rush hour. Drama level: spicy, with extra index seasoning.
Key Points
- •Seal is an end-to-end encrypted chat app where the server stores only ciphertext and never sees plaintext or private keys.
- •The system uses LanceDB as an embedded, unified data store for messages, user data, channel metadata, and encrypted image attachments.
- •Core challenges addressed include managing per-message ephemeral keys, storing ciphertext with metadata, multi-recipient encryption, client-only key persistence, and schema evolution.
- •The architecture treats the server as an untrusted relay using FastAPI for storage/relay and WebSockets for real-time delivery, with clients handling all encryption via libsodium.
- •Cryptographic design uses libsodium’s WASM build with X25519: each message uses a fresh ephemeral key, a random nonce, crypto_box_easy encryption, and discards the ephemeral private key for forward secrecy.