JMAP: Like IMAP but Not Really

For people reading along: $50/yr gets you 25 GB; $30/yr gets you 2 GB. I'd guess 2 GB would work just fine for most people.

OTOH, my relatively new gmail account has >4 GB in it. Other accounts have 0.8 and >3 GB; none of these were used for file storage (FUSE) or anything like that.

https://www.fastmail.com/pricing/

> Webmail was limited by HTTP, but not because HTTP is stateless; rather, it's because no mail server speaks HTTP, which means every webmail has to implement it's own IMAP proxy

That doesn't explain why it is limited, only why it isn't interoperable. A traditional IMAP client also didn't speak TLS. That wasn't a reason to invent a replacement for IMAP, because you simply stack IMAP on top of TLS, and noone complains that "every TLS IMAP server has to implement its own TLS proxy", let alone gets the idea that you should invent a replacement for IMAP in order to be able to use it over TLS.

> and IMAP as a protocol is very, very bad if you don't want to sync emails to your local machine and thus keep your own copy of the whole mailbox state.

Because? And mind you, we are looking for a reason that would justify (a) inventing a whole new protocol instead of adding a few small extensions and (b) specifically inventing a pull-based protocol that uses HTTP as the basis.

> On the other hand, JMAP does allow you to get push notifications on changes, outside of the normal HTTP API.

In other words: Because JMAP doesn't fit the needs of the application, because it uses a pull-based protocol, and in contrast to IMAP which has push built-in already (well, it's an extension to the original protocol, but one that is widely supported and a relatively simple change to the protocol), they support tacking on a workaround for the resulting problems? And that is supposed to be an argument for the protocol, or what?

As rswail said, REST doesn't need to use HTTP at all, however, if it does then it "should" use it fully including using HTTP headers for metadata. In theory, of course, you don't need anything other than POST

IMAP is just a way for attackers to perform credential spray's against large providers these days.

> That does not work over arbitrary connections, especially not mobile ones: in many cases, long-running connections are terminated (either because a moving phone moved in the network and received a new address, or because a middlebox threw away state about a connection it hasn't seen traffic for in x minutes). If you shut the modem down, you also can not receive messages, so you can only use polling patterns anyways (at which point the benefit of e.g. Websockets is largely lost).

That's only true in so far as it is besides the point. Yes, suspending your phone for hours on end and expecting established TCP connections through some telco's IP connectivity to still work obviously won't work. But that wasn't my point. My point was that interrupting connectivity does not interrupt TCP connections, or other kinds of long-running connections. And that tearing down the connection does not in any way improve the situation with regards to not being able to receive messages.

The mere fact that polling doesn't make things worse in a particular use case is not an argument for designing a poll-based protocol. But also, saying that you can only use polling patterns anyway is a massive oversimplification. Even if you implement a poll-based "background delivery" mechanism, a push-based protocol still is advantageous for when the application is being actively used in the foreground. Mind you, you generally can still poll with a push-based protocol, but that does not really work the other way around. Even if you poll for new messages in the background, you have a better user experience when server-side state changes during active use of an application are reflected immediately in the user interface, so you should still have a push-based protocol, and only switch to polling when in the background.

Also, part of your argument only applies to TCP, which unfortunately uses the IP addresses as part of the connection identity, but that is not an argument against long-running connections per se, as you obviously can build connection protocols that don't do that, see QUIC for a real-world example. So, if that is an aspect you want to solve, you shouldn't invent a new poll-based protocol on top of a "transport" that doesn't fit the needs of the application and that also doesn't even solve the problem (when the IP address changes during an HTTP request, that connection will still fail, possibly using a long-ish timeout, and in any case necessitating a complete retransmit of anything that had already been transferred), but instead you should maybe write a specification for IMAP over QUIC, so you can actually seamlessly continue a data transfer over address changes and NAT remappings.

> but that's not how the platforms work. Instead, the choosen method is to have central push services, which the phone OS polls and then distributes the messages to the apps.

Well, yeah, but that's simply the manufacturers forcing a technically inferior solution on their users in order to gain power over their property. While designing a workaround for this situation certainly is a good idea, making this idiocy the basis for a protocol design, so that even software on sane platforms can not do better does not exactly seem like a bright idea.