[benmxrt]

Great question. The emails are stored in volatile RAM on the backend only for the duration of the active session.

To ensure a smooth experience if you accidentally navigate away or refresh, I’ve recently implemented IndexedDB local caching on the client side. This keeps your messages accessible in your browser's local storage without them ever being written to our server's hard drive.

However, Mephisto follows a strict 'Zero-Persistence' policy: the moment you explicitly clear your session or the session naturally expires, a wipe sequence is triggered, and all data is cryptographically purged from both the server's RAM and your browser's local cache. If you navigate away without a cache, the signal is lost—just like a true burner phone.

[chaz6]

Is there any reason you need to store them in the RAM on the backend once they have been transferred to the client?

[benmxrt]

That is a valid point. Currently, the backend keeps them in RAM mainly to support multi-device syncing (like the QR handoff feature) during an active session. If a user scans the QR code to open the same inbox on mobile, the backend needs to serve those existing messages to the new client.

However, I'm exploring a 'Transfer & Purge' logic where, once a message is successfully delivered and acknowledged by the primary client, it could be encrypted or removed from the server-side RAM entirely, leaving the responsibility of persistence to the client-side IndexedDB. It’s a delicate balance between UX and the absolute 'zero-trace' goal.

[chaz6]

That makes sense, thanks!