[agloeregrets]

That’s all super fair, but they also argue this direction allows them to innovate as well. Notably, their direction resembles a rails approach and lets the server do more work. (Because Hey is instead just a standard API client, whereas the client can tell the server things that you just can’t do with IMAP.)

I imagine with the Apple situation they are working on adding support currently however, even if it’s reduced. They need an iOS plan B.

[maxsilver]

> They need an iOS plan B.

I hope they don't. Apple needs to feel the pain their evil and immoral behaviour is inflicting on the world.

In a perfect world, the government would force them to behave ethically. Absent that, Hey's stance here is the next best thing.

If folks like Basecamp don't start standing up to Apple, then nothing stops Apple from just outright killing the majority of mobile software development. And while it's not directly their fault, at some point iPhone users need to recognize that their purchase of an iPhone is directly funding the destruction of the innovative / creative software they claim to want to have.

If you like Hey, maybe stop buying a phone that's trying to murder Hey. If you run a company like Hey, maybe stop giving in to the mafia's extortion demands.

[rockwotj]

> In a perfect world, the government would force them to behave ethically. Absent that, Hey's stance here is the next best thing.

In a perfect world there is a good enough iPhone competitor that would force Apple to behave better because otherwise companies wouldn't build apps on their platform.

[thatguy0900]

I wonder if there's any single app company other than Google and Facebook that could take this stance and have Apple actually care. It's definitely not hey though.

[maxsilver]

> It's definitely not hey though.

For Hey alone, agreed. I don't think they have enough clout.

But Hey is a cool/popular new thing. If the next 20 coolest newest things also skip Apple as well (because Apple continues this grossly unethical behaviour) then Apple iPhones might lose their largely-unearned reputation as the place where the coolest/most-polished apps live.

It doesn't necessarily have to be a huge multinational corporate stance to make this painful. It just has to be enough of the trendiest new things people want.

[knowledge-clay]

> That’s all super fair, but they also argue this direction allows them to innovate as well.

That's true, but I would argue, perhaps somewhat conservatively, that email is an area where we don't want or need much innovation. Email works fine and has for decades. In many cases, "innovation" (except at the protocol level) has made things worse.

[swyx]

I mean, good for you, but all that proves is that you're not their target audience.

[knowledge-clay]

I believe that there is such a thing as good, responsible engineering practices, such as supporting open standards, that companies ought to to irrespective of "target audience". I'm not saying using IMAP is a better user experience and that everyone should use it, but I believe that any email provider has a responsibility to support IMAP.

[imchillyb]

I would argue that their non-standard implementation will make transitioning away from their service impossibly difficult.

The fact they don't support the widely supported IMAP means no easy way to move away.

This is vendor lock-in to their walled-garden. This approach should be killed, dead, before it ever makes it to the end user.

[bronson]

Transitioning away sounds easy: https://hey.com/faqs/#if-i-don-t-like-hey-can-i-export-my-em...

[wolco]

Lifetime forwarding if someone has a paid account? This will change in time. I wouldn't rely on it.

[HeXetic]

What do you think they can do with their custom API that IMAP can't? IMAP has server-side search and a file-based representation of things like configuration. It may not be as easy to write as a JSON API, but once you do, the interface is flexible enough to really accomplish anything.

[dewey]

Their whole "filtering everything out until you whitelist the sender" approach which is the one feature that sets HEY apart from the other providers wouldn't really work with normal IMAP.

As for IMAP with more JSON there would also be Fastmails https://jmap.io/

[zimpenfish]

> Their whole "filtering everything out until you whitelist the sender" approach

Unless I'm missing something about what they're doing, this is a basic SIEVE script that filters anything not explicitly whitelisted into a folder.

[dewey]

This has a bit of a "I can build Dropbox with a bunch of shell scripts over the weekend" vibe. I'm sure there's a bit more to it than that. How would you whitelist things in your regular IMAP client? Manually moving things to the IMAP Inbox and which then marks them as whitelisted somehow?

You could probably build that with a bunch of hacks but you'll not get a polished consumer friendly feature out of that. They are not in competition with people running mutt and a bunch of custom scripts, it's more of an alternative for people using Gmail with Gmail apps currently and don't even know what's IMAP.

[hayyyyydos]

> How would you whitelist things in your regular IMAP client? Manually moving things to the IMAP Inbox and which then marks them as whitelisted somehow?

That's exactly how you'd do it, and the functionality definitely exists - all handled on the server side. See: learning spam from ham by dragging to/from the spam folder.

https://wiki.dovecot.org/Pigeonhole/Sieve/Plugins/IMAPSieve

[dewey]

I wasn't trying to say that this method would be hard or impossible to build, but it's hard to use for the average user. Moving mails around on mobile apps is already annoying enough (At least in the iOS Mail.app)

[zimpenfish]

> How would you whitelist things in your regular IMAP client?

If I were building it for my parents, I'd say "anything in Pending/Held/StrangerDanger that you flag will be whitelisted and will be in the Inbox from then on".

Flagging a message on iOS Mail is pretty straightforward - swipe+tap or long-press+tap+tap and easy enough conceptually as a "this is good" action, I think?

Backend picks up the flag change, adds the address to the inbox, strips the flag, and moves that message to the inbox.

Add "move it to junk to undo the whitelisting" for completion (also easy on iOS Mail).

Perhaps not as polished as writing a custom app to do it, no, but it seems fairly consumer friendly to me?

[HeXetic]

The server can put messages into whatever folders it wants. Different folders can even put the same message into multiple meta-folders. The whitelist can be stored as a message (as basically a file) in a config folder. This is pretty straightforward IMAP.

Again I'm not arguing that IMAP isn't creaky and clumsy but let's not pretend that lack of power is the reason they didn't use it.

[bradly]

Can IMAP snooze messages?

[zimpenfish]

That'd be down to the IMAP server to support, I suspect, but you could certainly have one that understood the logic - "if there's a message in Snoozed and it's older than X, move it to Inbox". If you have access to your mail, you could do it yourself with a shell script and cron.