> I built BurnShot to solve a problem: "View once" features on WhatsApp/Slack still leave traces in cloud backups. Standard server-side deletion requires trusting the backend.
So, I rebuilt my app on a strict Zero-Knowledge architecture:
The Challenge:
Here is an encrypted payload sitting on my server. I stripped the #key out of the URL. I challenge anyone to intercept the network request, download the blob, and decrypt the image:
https://burnshot.app/view/243fb87b-f034-44ff-806d-dd60e207d7...
So, I rebuilt my app on a strict Zero-Knowledge architecture:
- 100% Client-Side Encryption (Web Crypto API, AES-256-GCM).
- Decryption keys live in the URL hash (#key), so my server only ever receives and stores garbled .enc binary blobs.
- Postgres RPCs handle atomic view-count detonation to prevent race conditions.
The Challenge: Here is an encrypted payload sitting on my server. I stripped the #key out of the URL. I challenge anyone to intercept the network request, download the blob, and decrypt the image: https://burnshot.app/view/243fb87b-f034-44ff-806d-dd60e207d7...
The UX Demo: If you just want to see the cryptography and atomic detonation in action, here is a full link set to self destruct after 100 views: https://www.burnshot.app/view/d9aafa5d-dccd-43f2-89ff-71a9fa...
I'd love for you to inspect the Network tab, try to break the cryptography, and roast my architecture. Main site: https://burnshot.app