Thanks for reporting this! The issue was caused by the email HTML content not being properly normalized before rendering - some emails from services like emailprivacytester.com return complex nested structures that triggered a React rendering error. I've pushed a fix that safely handles all edge cases (non-string HTML arrays, nested objects in header fields, etc.). Should be live shortly. Really appreciate you testing with edge cases like this!
Just pushed a hotfix for this. It was a missing headers issue blocking the WASM workers. The black screen issue should also be resolved now. Thanks for the heads up!
I built this because I was frustrated with existing file tools requiring uploads for simple tasks like merging PDFs or converting a video.
FileZen is a 100% client-side tool built with React and WebAssembly.
Tech Stack:
- ffmpeg.wasm for video/audio processing (running in Web Workers to avoid blocking UI).
- pdf-lib for document manipulation.
- Vite + React for the frontend.
The main challenge was handling memory limits in the browser (especially specifically on iOS Safari) when processing larger video files.
It's currently an MVP and completely free. I'd love to hear your thoughts on the WASM performance and if you encounter any crashes on mobile devices.
guilty as charged lol i tried way too hard to sound like a professional dev and ended up sounding like a bot... guess that backfired. im honestly just a solo dev who is totally overwhelmed by everyone watching my every move right now. lesson learned: less polish, more me. thanks for the reality check
I’m genuinely overwhelmed by the traffic (hitting 145+ concurrent sessions!) and the deep technical feedback from this community.
As a solo developer, seeing Mephisto being analyzed so thoroughly is incredible. If you support the idea of a 100% cookie-free, zero-persistence temporary mail tool, please consider starring the project on GitHub. It helps with visibility and keeps the motivation high to implement the complex features we’ve been discussing here (like IP-based domain allocation and secure reply-only logic).
You hit the nail on the head. From an SMTP perspective, 'replying' is functionally identical to 'sending,' which is why most disposable mail services are strictly receive-only.
The moment you allow outbound traffic, you risk being weaponized as an open relay for spam. To implement a safe 'Reply-Only' feature, Mephisto would need a sophisticated validation layer that cryptographically links the outbound reply to a specific, recently received message ID. Even then, rate-limiting would have to be extremely aggressive. For now, staying receive-only is a deliberate choice to protect the service's reputation and ensure 100% uptime.
nah its just me lol english isnt my native language so i tried way too hard to sound professional and clear... guess i overdid it and sounded like a bot. im just super nervous with 145 users right now my heart is still racing trying to keep up
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.
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!
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.
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.
