Hacker News Reader

This is a great point: "There are no intermediary servers with access to your account or copies of your messages." A number of popular email clients use intermediary servers and that's a complete deal breaker for me. I'd argue that should be a deal breaker for almost anyone. I'm not a security expert, but as far as I can tell, for most people the single biggest security vulnerability is an attacker gaining access to their email. Using a mail client with an intermediary mail server essentially doubles the surface area attackers can exploit.

I never quite understood what the value add was for email-client developers to use intermediary servers. Is it to gather usage telemetry or something else?

Usage telemetry can be gathered pretty easily from the client itself. Having an intermediate service is usually for stuff like push notifications, search, autocomplete, recommendations and really any other feature that goes beyond the email spec and would be difficult or cpu intensive to implement on all the clients.

Pessimistically for telemetry, but I suspect some of them are Javascript apps in a lightweight shell that have actual technical difficulties making a TCP IMAP connection.

Yeah, I think difficulty making an IMAP connection is one reason. I think the biggest reason has been to decorate more features on top of the backing email service, like adding Snooze support to an arbitrary IMAP account (so the server can un-snooze a message at the scheduled time).

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.

Doing TCP from a "native" JS app should be pretty easy[1] (caveat: I haven't tried.) I'd think the cost of running a proxy server would be enough motivation to figure this out, for any developer whose primary reason is as simple as technical difficulties with JS and TCP. I think it more likely the other responses such as doing heavy indexing that won't work as nicely on the clients.

[1] https://stackoverflow.com/questions/41674063/is-it-possible-...

On iOS (and some of the more aggressively power-saving OEM Android builds), it's the only way to implement push notifications

On the positive side, you could use them for some privacy features, like predownloading images (works with popular clients like Gmail which prefetch them, whether you read the email or not, to water down analytics)

It turns the app into a service which might require an ongoing fee, which is revenue.

Indexing and search can be sophisticated & available before downloading any messages; you can ensure completion of complex pop and imap operation (eg working with messages "tagged" by gmail); just a few benefits.

Note, this is in no way an endorsement of middle manning email management and facading as a client.

I was about to install it until i went through OAuth setup which grants the "Mimestream" application permissions do to a number of things including "Read, compose, send, and permanently delete all your email from Gmail"

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

I don't see much difference in the distinction between the client software (written by Mimestream, probably with regular updates) having access to your account, which it obviously has to has, and Mimestream having direct access. But IANA security researcher, so salt liberally.

I mostly agree -- it takes a level of trust to provide your credentials to a third party app.

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.

Tokens are granted to the app running on your Mac, not a service. There's definitely no Mimestream-run service component with access tokens to your account.

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.

This looks great!! It's beautiful and lightening fast. I would definitely pay for this. Except for one thing.

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.

Great feedback – I've gotten this request a lot today. It's been something I've always planned on doing, but based on the popularity of this request, this is a lot higher up on the list now.

Awesome! If you need more feedback or want to actually watch me work in gmail, I'm happy to do a screen share. My email is in my profile, hit me up if you're interested.

I use priority inbox with custom queries too, so that's the missing killer feature for me. Right now I just use standard priority inbox with the four slots (starred, important+unread, unread, everything else) but multiple inbox with five sounds pretty good now that I see these queries.

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.

Installed it but really miss the same categories as above! hopefully this can be added soon.

it is indeed very similar to how I use gmail (both personal and work accounts) and the reason I've stuck to the web interface so +1000

This is really interesting work. Have you paid the $15,000 for a security audit Google requires now for accessing the Gmail API.

https://support.google.com/cloud/answer/9110914?hl=en

If so how was your experience going though the audit process?

I had to go through a Google security review process, which took surprisingly long to get through (probably a good thing!). However, the $15k+ 3rd party audit is only necessary if you are running servers that have a copy of client data. Mimestream only caches email data on your Mac, so I didn't have to pay this fee.

We do still have to trust you though right njhaveri? If I understand it correctly this is a closed source app with unlimited access to GMail.

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.

This is a very fair concern, and I sympathize with it a lot. I have thought about this a fair bit, and thought about eventually turning this into a "source-available" model (but not yet, I'd at least like to be fully launched on both App Stores first and have some user-base). There are pros and cons to that. At the end of the day, if you install an app from the App Store, you place trust in the developer. App Store Review only goes so far (e.g. look at Epic sneaking in an alternate payment system). Even if I made source available, the typical user has no guarantee that it matches the binary they're installing from the App Store.

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.

How does Mimestream work in terms of MFA? Im not familiar with how Goolge OAuth handles it, but if I granted access to Mimestream app from one machine, can the same grant be used from another(i.e. bad actor's server)?

Thanks :)

I notice that many, many software + service / SaaS are like that.

"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.

It's a valid question, though I suspect that trust in a paid, MacOS-AppStore environment fundamentally works differently to the open source world.

Congrats on an amazing launch! You might though consider a new name before going to the App Store?

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.

Because “Amazon” is a name that in 1997 implied online bookstore? Or “Twitter” implied microblogging platform in 2008? I feel you’re over thinking it because you do know what MIME means in this case, for the average person that doesn’t, they very likely won’t think twice about it.

Thunderbirds aren't common in the wild either.

Well, not lately, but there were plenty on the road when I was a lad.

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.

The name does tap into the psyche though, thanks to the ancient TV show - and Indigenous tales, of course, though those are probably less widely known.

This is fantastic, please support Google Advanced Protection as I cannot add my account as a result of it being enabled on my account.

  "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."

> To prevent unauthorized access, Advanced Protection only allows Google apps and verified third-party apps to access your Google Account data, and only with your permission. - https://landing.google.com/advancedprotection/

I didn't realise until now that third-party apps could work with Advanced Protection.

I didn't either. I'll be looking into this. Thanks!

I looked into it and it seems by invite only. I get it.

Thank you for looking into it. I will consider removing it from my account... seems to only add barriers that are vendor lock in and not actual security.

Do you need the full advanced protection setup (hw key required for every session)? It does work with the somewhat less draconian normal key support where the key is required just for new logins.

AFAIK from my time in the APP, The "blessed session" system doesn't work any differently as I don't recall needing the key to access passwords.google.com or anything like that.

Yes, I like having something titled 'Advanced Protection' on my central Google account.

Would you please please please share what “Classic mode” is all about in Mail.app? I have this theory that a few important people at Apple protested killing it, so some poor soul had to add “Classic mode” to keep them happy while working on improving Mail.app.

First of all congratulations on a great looking app. I just set it up for my work account (I use a different provider for my private mail) and I love how I have all labels available. I'm also excited that you'll distribute it via the Mac App Store.

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.

Thanks! I have been hearing the plugin feedback a lot lately, and I will be thinking about making a plugin API in the future.

Hi, i browsed through the website but didn’t find a comprehensive comparison with Apple Mail. Why not just using the default macOS email client?

There are two main differences: 1. Mimestream uses the Gmail API (instead of IMAP), so it supports more Gmail features: Gmail categorized inboxes, first-class labeling support (apply multiple, change color, etc), use all the Gmail aliases you have set up, use the signatures you set up in Gmail, and conduct server-side searches with Gmail search operators. A lot more is coming on this front, as the app is still in development. 2. This is a lighter-weight client with a minimal local cache. Mail downloads a copy of every message in your account and requires a lot more disk space to use.

How was your experience working with the GMail API?

It's nice to have a RESTful API, and nice to access to more Gmail features, but there are several aspects where it is not as efficient as it could be, and multiple round trips are required with the server to perform some basic tasks that IMAP can execute in 1 round trip. It also has pretty aggressive request throttling, which is fine for a very thin client like Mimestream, but would not be a good fit for a client that wanted to download every message in the account.

Can you say a little more about the thinness and what the offline capabilities are? I noticed the search looks like it happens serverside which is great when you're online since you get actual gmail search. What happens when the client is offline?

Search is a merge of server-side results and a very basic local search that right now only looks at From and Subject. If you're offline, you'll get the local search results.

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.

Thanks, I think you're right to identify 'predictability' as a key feature here. It's not so much that I need my every message offline (for which, as you point out, I can just Mail.app) it's that I'd like to have some idea of what I can expect offline if the client says it works offline. If the client doesn't offer any predictable offline features it's not really an offline client.

Thanks for answering, i have a Gmail account that i barely use and i didn’t knew about all these features.

It sounds like the biggest difference is that it uses Gmail's API instead of MIME, so it has better support for Gmail features like labels.

Screenshot on homepage shows Finder menubar, although the app is active. Looks a bit off.

Oops. Thanks for pointing this out, it's fixed now!

While you're at it, you might what to stop time at 9:41 ;)

I know this is a low quality comment, but I wanted to take a moment to say that I think this looks incredible. Sleek, professional, private, and packed with utility. Great work.

> Mimestream differs from other email clients because it uses the Gmail API rather than IMAP

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 think that's more than just a technical point. If someone sold me an email client that only supported one provider, I'd feel swindled.

I would encourage them to reconsider their "email client" language. It's asking for a headache.

Let's not go overboard, you two.

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.

> 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.

"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?

Awesome. The only thing that drew me away from Apple Mail is the fact it didn't have build-in snooze functionality for emails like Gmail has. Does/will Mimestream support this too?

To bad it has a macOS 10.15 requirement.

Are you planning to support the "postpone" feature? This is the one thing that is missing for me when using gmail in Apple Mail.

Would love to, but need Gmail API support. Please consider Starring (but don't comment +1): https://issuetracker.google.com/issues/109952618

The app looks sleek. Do you plan to also support Gmail's smart compose feature or is that beyond what a native app can support?

This is great! Will you be supporting the different type of inboxes e.g. "Important first"?

I've received an overwhelming amount of feedback asking for this, and I plan to add this functionality.

Any plan to support Outlook.com?

Also interested. Would be good to have the ability to add standard IMAP accounts as well.

I am definitely interested in eventually supporting IMAP, JMAP, and Outlook in the long term. In the short term, the focus will be on making the Gmail support solid.

Looks quite good, congratulations on having put the effort for a native app.

Awesome, do you plan on integrating things like gmail tasks?

Definitely planned ;)

To add, calendar support would be nice.

This looks absolutely amazing. Nice one!

Can you make this a competitor to Thunderbird rather than being locked into GMail? I would love to have an app like this that used IMAP and was multiplatform!

https://news.ycombinator.com/item?id=24428666

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...