Live data from Hacker News

JMAP: Like IMAP but Not Really

unencumberedbyfacts.com

161–170 of 235 posts

Re: JMAP: Like IMAP but Not Really

#161
I've started to migrate 18 years of email history to Fastmail, after running my own mail infra for almost 2 decades.

I am not impressed. Folders moved in the webinterface show up unmoved in Thunderbird. And vice versa.

Sometimes it works, sometimes it doesn't. They're investigating the problem at the moment, but the updates they've given me don't give me much hope.

I'm looking at migrating away to another provider that just does plain old imap.

Re: JMAP: Like IMAP but Not Really

#162
post #145

FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface. I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years. Seeing this new protocol is exciting, because JMAP i…

> Also from what I understand JMAP should be friendly for mobile usage. They kept notifications out of it, you're supposed to implement notifications using whatever the mobile platform provides. Interacting via JMAP is via plain HTTP requests, which is super cool. Sounds actually not cool. Is there really no standardized way to do notifications? The world consists not only of shitty mobile walled gardens which insist…

If you want good battery life, there is no alternative to the mobile notifications provided by the platform, because otherwise you have to always keep your own connection open to your server.

Re: JMAP: Like IMAP but Not Really

#163

Earlier quoted context omitted.

> Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? If you maintain a connection you have a leave the modem powered. If you connect every so often (1 minute, 10 minutes, whatever) the modem can be powered down in between. The modem and the screen are the top two users of power in a phone so this is a big win.

Sorry, but that makes no sense. Keeping a TCP connection in established state does not require any modem to be powered. I even suspend my laptop with established SSH connections over night, to disk, so it's completely powered off, I could even disconnect the power supply and take out the battery for the night. When I power it back on, the SSH sessions are still working perfectly fine, after hours of being powered dow…

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

So in practice, you have to regularly send traffic down the connection, fully powering up the modem, and ideally that shouldn't happen for each app individually. Now one could imagine a system where the OS coordinates this and signals to apps that the system is going to transmit now, and that they should trigger their own requests, bundling them in the process, 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.

Re: JMAP: Like IMAP but Not Really

#164
post #120
post #67

>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind R…

REST is what Roy Fielding wrote about in his thesis. It is an architectural style, not a protocol. It involves two endpoints exchanging the state of a shared resource. It needs to be compliant with the constraints of that style. People think that REST must be over HTTP, but it can be over any protocol. The essence is that it is a style of systems design, so JMAP can be considered RESTful as described in the link abov…

I know all this, but this API doesn't meet that definition. As cruegge has linked the JMAP developers themselves don't consider their API REST. From the description it seems more like an RPC that's transaction oriented and for very good reasons.

The fact that this is a discussion though makes my point. By REST being only an achitecture style with very loose definitions makes it arguably fit for all different kinds of APIs which in turn has made the term useless over time. Maybe we could use a set of technical standards (like SOAP) for different common API implementation solutions within the bigger REST idea. Discussions like REST vs SOAP are like comparing OO and Haskell, one is a concept/pattern, another is a specific technology.

Re: JMAP: Like IMAP but Not Really

#165

Earlier quoted context omitted.

Most mail clients are running on mobile (judging by number of devices). Long-running connections on mobile are a bad idea because of network reliability and battery concerns.

Hu? Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? And could you also explain how constantly making new connections makes things work more reliably over unreliable links? Like, does that allow you to transfer data when the network link is down? Does the fact that inside the TLS/TCP connection data is transferred via HTTP instead of IMAP…

Ignoring efficiency concerns, modern mobile oses don't allow applications to keep connections open for long. If you want notifications to work, you need to use the platform notification system.

The platform argument is roughly that if they hold open one connection, it's cheaper than each app holding open their own connection. And maybe, if you're optimistic, the platform will be better at figuring out ping intervals for that connection that adapt to broken Nat devices per network (ie: on some networks, wake up once a minute to keep the connection active, and on reasonable networks wake up once every 30 minutes)

