# JMAP as replacement of IMAP **URL:** \ **Category:** Feature Proposal\ **Created:** [April 27, 2021, 9:28pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652 "2021-04-27T21:28:05Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![mbeko](https://support.delta.chat/user_avatar/support.delta.chat/mbeko/32/175_2.png) [@mbeko](https://support.delta.chat/u/mbeko)\ **Post date:** [April 27, 2021, 9:28pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/1 "2021-04-27T21:28:05Z")
I’d like to raise awareness of the [JSON Meta Application Protocol (JMAP)](https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol). 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](https://www.ietf.org/blog/jmap) make this protocol interesting for implementation in Delta Chat. ---
**Author:** ![Simon](https://support.delta.chat/user_avatar/support.delta.chat/simon/32/287_2.png) [@Simon](https://support.delta.chat/u/Simon)\ **Post date:** [April 28, 2021, 5:51am UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/2 "2021-04-28T05:51:50Z")
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. ---
**Author:** ![mbeko](https://support.delta.chat/user_avatar/support.delta.chat/mbeko/32/175_2.png) [@mbeko](https://support.delta.chat/u/mbeko)\ **Post date:** [April 28, 2021, 8:38am UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/3 "2021-04-28T08:38:59Z")
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](https://wiki.xmpp.org/web/XMPP_Office_Hours). For now, only the slides are available on the schedule page, but the recording will certainly be uploaded soon. ---
**Author:** ![link2xt](https://support.delta.chat/user_avatar/support.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://support.delta.chat/u/link2xt)\ **Post date:** [April 29, 2021, 5:06am UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/4 "2021-04-29T05:06:57Z")
> [@mbeko](#): > > 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. There are several mentions in the [issues](https://github.com/deltachat/deltachat-core-rust/search?q=jmap&type=issues), but corresponding issue is closed as there are no plan to work on it soon. > [@mbeko](#): > > 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. This is likely a rate limiting issue on the server, not an SMTP problem. > [@mbeko](#): > > You might be interested in the “Intro to JMAP” talk that Daniel Gultsch gave in the last [XMPP Office Hours](https://wiki.xmpp.org/web/XMPP_Office_Hours). For now, only the slides are available on the schedule page, but the recording will certainly be uploaded soon. Looks like it is [uploaded](https://yewtu.be/watch?v=VnRvDyyhEyQ) already. I’ll watch and probably comment here on it. By the way, he is also developing a JMAP client [Ltt.rs](https://ltt.rs/) ---
**Author:** ![link2xt](https://support.delta.chat/user_avatar/support.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://support.delta.chat/u/link2xt)\ **Post date:** [April 29, 2021, 6:24am UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/5 "2021-04-29T06:24:13Z")
- 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](https://dontkillmyapp.com/), especially iOS for which there is no other solution. But there is also a [Webpush extension](https://doc.dovecot.org/configuration_manual/coi/) 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](https://capnproto.org/rpc.html) 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 ---
**Author:** ![mbeko](https://support.delta.chat/user_avatar/support.delta.chat/mbeko/32/175_2.png) [@mbeko](https://support.delta.chat/u/mbeko)\ **Post date:** [April 29, 2021, 6:40pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/6 "2021-04-29T18:40:23Z")
Thanks for your assessment and the details related to Delta Chat’s functioning! > [@link2xt](#): > > This is likely a rate limiting issue on the server, not an SMTP problem. 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. > [@link2xt](#): > > he is also developing a JMAP client [Ltt.rs](https://ltt.rs/) 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. > [@link2xt](#): > > but I don’t see much benefits to Delta Chat 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. ---
**Author:** ![Simon](https://support.delta.chat/user_avatar/support.delta.chat/simon/32/287_2.png) [@Simon](https://support.delta.chat/u/Simon)\ **Post date:** [April 30, 2021, 2:18am UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/7 "2021-04-30T02:18:55Z")
> [@link2xt](#): > > 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. 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… 🤷‍♂️ > [@mbeko](#): > > Another example is that sometimes e-mails arrive several days later via IMAP while they’re already visible in the web interface. 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. ---
**Author:** ![adbenitez](https://support.delta.chat/user_avatar/support.delta.chat/adbenitez/32/2323_2.png) [@adbenitez](https://support.delta.chat/u/adbenitez)\ **Post date:** [April 30, 2021, 5:48am UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/8 "2021-04-30T05:48:14Z")
> [@mbeko](#): > > 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. I am using nauta.cu 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 🤔 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 😉 ---
**Author:** ![link2xt](https://support.delta.chat/user_avatar/support.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://support.delta.chat/u/link2xt)\ **Post date:** [April 30, 2021, 7:11am UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/9 "2021-04-30T07:11:58Z")
> [@Simon](#): > > 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… Overall, this JMAP standard looks very similar to [XMPP Over BOSH](https://xmpp.org/extensions/xep-0206.html). On the other hand, Thunderbird is planning to add JMAP support at some point: [Roadmap - Thunderbird](https://developer.thunderbird.net/planning/roadmap) ---
**Author:** ![mbeko](https://support.delta.chat/user_avatar/support.delta.chat/mbeko/32/175_2.png) [@mbeko](https://support.delta.chat/u/mbeko)\ **Post date:** [May 1, 2021, 8:49pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/10 "2021-05-01T20:49:44Z")
> [@Simon](#): > > with dc or with other mail clients too? 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. > [@adbenitez](#): > > I am using nauta.cu IMAP/SMTP servers and it works in real time 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. > [@link2xt](#): > > On the other hand, Thunderbird is planning to add JMAP support at some point 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](https://jmap.io/software.html). ---
**Author:** ![aelius](https://support.delta.chat/letter_avatar_proxy/v4/letter/a/7feea3/32.png) [@aelius](https://support.delta.chat/u/aelius)\ **Post date:** [June 9, 2024, 4:55pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/11 "2024-06-09T16:55:40Z")
I think there are some more potential benefits of JMAP (those familiar with it please weigh in). - DC clients could request and process high priority messages first (such as, user left group) before fetching the bulk of the messages. Would mitigate the issue where someone replies to a group before downloading all messages. - Might be feasible to only implement lazy loading. Again, largely a benefit for DC groups where users haven’t opened DC in a long while. - Expanding on the above: maybe users don’t want to leave a group, but they aren’t very active. Maybe they only participate in the group from specific devices. IMAP mail clients can unsub from syncing folders: an individual DC client could choose to not download group messages, while still being able to quickly pop in on demand without penalty via JMAP. And don’t forget, even small speed improvements can go a long way to the perceived user experience! I don’t have many DC messages to sync, and a device left offline for a few days does spend several seconds syncing on start. That is also an issue that will increase with scale. Users heavily invested in DC could migrate to a JMAP provider to improve their experience. Since the last post in this thread, JMAP’s availability has increased, in terms of libraries and available FOSS clients to take notes from. Specifically, aerc: [aerc/worker/jmap at master · rjarry/aerc · GitHub](https://github.com/rjarry/aerc/tree/master/worker/jmap) See also: this page has likely been updated since you last checked [JMAP Software Implementations](https://jmap.io/software.html) Lastly, DC has branched into new territory with chatmail. “How many users would actually have access to and benefit from jmap?” It could be every chatmail user. Chatmail is easy to self host and light on resources, and interested individuals are encouraged to set up chatmail on a toaster? Perhaps JMAP would perform even better on that toaster or under constrained bandwidth. Food for thought 😛 ---
**Author:** ![Andreas](https://support.delta.chat/user_avatar/support.delta.chat/andreas/32/2393_2.png) [@Andreas](https://support.delta.chat/u/Andreas)\ **Post date:** [June 16, 2024, 6:47am UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/12 "2024-06-16T06:47:53Z")
I think it’s a good thing to also use JMAP, the problem is, in my opinion, once the economic funds to make it have been found, there is a lack of developers. This is why making DC known can only make other DEVs join the project. Our DEVs are already doing the impossible, they are preparing for miracles… ---
**Author:** ![adbenitez](https://support.delta.chat/user_avatar/support.delta.chat/adbenitez/32/2323_2.png) [@adbenitez](https://support.delta.chat/u/adbenitez)\ **Post date:** [June 19, 2024, 12:25pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/13 "2024-06-19T12:25:37Z")
we now have chatmail servers using plain old IMAP + PUSH notifications and it works blazing fast no JMAP needed, maybe there would be some small benefits on using JMAP, but IMAP will not disappear any time soon, so we would need to make heavy changes to DC core to add JMAP and still support IMAP at the same time anyway, so the cost outweighs the benefits ---
**Author:** ![link2xt](https://support.delta.chat/user_avatar/support.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://support.delta.chat/u/link2xt)\ **Post date:** [June 19, 2024, 2:15pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/14 "2024-06-19T14:15:53Z")
JMAP has some new features like permanent Thread id that can be used to request messages that belong to the same reply thread and likely the same chat. But most of the features are designed for webmail clients working with unencrypted emails. I hope that in the future Delta Chat will completely hide `In-Reply-To` and `References` using [header protection](https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/) so the server will have less metadata about which messages are related to each other. This goal is not compatible with the server grouping messages into threads or prioritizing important messages about chat membership changes. If we implement JMAP we will likely use a subset of features that exist in IMAP as well. Then there is still an advantage of JMAP being more difficult to distinguish from web browsing and block. JMAP should be more widely deployed for this to become interesting. > [@aelius](#): > > Lastly, DC has branched into new territory with chatmail. “How many users would actually have access to and benefit from jmap?” It could be every chatmail user. Chatmail is easy to self host and light on resources, and interested individuals are encouraged to set up chatmail on a toaster? Perhaps JMAP would perform even better on that toaster or under constrained bandwidth. Chatmail is based on Dovecot and judging from the dovecot mailing list Dovecot developers are not very interested in adding JMAP into Dovecot. Dovecot is indeed very lightweight and because of this chatmail is unlikely to switch to some new IMAP + JMAP implementation. For example [Stalwart Mail Server](https://github.com/stalwartlabs/mail-server) supports JMAP but requires a database backend. I doubt this is going to use less resources and I don’t see how JMAP can save bandwidth compared to IMAP. ---
**Author:** ![adbenitez](https://support.delta.chat/user_avatar/support.delta.chat/adbenitez/32/2323_2.png) [@adbenitez](https://support.delta.chat/u/adbenitez)\ **Post date:** [June 19, 2024, 2:19pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/15 "2024-06-19T14:19:54Z")
> [@link2xt](#): > > I don’t see how JMAP can save bandwidth compared to IMAP. this is because you can download binary attachments as binary instead of base64 encoded part in IMAP, but it is not relevant, I guess, if you anyway want to send the binaries encrypted ---
**Author:** ![link2xt](https://support.delta.chat/user_avatar/support.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://support.delta.chat/u/link2xt)\ **Post date:** [June 19, 2024, 2:56pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/16 "2024-06-19T14:56:01Z")
> [@adbenitez](#): > > this is because you can download binary attachments as binary instead of base64 encoded part in IMAP, but it is not relevant, I guess, if you anyway want to send the binaries encrypted Indeed, in case of OpenPGP-encrypted emails from the point of IMAP/JMAP server payload is not a binary with `Content-Transfer-Encoding: base64`, but an unencoded `application/octet-stream` MIME part that starts with `-----BEGIN PGP MESSAGE-----`. JMAP standard has no way to request binary OpenPGP payload for such messages. To save bandwidth it is more interesting to support IMAP COMPRESS extension. ---
**Author:** ![Raiden](https://support.delta.chat/user_avatar/support.delta.chat/raiden/32/2544_2.png) [@Raiden](https://support.delta.chat/u/Raiden)\ **Post date:** [June 19, 2024, 3:30pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/17 "2024-06-19T15:30:15Z")
> [@adbenitez](#): > > but it is not relevant, I guess, if you anyway want to send the binaries encrypted Wouldn’t an encrypted attachment that isn’t encoded as base64 still be significantly smaller? In my experience, attachments can be about 30 percent larger with base64. ---
**Author:** ![link2xt](https://support.delta.chat/user_avatar/support.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://support.delta.chat/u/link2xt)\ **Post date:** [June 19, 2024, 9:42pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/18 "2024-06-19T21:42:10Z")
Currently in Delta Chat attachments are base64-encoded using MIME `Content-Transfer-Encoding: base64`, but if OpenPGP is used then the whole payload is signed, compressed and encrypted, so compression negates the effect of base64-encoding. Afterwards base64 is applied again, but as ASCII armor rather than MIME encoding, this is unavoidable as ASCII armor is required by [RFC 3156: MIME Security with OpenPGP](https://www.rfc-editor.org/rfc/rfc3156) For unencrypted messages sending binary data without any encoding is theoretically possible, but in practice we never know if receiving server can accept binary 8-bit emails: > [@Integrated compressor](https://support.delta.chat/t/integrated-compressor/1128/7): > > OpenPGP already compresses the message losslessly before encryption, but after encryption the message is base64-encoded. We can hardly do anything about it, because other encodings for OpenPGP are not standardized. There is a [binary MIME content-transfer-encoding](https://tools.ietf.org/html/rfc3030), but it is not widely supported and can’t be used to re-encode OpenPGP messages: OpenPGP messages are not using base64 Content-Transfer-Encoding, but ASCII-Armoring instead. OpenPGP message is basically a text message starting with ----… So there is no easy way to avoid base64 overhead when sending mails. However when the mail is finally delivered to the server, we can get rid of base64 overhead. JMAP servers can decode MIME base64 encoding back when the mail is finally delivered, but IMAP COMPRESS or TLS compression can achieve the same effect and also work for OpenPGP ASCII armor. ---
**Author:** ![r10s](https://support.delta.chat/user_avatar/support.delta.chat/r10s/32/1513_2.png) [@r10s](https://support.delta.chat/u/r10s)\ **Post date:** [February 16, 2026, 9:55pm UTC](https://support.delta.chat/t/jmap-as-replacement-of-imap/1652/19 "2026-02-16T21:55:05Z")