Show HN: Mimestream, a native macOS email client for Gmail
mimestream.com
mimestream.com
Mimestream is written in Swift, and uses AppKit+SwiftUI for a clean, stock appearance. It's designed to be fast, lightweight, and use a minimal amount of disk space. Mimestream's advantages over using the Gmail web interface includes features like multiple accounts, a unified inbox, system notifications, swipe actions, dark mode, (some) offline support, tracker prevention, multiple keyboard shortcut sets, and more.
Mimestream differs from other email clients because it uses the Gmail API rather than IMAP, so it supports more Gmail-specific features like categorized inboxes, Gmail's search operators, first-class labels support (apply multiple via ⌘L, set colors, etc), synced aliases, synced signatures, etc. I'm planning a lot more work in this area, including server-side filter configuration, Google Drive support, G Suite directory autocomplete, and more.
The app is a traditional email client that makes direct connections to Gmail and stores your data on your Mac. There are no intermediary servers with access to your account or copies of your messages. Mimestream is free for a limited time during the public beta, but will eventually be a paid app by the time it gets to the Mac App Store.
I hope you enjoy trying out the beta, and I look forward to hearing your feedback!
That being said, there are security/privacy implications to that model, and I wouldn't personally use an app that works this way. That's why Mimestream was built as a traditional client.
[1] https://stackoverflow.com/questions/41674063/is-it-possible-...
Note, this is in no way an endorsement of middle manning email management and facading as a client.
One can blame it on Google OAuth UI or on Mimestream UI, but its not clear to me whether these privileges are granted to the locally installed application and can only be used by it
OR
whether these privileges are Granted to "Mimestream" the Google OAuth App account which can then be used to do those actions outlined above by some service associated with "Mimestream" Google App.
Needless to say, i chickened out from using my main google account with it and instead will test drive it with a toy account
However, there are precautions that you can do to minimize the risk of your credentials used without your authorization with a local client software:
1) requiring multi-factor authentication when credentials are used from a new location/device/ip... 2) A local firewall(like little snitch for osx) that surfaces any unexpected outbound requests.
These obviously wont be much help if you grant some other server permission to access your email.
One tip - on the Google OAuth sign-in page, you can inspect the URL's query component to see the redirectURL parameter, and you'll see where Google will send the token. In Mimestream's case, it is <long-custom-scheme>:/oauthredirect, which is a custom scheme registered with macOS by the app, so macOS shows you the "Do you want to allow this page to open Mimestream" prompt.
This being said, you are totally correct, when you use any closed-source app like this that you did not build yourself, you are placing trust in the developer, and you are wise to be cautious.
In my opinion, there are still several practical security/privacy downsides to apps that run intermediary services with access to (or copies of) your email: - A larger attack surface (the intermediary service) for an adversary to take advantage of, and one that is probably less hardened than Gmail - A larger bug surface, as the service could potentially accidentally expose your data to another user (and this sort of bug _has_ happened in the past to others). - Google probably has serious policies/systems in place for preventing a curious (or disgruntled) employee from reading your unencrypted email. Hopefully. That level of sophistication seems less guaranteed from a small company, and it's completely invisible to you as a user.
It doesn't seem to support priority inbox, which is critical to my workflow. My currently gmail inbox looks like this:
in:inbox is:important is:unread
in:inbox -l:important -is:updates -is:promotions -is:social
in:inbox -l:important (is:updates OR is:social)
in:inbox -l:important is:promotions
in:inbox is:important is:read
The only reason it's like that is because gmail limits you to five sections. Ideally I would split up updates and social.
The first section is my triage section, and the only one whose unread count I care about. The rest I try to triage by skimming once a day and cleaning once a week.
Then the last section is my "todo" section, things I have to respond to that will take more than a minute.
So if I could customize the interface with the searches I want and in the order I want, that would be ideal. And then have a view where I can select how many messages from each section are visible at once (like in Gmail's multiple inbox view).
If I could do that, I could easily see myself paying $100 for that, especially if it has a companion ipad/iphone app.
I'm pretty hungry to switch from Spark and their intermediate servers, and I bet I'm not the only one. At work I use full GSuite integration, so am pretty much stuck with Wavebox or another Electron aggregator. But for personal use this hits exactly the right spot for me.
https://support.google.com/cloud/answer/9110914?hl=en
If so how was your experience going though the audit process?
How can users be sure that it doesn't do stuff that you say it doesn't or that you are who you say you are, considering "Mimestream LLC" only has an email address and your HN profile has only ever posted about this one app?
Hope that's not too aggressive :) legitimately curious if this is something that you've thought about or if you are planning on gaining reputation over time to the point where people will click through the scary "This app can delete all of your gmails" warning.
I've also thought about starting with an OAuth scope that allows all operations except permanently deleting email, and asking the user to re-authenticate and upgrade their scope the first time they try to permanently delete something. This is a little awkward from the user experience, though. Maybe burying this as a fallback mechanism during the onboarding flow is an option.
General reputation-building is probably the right place to start.
"Sign up to our cool thing and see how well it works with all the PII you put in it. We are closed source, do not present our company, our team, or how we intend to earn money. No privacy policy too, but hey.. we do have a nice email"
/endrant
This really surprises me. I'd never try these out. Should be so easy to just be a bit more open.
In this case at least the founder announces himself, which is a good start.
Telling someone who doesn't read HN about your app would be very difficult because "mime" and "stream" aren't words people would expect next to each other. "Mime" is also a pretty uncommon word. Getting the early adopter crowd now who understand the name is important but this app has exciting potential I think for an audience beyond that.
I do think the median user would be nonplussed by a name like Mimestream. One struggles to form a mental image of a stream of mimes, and I assure you that knowing that something called MIME exists is uncommon.
"Advanced Protection prevented your Google Account from signing in. This security feature stops most non-Google apps and services from accessing your data to keep your account protected."I didn't realise until now that third-party apps could work with Advanced Protection.
My job these days is heavily email based, it sometimes feels like all I'm doing all day is jump between gmail, Slack and Zoom. Thus I've spent a lot of time optimizing my workflow with labels, etc. Unfortunately, I also rely on a lot of integrations with 3rd party services (through Chrome plugins):
- Salesforce - Calendly - Grammarly
If push comes to shove I can do without Calendly and maybe even without Grammarly but its entirely impossible for me to do my work. I dream of an email client like this but the unfortunate reality today is that anything not (easily) connected to certain other services is in a tough position for email power-users - or just people in weird jobs.
Good luck. I'll keep an eye on Mimestream. Maybe at some point there'll be a plug-in API and an opportunity to bring some 3rd party services into the app.
When you're offline, you can view messages. However, only the most recent messages are cached in the account, and caching is run lazily with the background activity scheduler, which won't run if your device is under any kind of load and runs infrequently on battery. Overall, I eventually plan to offer a "days of mail" setting to make this more predictable.
You can also take actions on messages – marking them read, starring them, replying and sending new messages, etc. This is all architected to work while offline and replay when a connection becomes available. This design is necessary to make things seem snappy when the client is online.
Overall, I have not yet heavily tested the offline capabilities, and there is some work to do around the caching predictability story. If offline access is a very firm requirement, I would recommend a client designed around this model, like Mail.
Technically speaking that make Mimestream not an email-client, but only a Gmail-client.
It's only an email-client if it works with general email-providers, which this one clearly doesn't.
I would encourage them to reconsider their "email client" language. It's asking for a headache.
Their title on HN and website is "A native macOS email client for Gmail," and that's exactly what it is, especially if you were trying to be technical.
It's like bickering that it's not a native client, it's a macOS client, because it only runs on macOS. Or that you'd feel swindled if it didn't run on Gentoo because anything that calls itself "software" when it's really "Macware" is basically false advertising. It's an odd attempt at pedantry.
"Email client" used to mean something before everyone started assuming Email = Gmail.
Imagine someone submitting a link posted as "A web-browser for facebook.com".
Nobody here would ever accept that a piece of software which could only work on facebook.com to be an actual web-browser.
So why should we allow for the same exception when it comes to email?
To bad it has a macOS 10.15 requirement.
The multiplatform part is completely dependent on if anything is done to get appkit and swiftui working on other platforms, which is probably a solid "no" for the foreseeable future.
https://forums.swift.org/t/swiftui-for-non-apple-platforms-l...
> Note: The Gmail API should not be used to replace IMAP for full-fledged email client access. Instead, see IMAP and SMTP.
I'd be a little worried they will disable API access for the client due to this.
Google did vet Mimestream as a general-purpose email client before approving API access, and on the paperwork for that process "general purpose email client" was the app category that I selected, so I'm hoping all will be OK, or else I will be really scrambling to implement new protocols :P
I wonder about native app viability these days though. Years ago I used native email apps like Outlook, KMail, and Thunderbird, but lately I just use the websites made by the service providers (Fastmail for personal, Gmail for work). As an open standards person I find my behavior kind of depressing, but the websites just tend to work better.
Hoping other platforms follow suit. Preferably using SwiftUI...hey, I can dream right?
This makes it seems like it's up to those other platforms, but it's really all about Apple's decision, right? (in which case I'll eat my metaphorical hat if this happens)
- Plain web app, eventually PWA
- cli/daemon + native browser
- web widget
No need to package a full browser with the application, unless one just wants to be lazy and avoid writing browser agnostic code.
Every application shipped Electron besides contributing to global warming, is yet another point increase in Chrome market dominance.
There truly is no escape.
WebKit is not Bink, and it is good so, we don't need Chrome über alles, aka ChromeOS.
1. It's wicked fast (seriously) 2. It has Gmail style shortcuts
The only thing I wish it had was a generic IMAP support for some of my other accounts. Either way I've been liking it!
I'm also really keen on adding support for JMAP and Office 365 I the future.
Edit: downloaded the beta. Will give it a shot with my work G Suite account.
I use Thunderbird on my Mac because I need things like smart signatures that are dependent on my outgoing email address but I want a combined Inbox.
A native app that supports JMAP and provides that sort of integration would let me migrate from Thunderbird, which while it's been awesome for the years I've used it, is showing its UI age.
Actually, I’d easily pay $25 or even more for a similar app, for Fastmail.
same. Hoping there was some obscure winner.
- Snooze
- Scheduled Send
- Undo send
- Missing attachment warnings ("you said see attached but have no attachments, did you mean to attach something?")
Unfortunately, Gmail API support is lacking for Snooze: https://issuetracker.google.com/issues/109952618, but I will eventually add the ability to do a Mimestream-local snooze (which makes more sense once there is an iOS companion app)
Same for Scheduled Send, see https://issuetracker.google.com/issues/140922183 :(
I still find that hard to believe, and it's a deal breaker. IIRC, the Gmail app doesn't support signature formatting at all. Please do.
Once Snooze is added, I'll happily buy this app for $20+ - I've been waiting for something like this since Inbox and Mailbox were killed off.
I have two asks:
1. Glad you're supporting Gmail shortcuts, but sad to say they aren't working in a second keyboard locale which I have (as basically any non-Anglo-American user would). Gmail provides two columns for keyboard shortcuts in settings so I went and manually adapted all keys. Or maybe Mimestream could support that automatically, for instance Superhuman has no issues with the language I'm using. Currently I just can't use any keyboard shortcuts unless I switch my input to English.
2. I specifically dislike unified inbox, could there be a setting to revert the side bar, so instead of the top level Inbox with folders for my accounts it would be top-level accounts with folders for each?
Thank you for working on this!
#2 is something I'm hearing more about... I'll plan on offering this in the future.
Did you ever consider adding a Markdown to HTML email option?
This is especially helpful when sending formatted code around!
# 1. Put markdown on clipboard
# 2. Convert to hex
out=$(pbpaste | pandoc -f markdown -t html -s | hexdump -ve '1/1 "%.2x"')
# 3. Convert to an applescript data class
osascript -e "set the clipboard to «data HTML${out}»"
# 4. Paste rich HTML
You can use something like Alfred or Keyboard Maestro to trigger that script with a keyboard shortcut.As a programmer, having native markdown support in the app is something I wish for almost every day (especially for code blocks). It's something I plan to add.
Kudos!
One criticism though, the swiping is incredibly annoying right now. You have to swipe an almost painful amount to archive emails without a click, it should require less than half the swipe-distance of what it does now. Look at how little swiping Chrome needs to go back to the previous page, and emulate that.
One tip: by default, the Delete key is mapped to Archive (though you can change that in Preferences to be Trash if you prefer that). A little faster than swiping.
> The app is a traditional email client that makes direct connections to Gmail and stores your data on your Mac. There are no intermediary servers with access to your account or copies of your messages. Mimestream is free for a limited time during the public beta, but will eventually be a paid app by the time it gets to the Mac App Store.
I appreciate the thought behind this. However, it means you can't implement some other features (pixel tracking, scheduled send, snooze) unless GSuite opens up an API for them. Consider having a subscription which uses a 3rd party server. I would be happy to pay for it.
It sounds like huge disadvantage when email client works with just one provider.
Benefits: this app likely doesn't use 1 GB of RAM. That's pretty much my only complaint about Mailplane (not blaming them; there's not much they could do about that). The native UI is likely nice, but not going to be the main factor causing me to switch.
This app is native and fricking fast.
Is there a chance you could recompile this to support 10.14?
I'll most likely not be upgrading from Mojave for the foreseeable future, until my 2013 MacBook Pro stops working and I'm forced to get something new.
One thing I don't like though is the Big Sur requirement as early as this year. I'm also still on Mojave and will probably upgrade to Catalina in the coming weeks.
It's only been a day but 5 accounts in Mimestream is only using 350 megs of memory versus 1 tab of Gmail using 1.4 gigs of memory.
As another comment pointed out, can we have the ability to do like Priority Inbox or allow us to just show Unread + Flag (like Mail)?
After using emails for 20+ years, I'm pretty immune to all the jazz that comes with emails, and can survive pretty well. The only thing that I need now it the ability to see "Unread + Flagged". Please refer to my screenshot for how my Mail typically looks like -- https://public.oinam.com/photos-oinam/brajeshwar-apple-macos...
Or perhaps a snooze button for specific period of time. Do you have any intention of such features?
Besides, the application is great. Good work.
Similarly, it would be awesome to hide inbound email until I want to see it (while I am still able to use my mailbox to send email and respond to already-received messages.)
EDIT: Ah, it turns out Gmail can schedule email sending. Thanks @llarsson!
There are loads of email clients but something that would not be distraction for an end user is a market on it's own.
Do you intend to have a subscription based plan or one-time fee purchase?
You can expand it further for JIRA, GitLab and others. Just a suggestion to create unique selling spoint for Mimestream
The only snag here is that I haven’t updated to Catalina.
Will be trying this out when I finally upgrade (possibly directly To Big Sur).
Excellent work guys. I hope pricing is reasonable and perhaps there's a family package or something.
You can reset your cache by running these this in Terminal: rm ~/Library/Containers/com.mimestream.Mimestream/Data/Library/Application\ Support/Mimestream/Mimestream*
rm -rf ~/Library/Containers/com.mimestream.Mimestream/Data/Library/Application\ Support/Mimestream/Attachments
I miss some things, like keyboard shortcuts for jumping to a specific label, superstars, search items suggestion (for specific GMail filters like has:attachment), but overall this is really good, and honoring the label colors is an excellent touch.
Some more advanced features that come to mind would be multiple tabs, deeper Calendar integration to display inline your schedule when receiving .ics attachment.
What will the pricing model be?
Sadly, superstars aren't yet possible with the Gmail API, but please star this Gmail API issue to express your interested: https://issuetracker.google.com/issues/166654165
Another feature request is to support the vertical split layout, it's more comfortable for tall screens.
Not sure if this has been mentioned in the comments yet (I came across this post 100+ comments later), but one thing I miss terribly after leaving AirMail was the ability to write markdown in email. I absolutely loved the split-pane window when writing an email, and see it update in real-time as I write my markdown'ed email.
I am on the web-client for Gmail for now, and although there are browser plugins for MD, they feel quite clunky to use. It would be great if you could consider MD support in composing emails!
After watching WWDC2020 this spring, I'm pretty convinced that Apple has set itself up with what looks like one of the cleanest IDEs for building user-facing ML applications and I'd like to give it a try.
It uses a declarative language to describe the UI, so I think it should be much easier to learn than the previous imperative paradigm.
For the most part, you can get away with the standard "visual defaults" as you call them on the platform. You can easily create a complete app without having to customize any UI, although it obviously adds to the look and feel if you do.
Does it support e-mails with winmail.dat? That's been my biggest annoyance with Airmail, I end up having to go to the gmail web interface to view any e-mails with winmail.dat
https://mjtsai.com/blog/2019/10/11/mail-data-loss-in-macos-1...
Would have been useful to be able to reuse my email address from desktop but using a different email seemed to work fine.
One suggestion: I really love the iOS gmail app feature to quickly switch between all mail and show unread mail only. I'd love a button or an option under the "go" menu to jump to unread mail. I know I can type "label:unread" in the search, but a one/two click method would be awesome!
While we’re on this topic, do you have any plans to add custom integrations with 3rd party services like Todoist and Bear? That’s one reason I’ve switched to Spark and I’d be extremely happy to pay you for it.
My only question relates to payment. This is an app that I would gladly pay a solid price to own (in the ballpark of $50?). I would _much_ prefer that over a subscription model.
Because the site mentions eventual payment, but doesn't specify a pricing model, would you be willing to elaborate on your intentions?
Don't offer permanent licenses, it will add complexity to purchase and support. You do not want a users with a product of yours with a vulnerability they are not entitled to update.
A subscription-only model will allow you to focus on only the last build which everyone will be entitled to download, greatly simplifying your support.
You will be able to add features at your pace and will avoid the bloating that results when you compete with yourself as is the case with a permanent license model and (increasingly stupid) upgrades.
You will focus on quality not on corner case features to justify upgrades or interface revamps for the sake of it, confusing your existing user base. If you keep your quality high and the product is stable and reliable, your users will stick.
We have been selling our desktop product (in our case B2B) as subscription-only for 8 years and we couldn't be happier about the decision.
For those unfamiliar, with Sketch, you basically have a yearly subscription and you continue receiving regular updates while you are subbed. Once your subscription expires, you get to keep the version you paid for at the beginning of your subscription period, but you stop receiving future updates (aside from security ones and such, ofc).
With Sketch it makes sense, because each year they add a cumulative of lots of new features and such, so people are motivated to renew the sub every year to get those features. With an email client, however, there isn't much in terms of "new features coming every year with updates" that people would be excited to pay the sub for on regular.
However, I still think it is worth exploring and considering as a viable possible option. With that model of "yearly sub, but you get to keep the old version once the sub expires", you allow people (who don't wanna deal with subs and just wanna use the barebones product to pay for once and forget) to experience your product and give you money. And powerusers and those who just want to support the project would be happy to pay the annual sub on regular and receive new features as they come. With that in mind, I would think a yearly $50-60 sub is pretty reasonable, but I am not an expert on pricing things like that, so take it with a grain of salt.
I spent a while with a professional version until the community edition had some features that convinced me to move over.
I pay for the following subscriptions/software as a tech user (I do some development, but most of my work is design and management):
* Fastmail business (I've got email in the archive back to 1998)
* Microsoft Office for Mac
* Dash
I see my subs as a monthly work/business cost, so I'd see Mimestream as "worth" somewhere around the $10/month price point. I'm just one data point though :)
The company I work with/for uses a combination of GSuite and things like Lucidchart/Confluence/JIRA, but that's their choice :)
[1]: A term coined by Brent Simmons, creator of NetNewsWire, (in my opinion) the best Mac-assed RSS reader. https://inessential.com/2020/03/19/proxyman
In the meantime I'll change my default browser for a moment and see how it goes.
Edit: It worked switching default browsers.
@njhaveri can you please clarify?
Thanks!
I would love to see — and would definitely pay for — a similar approach to Google Calendar. Unfortunately CalDAV-based clients only offer a fraction of the web client functionality.
What’s your stand on the latest changes announced at this year’s WWDC for Mac development?
Is there a way to get rid of the badge counter on the dock icon? I somewhat feel anxious/FOMO when the counter is there.
[edit] logs forwarded
I admit I cannot see the logic of this statement. Explain?
Does it support end to end encryption with PGP or smime?
> Read, compose, send, and permanently delete all your email from Gmail
anything you can say to make me feel better for allowing this level of power for a beta app from a random person on the web? i'd really like to try it out.
PS - Thanks for the app, it's already an improvement in some ways over the gmail interface... looking forward to even more!
Still, great job!
This comment isn't useful to me, or him, without specifics.
That said, the FAQ mentions that the for-profit model is designed to avoid ads in the client and to "take a strong stance on privacy", which is a little bit disingenuous given that the client exclusively relies on an email service provided by the world's largest advertiser and email data miner.
Yes, Mimestream itself isn't using my data, but there's a bit of induced cognitive dissonance in taking a strong privacy stance for a Google-specific product.
Come on, they're explicitly saying that they're charging for the service. It's pretty clear that when they're talking about privacy the caveat is that they won't suck your data into another sink (them) _other than google itself_, being the provider of gmail and all.
I'm all for privacy and informing the user but they're hardly playing word games here.
I'm not saying they're playing word games. I'm saying the strong ethical stance on privacy is diluted by the underlying service they built their product on.
If I built a new automobile refueling station that dispensed diesel and gasoline, but used the fact that the pumps themselves ran on solar energy to claim "I strongly believe in 100% renewable energy", well yes, in one way you're living up to your ideals, but in another larger way, you're really not.
Here’s hoping you can use it with an actually private email service in the future.
I would like to add support for IMAP and JMAP in the future, which should broaden the scope of services you can use this with!
I would much rather have my emails sucked into some developer’s private server than sit on the server of a large multinational that provides them to the federal police and national military without warning, notice, just cause, due process, or meaningful judicial oversight.
Doing gmail-first is the error, and is an endorsement of a society without privacy or the rule of law.
You have produced an espionage-only email client.
We can’t just go about our lives, pretending gmail is okay because it’s popular. Using gmail and building in its ecosystem is an explicit endorsement of gmail which is part of an illegal military spying program.
They aren’t different things, as much as I imagine we’d all like them to be. To endorse gmail is to endorse illegal military spying, and is to endorse a society without privacy.
As of October 2018, Gmail had 1.5 billion users.
That's sadly a step in the wrong direction. JMAP (https://jmap.io/) has been around for a while and it is a shame google refuses to adopt it.
Being snobby about protocols isn't useful and comments like that should be sent to Google instead.
JMAP has been around for 5+ years, and specs published last year by the IETF: https://tools.ietf.org/html/rfc8620 and https://tools.ietf.org/html/rfc8621