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.
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.
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 Ltt.rs
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:
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… 
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 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 
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.
I think there are some more potential benefits of JMAP (those familiar with it please weigh in).
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
See also: this page has likely been updated since you last checked JMAP Software Implementations
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 
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…
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
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 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.
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 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.
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.
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.
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
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:
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.