What Happens When Your Message Self-Destructs?

A peek inside the self-destruction mechanism — from frontend to backend.

You paste a message. You set the timer. You click “Create.” Moments later, a short-lived message is born — but what happens next? How does BareSend know when to delete it, and how does the countdown work?

Step 1: Encryption in your browser

Before anything reaches our server, your message is encrypted client-side using AES-GCM with a 256-bit random key. The encryption key never leaves your browser. We never see it.

Step 2: Upload + expiration timer

Once encrypted, your message is uploaded to our backend along with:

• A server-side expiration time — e.g. “valid for 1 hour.”
• A unique message ID (not the key).
• No user data, no IP logs, nothing identifying.

The key itself is never sent. You share that separately — that’s the magic of zero-knowledge.

Step 3: Decryption request

When the recipient opens the link, the frontend sends the message ID to the server, asking: “Is this message still valid?”

If it is, the encrypted message is returned. If not, they get nothing. The message is already gone.

Step 4: 60-second fuse

The moment a valid message is decrypted, two things happen in parallel:

• The decrypted message is shown on screen.
• A 60-second timer starts ticking — both in the browser and on the server.

After those 60 seconds, the backend erases the message permanently. Even if someone refreshes — there’s nothing left to find.

Step 5: The vanish

The frontend visually counts down and then clears the message from view. But the real deletion happens server-side — ensuring it's gone for good.

No drafts. No recovery. No backups.

We don’t store undecrypted messages beyond their expiration. We don’t cache content. We don’t do sneaky “trash bins.” When it’s gone, it’s gone.

That’s not a bug. That’s how trust is built.