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