Comment by calpaterson | Hacker News Reader

Comment by calpaterson | Hacker News Reader

> We want to be able to add new features that would exceed the scope of IMAP. Further, the current mail stack was just not built for a good mobile experience, and it's complexity provides a considerable barrier for emerging mobile clients. We want to cut off the legacy baggage and keep the entry barrier for users and developers as low as possible.

What new features? Current email infrastructure already implements everything mentioned on this page. There's mention of the "limitations" of IMAP and SMTP but it seems specious. Reading email is a pretty well solved problem now, and I think every popular language has libraries for IMAP and SMTP.

On the topic of IMAP's performance on mobile: there is an installed base of millions who use IMAP for their mail on their phones. There are many, many good email clients for Android (I recommend K-9 Mail, which is FOSS) and they work great. Presumably it is the same for iOS.

If they write a nice HTTP API for reading mail inboxes, that will probably be a nice option for people who for some reason can't or don't want to use IMAP, but there really is nothing here to move mail forward.

Mailpile is a lot more interesting (webmail and privacy features): https://www.mailpile.is/

Well, could you add instant messaging functionality to IMAP? Can you manage multiple inboxes with one IMAP account? Can you do server side threading with IMAP? Can you manage attachments and messages separately with IMAP? Can you upload attachments NOT using base64 using SMTP/IMAP? Can you use labels with IMAP? Can you manage multiple domains under IMAP? etc.

As for iOS client's there are exactly 3 that come to mind. Gmail, Apple Mail and Sparrow (discontinued).

We realize that this product is not for everyone - but for those who want a zero config, hassle free product.

Mailpile is for an entirely different audience.

> Well, could you add instant messaging functionality to IMAP?

IMAP does not reimplement XMPP, which I consider a feature. If you want instant messaging, you should use XMPP, and it's perfectly possible for a client to allow you to use both.

> Can you manage multiple inboxes with one IMAP account?

Yes, this is built in to the standard and every client can do this

> Can you do server side threading with IMAP?

Yes: http://tools.ietf.org/html/rfc5256

> Can you manage attachments and messages separately with IMAP?

Admittedly not, but again do you really want to? There are separate protocols for managing files and we already have dropbox.

> Can you upload attachments NOT using base64 using SMTP/IMAP?

Yes: http://tools.ietf.org/html/rfc3516

> Can you use labels with IMAP?

Google do it this way, but it's not standardised: https://developers.google.com/gmail/imap_extensions#access_t...

There are also user-defined flags

> Can you manage multiple domains under IMAP?

Yes, almost every client supports multiple accounts.

IMAP is a good candidate for the most often (and most badly) reinvented protocol around. There's plenty of reasons to expose parts off the current infrastructure over HTTP (Mandrill is really useful) but I think if your plan is "reinvent ALL the things" you need to be a lot clearer about what exactly is so backwards about on of the most well studied and well engineered pieces of infrastructure around.

I guess I didnt phrase this very well, with IMAP i mean cloud imap services.

the problem is that it is very complex, and features are not implemented consistently accross clients. Especially the newer, or not standardized ones you listed. You know that there is something wrong when an entire slew of RFCs can be replaced with a few simple api calls.

As for iOS client's there are exactly 3 that come to mind. Gmail, Apple Mail and Sparrow (discontinued).

There's a good reason for that- Apple won't let you check a mail server on the client side. So you have to do what Mailbox did and set up huge server infrastructure to check people's e-mail then send push notifications. It makes it a lot more difficult than just making a client app.

So, the "solution" is to have your users set up a .forward-filter that pings a web service on new mail? Then have a really simple status server that simply replies with number of new mails since last check (or something along those lines...) - and have your email client poll (and reset) that counter... would give a few false-positives, but probably be better than having to poll an actual (variety of) IMAP/POP3-servers.

(This obviously won't work for most end-users, sadly)

Yes, but we run our own servers.

Reply on news.ycombinator.com