You're right that the current beta uses Guerrilla Mail as the upstream provider for mail delivery. My 'Zero-Persistence' and 'No-Cookie' claims specifically apply to the Mephisto layer: we don't store your data in our own DB, we don't use tracking cookies, and we purge all session metadata from our RAM.

Regarding polling vs WebSockets: The frontend currently polls the Mephisto proxy to ensure maximum compatibility with strict corporate firewalls, but a native WebSocket implementation for our own mail-server node is the long-term goal. I’m being transparent about the proxying—Mephisto is designed as a privacy-hardened 'frontend wrapper' that adds an extra layer of anonymity between you and the upstream providers.

I want to be completely transparent here. Mephisto currently utilizes a few different upstream providers (including Guerrilla Mail and 1secmail) via a custom proxy layer to ensure high availability. The goal of this project isn't to build a new mail protocol from scratch, but to provide a hardened, cookie-free, and zero-persistence 'privacy frontend' that bridges the gap between these APIs and the end-user.

Regarding the AI claim: I've used modern dev tools to speed up the React/TypeScript implementation, but the architecture (RAM-only storage, IndexedDB caching, and PWA focus) is a deliberate design choice I've made to solve specific privacy frustrations I had with existing services. I appreciate the call for better attribution, and I'll be updating the 'About' section to clearly credit all upstream providers.

You got it. This is AI Slop at it's worst. And even the replies from the author reeks of AI. I read some of the source code, and it is slop, which I would never trust without scrutiny. Carefully read just the first words of benmxrt:

You're right that the current beta…

That is a great point

Absolutely agree with both of you

That is an intriguing feature request

That’s a very fair point

You hit the nail on the head

Great question

That is a valid point

Sharp eye

That is a great point, and it's definitely on the roadmap.

The "cat and mouse" game between disposable email services and site filters is constant. I'm currently looking into rotating a pool of less common TLDs to keep the service viable for longer.

The idea of letting users pick from a list is also solid—it gives them more agency and potentially bypasses blanket filters that only target the "default" domain.

Thanks for the feedback, Tony!

That’s a very fair point. Showing the full list makes it easier for automated scrapers to blacklist the whole pool. I’m considering moving to a 'Random Rotation' by default, and only revealing the domain picker for advanced users. Balancing discoverability and resilience is definitely the biggest challenge here.

being able to reply IS the ability to send to an arbitrary address, because the SMTP protocol makes it trivial to SEND an email from any arbitrary address.

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.

[dead]

Wow, thank you so much! That means a lot coming from this community. I'm trying to keep it as lean and purposeful as possible. Glad the implementation resonated with you!