22619ebd11
Client-side libsodium encryption with the key in the URL fragment, an Express/SQLite server holding ciphertext until a confirm-token round trip proves successful decrypt (avoiding the delete-on-first-byte race), TTL sweep for unclaimed drops, and a password-gated upload UI styled to match flit. Dockerized to match the project family's conventions, with a named volume so the DB/blobs survive redeploys, and a Gitea Actions workflow to build and push the image.
wisp
Short-lived, end-to-end encrypted file sharing. Send a file to someone who isn't online right now — they get a link, they get the file once, and then it's gone. The server never has the ability to read what it's holding.
Why
flit already does encrypted file transfer between devices, but it's
synchronous — both sides have to be online at the same time for the WebRTC
handshake. That's fine for "send this to my other laptop right now," and
wrong for "here's a file for you, grab it whenever."
wisp is the asynchronous counterpart: upload once, the recipient retrieves later, on their own schedule. That async gap is the one thing flit's architecture (zero server storage, direct P2P) structurally can't do — it requires the server to actually hold ciphertext for a while, which is new territory for this project family, not a variant of something already built.
What it isn't
- Not zipline. Zipline is persistent link/screenshot hosting — you keep the URL, the file stays. wisp is the opposite: single retrieval, then the file is unrecoverable, by design.
- Not flit. Flit needs both peers online simultaneously and never stores anything server-side. wisp is deliberately async and requires temporary server-side ciphertext storage.
Core model
- Sender encrypts the file client-side (symmetric, libsodium secretbox — same primitive flit's browser client already uses).
- Ciphertext uploads to the server. The encryption key never leaves the
sender's browser except inside the URL fragment (
#key=...), which browsers never transmit in HTTP requests. The server only ever sees opaque bytes. - Sender shares the link through any channel they like.
- Recipient opens the link, downloads the ciphertext, decrypts client-side.
- On successful decrypt, the client sends a short confirmation to the server. Only then does the server delete the blob.
- A TTL (default: a few days) is the backstop for links nobody ever opens, so nothing sits on disk forever.
Full design, including why "delete on first byte served" is the wrong default, is in IMPLEMENTATION.md.
Status
Design only. No code yet.