Re: JMAP: Like IMAP but Not Really

#166

FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface. I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years. Seeing this new protocol is exciting, because JMAP i…

> after a trial realized that Gmail does many things well, except for being a good email service. This. I remember back when Gmail was new and hot. It was unlike any other email service out there, and ridiculing people for using inferior email-solutions could to a certain extent be justified. While other webmails were slow, had constantly reloading pages and what not, Gmail was fast . It was amazingly fast. Gone wher…

The main thing gmail offered back then was a frickin GB of email storage. (Which spawned a host of other things, like a FUSE filesystem backed by Gmail.) No other free provider was even close! Hotmail offered email measured in 10s of MB and I'm sure Yahoo was similar.

(I got my first gmail account in 2004.)

Yeah, the UI wasn't bad, but there was less email back then and I didn't (still don't) really mind being served HTML repeatedly instead of some "AJAX" application, which is what I remember the technique being called. (It used to be the latency to the server was poor and JS hid that; now, on 2-3ms fiber, it seems that the JS actually introduces a lot more latency than it hides.)

Re: JMAP: Like IMAP but Not Really

#167
post #145

Earlier quoted context omitted.

> Also from what I understand JMAP should be friendly for mobile usage. They kept notifications out of it, you're supposed to implement notifications using whatever the mobile platform provides. Interacting via JMAP is via plain HTTP requests, which is super cool. Sounds actually not cool. Is there really no standardized way to do notifications? The world consists not only of shitty mobile walled gardens which insist…

If you want good battery life, there is no alternative to the mobile notifications provided by the platform, because otherwise you have to always keep your own connection open to your server.

That's simply not true if implemented correctly. Maintaining an open connection yourself has at most minimal impact on battery life. See for example Conversations (XMPP client) which is able to do this just fine on Android.

Re: JMAP: Like IMAP but Not Really

#168
post #163

Earlier quoted context omitted.

Sorry, but that makes no sense. Keeping a TCP connection in established state does not require any modem to be powered. I even suspend my laptop with established SSH connections over night, to disk, so it's completely powered off, I could even disconnect the power supply and take out the battery for the night. When I power it back on, the SSH sessions are still working perfectly fine, after hours of being powered dow…

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 (…

> Now one could imagine a system where the OS coordinates this and signals to apps that the system is going to transmit now, and that they should trigger their own requests, bundling them in the process

FWIW this would happen quite naturally if the system simply used flexible timers for these sorts of wakeups. It's an accepted, even trivial solution to the "need to power something up on an infrequent and perhaps unpredictable basis, and have it be used seamlessly by multiple apps" use case. Centralized services are nice but they shouldn't be the only way for a system to get notified about stuff.

Re: JMAP: Like IMAP but Not Really

#169

Earlier quoted context omitted.

> What would (imnsho opinion) have fixed spam is sender pays. Alternate but similar - sender holds the email until the receiver fetches: https://cr.yp.to/im2000.html I'm not sure it actually helps that much to cut down spam but anything is worth a try at this point.

That sounds like a nice way to allow the sender to work out whether the receiver mailbox is active.

That assumes there's no facility for batching - where my server can ask a remote server "give me everything for " rather than asking for each individual mail.

Re: JMAP: Like IMAP but Not Really

#170
post #86

Earlier quoted context omitted.

Does FastMail let you have complex conditions in filters though? One huge value of Gmail for me is that I can have arbitrarily complex nested conditions to filter mail using a formula. I've been looking for even more flexible filtering (e.g. custom scripts) and yet I have not even come across anything on par with it.

fastmail lets you write complete scripts for filtering using the Sieve programming language. https://www.fastmail.com/help/technical/sieve.html

Sieve is great. I highly recommend it over, say, procmail, or Outlook filters (especially Outlook Web Access).
Post reply on HN