Hey, I’m Carlos, maker of Mail Memories (https://mailmemories.com), an app that lets you export images from your email account and Blackjack Break (https://blackjackbreak.com), a deconstructed blackjack game.
Nah, but thanks. I actually spent a lot of time checking out Takeout, shell scripts, and existing options before writing a single line of code for the app.
Non-technical users don't want to deal with mbox files no matter how many scripts someone recommends. And shell shells scripts...
I made this to bridge the gap. I wanted a utility that handles the protocol mess locally, avoids downloading gigabytes of metadata, skips the cloud, and just gives you your own photos back.
Clever. But Gmail and Google Drive share the exact same 15 gb storage quota. If a user has 10 gigs of photos in their Gmail and runs this script, it'll create another 10 gb of files in their Drive.
Instead of saving space, this script doubles their storage usage to 20 gb, breaking through the 15 gb free tier and forcing them to buy a Google One subscription.
That’s one of the reasons this desktop app exists, it streams the files straight to your hard drive so you can avoid this
Just wanted to take a moment to say thank you to everyone who commented today. Launching on HN isn't for the faint of heart, but it’s been really valuable.
What a day. I was told my landing page looks like an AI wrote it, got roasted for a confusing illustration metric (and rightly so), and received the ultimate rite of passage: being told my app could be replaced by a couple of Linux CLI commands.
Unironically, thanks everyone. Because of your feedback, the site copy's a little tighter, and the Windows installer no longer throws a scary UAC prompt. I couldn't have asked for a better (or more intense) test.
You're half right. The HTML and CSS are from a standard template that I imagine exists in just about every LLM's dataset, since they've scraped an internet's worth of them. I wrote (and rewrote and rewrote...) and edited every single word on the page, though.
Just pushed an update to the site around this. Changing the text to "Downloaded" still might confuse someone, so I removed that line from the illustration altogether.
Totally fair, though. In my defense, 98% of my time went into wrestling with IMAP parsing architectures, optimizing memory, and code-signing certificates instead of designing custom CSS layouts from scratch. I'll finesse the design in the future.
I rebuilt the app because I was feeling that same fatigue. It felt like every cool new tool I looked at wanted to upload personal data to a remote server, hook it up to a third-party AI API, or charge a recurring fee.
The original version of the app actually was a cloud-based SaaS. But I figured people would feel significantly more comfortable having a sensitive tool like this run entirely on their own hardware instead of in the cloud like everything else. Making it local-first also makes it easier for people to download and try it out.
No, I'm not afraid of pushback at all. I'm actually really glad I used IMAP.
Building on top of it let me solve a few major protocol headaches directly in the client:
The app filters out signature junk (like tiny social media and logo icons), pulls down just the raw attachments instead of downloading entire 20-year-old message threads, and handles thousands of images while gracefully managing Google's rate limits (to avoid connection drops).
It actually does use IMAP! The app connects directly to Google's IMAP servers via SSL straight from your machine.
I intentionally chose a local IMAP pipeline over the official Gmail API because of platform gatekeeping. To use the API for this, Google forces independent developers into a "Restricted Scope" tier, which requires an annual $15,000+ third-party security assessment.
Going the local IMAP route lets me bypass that completely while keeping user data 100% local and secure.