JMAP as replacement of IMAP

I’d like to raise awareness of the JSON Meta Application Protocol (JMAP). It is a modern version of IMAP and SMTP with the goal of overcoming the issues with these protocols.

I think especially the advertised ease of use for developers and improved experience for mobile users make this protocol interesting for implementation in Delta Chat.

It’s not used widely enough from what I know.
But sure in the future deltachat could have support for it, but as an addition to imap support, not as replacement of imap.

1 Like

That’s correct, it’s not that widespread, yet, but I thought it should appear on Delta Chat’s long-term roadmap.

I wrote the post because I was surprised that there was no mention of JMAP here in the forum. So I wanted to make you aware of it as it seems to have a lot of potential to create a better user experience.

As an example of the issues that occur on various mail servers with Delta Chat but also other mail clients that use IMAP/SMTP:
Today, I had to wait five minutes until my message has been sent.

I wrote “replacement” because first I understood that JMAP is compatible with IMAP. But in hindsight I see that I got that probably wrong. It should be an addition, not a replacement.

You might be interested in the “Intro to JMAP” talk that Daniel Gultsch gave in the last XMPP Office Hours. For now, only the slides are available on the schedule page, but the recording will certainly be uploaded soon.

1 Like

There are several mentions in the issues, but corresponding issue is closed as there are no plan to work on it soon.

This is likely a rate limiting issue on the server, not an SMTP problem.

Looks like it is uploaded already. I’ll watch and probably comment here on it. By the way, he is also developing a JMAP client

  • MIME parsing included: actually IMAP is also able to do some MIME parsing and you can retrieve parts of MIME message body via IMAP. But it does not work for encrypted messages which are a majority of messages sent with Delta Chat, so MIME parsing has to be implemented in the client anyway. And when messages are sent between email servers, they are still sent as MIME messages over SMTP.
  • Third party push: this is indeed necessary for some phones, whose vendors artificially restrict the ability to run apps in background, especially iOS for which there is no other solution. But there is also a Webpush extension for IMAP which does the same thing.
  • Accessible via HTTP: this is an advantage for web applications, such as webmail interfaces, and may offer some resistance to network filters, but is not necessary for Delta Chat.
  • As mentioned on slide 18 (“Can JMAP be used for IM?”), JMAP does not have a way to push messages to the client. Same as with IMAP, you still need an additional round-trip to fetch the message after getting notified about it.
  • “Result references”, which allow Cap’n Proto-like call chaining will not benefit Delta Chat. Delta Chat uses IMAP only as a “feed” and downloads messages as soon as they arrive. After that, all operations are local, so there is no need for better RPC protocol.

Overall, it’s a nice standardized protocol for webmail clients, so you can build an alternative local-first webmail interface for Fastmail, but I don’t see much benefits to Delta Chat, except for:

  • Getting access to push notifications on Fastmail
  • Supporting JMAP-only servers (do they exist?)
  • Bypassing firewalls which block IMAP or SMTP

Thanks for your assessment and the details related to Delta Chat’s functioning!

Maybe, but keep in mind that it was just one example of many. I’ve experienced such issues on five servers, small and large ones in different countries, both for sending and receiving. Also, I’m not connected permanently to the internet and mostly just connect once a day to check and/or send mails and messages.

Another example is that sometimes e-mails arrive several days later via IMAP while they’re already visible in the web interface.

Of course I can’t say if any of those problems is caused by deficiencies in the protocol. I just want to mention that they are common in my experience.

Exactly, I know him personally and we have shortly discussed that the projects could benefit from each other’s experience. That’s how I got the idea to mention the topic here.

All right, I was just thinking that it’s a protocol that can be expected to gain popularity as it’s standardised and working with IMAP as a developer is a pain (at least it is for me and I have heard similar opinions from others).

Once it’s more popular, I assume it would be reasonable for Delta Chat to implement it, if only to support JMAP-only servers that could appear then. Then we could also find out if a good part of the random lags and other issues would be solved with JMAP.

Sidenote: that (+ thread support in wasm for rust async) could enable making a standalone webversion of DC. but you can already make proxy servers that translate tcp sockets into websockets… :man_shrugging:

with dc or with other mail clients too? I’d guess it’s either a bug in dc or bugs in the mailserver software depending on your answer. But that’s a topic for another forum topic, lets keep this thread on point.

I am using IMAP/SMTP servers and it works in real time, messages are sent instantaneously, just like XMPP, etc. I don’t think JMAP would improve anything wrt sending speed :thinking: it is just that most email providers add rate limits.

At the end of the day it will not solve anything for the developers because you then would need to maintain IMAP support, plus JMAP, and based on current situation I doubt JMAP will ever replace IMAP, this old things refuse to die :wink:


Overall, this JMAP standard looks very similar to XMPP Over BOSH.

On the other hand, Thunderbird is planning to add JMAP support at some point: Roadmap - Thunderbird

I’ve lost track a bit, but I think this only happened with other mail clients so far. But you’re right, it doesn’t belong here. I’ll open a topic if I experience it next time with Delta Chat.

It’s great that it works for you so well, but as I wrote, I didn’t mean to speculate about those issues. JMAP certainly is more efficient with use of resources as this is one of its main goals. When it becomes more widespread, we can see for ourselves if it indeed improves the user experience.

They also provide some points why I mentioned it here:

Implementing JMAP (RFC 8620) support at an early stage could be useful for getting experience in (re-)implementing protocols, without worrying too much about existing limitations, and at the same time obtain support for JMAP. It would also help move JMAP forward as a first rate protocol

Here’s also an overview of existing, planned and requested implementations.

1 Like