The blog post you are referencing explains the changes the XMPP community has to do to keep up with what Lets encrypt did. TLDR: People just need to upgrade their servers.
Maybe the first but not the only one. Ltt.rs (an email client using JMAP) does this as well. BTW you can also directly deliver WebPush notifications to FCM servers. No need for a proxy/rely run by the app developer.
Ltt.rs has support for both UnifiedPush and FCM and is fully open source. The code difference between UP and FCM is very very minimal since - as I said - both are just WebPush endpoints.
There are certificates that are valid for the XMPP domain example.com but not for the regular (HTTP) server on example.com. Off-the-shelf verifier don’t have support for that.
* Conversations uses two different OpenPGP implementations. (It doesn’t)
* The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely
* ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool)
* ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.
With an up to date Conversations on a modern server we have a pretty good chance to detect or prevent that style of attack due to a mechanism called SASL Channel Binding.
No I don’t use it daily. It can’t even send emails yet and you have to set your login credentials at compile time. I got frustrated having to deal with HTML emails and now I’m waiting for the servers to mature a bit. And honestly also for dovecot to announce support. I mean I love what the fastmail+cyrus team is doing; but if Dovecot is not going to support it, it is probably not worth it to build a JMAP-only MUA.
The strong suit of JMAP (among other things) is getting access to specific properties of a server side parsed email. It will do the MIME parsing for you; separate attachments and text bodies from each other and for example allows a client to fetch only Subject and senders instead of the entire email. By brainlessly dumping all that into a Maildir you'd be giving up a lot of the benefits of JMAP. I'm a big fan of JMAP but I don’t see it replacing IMAP for (desktop) clients that will keep a fully synced Maildir locally.
Pretty cool protocol. I've been following this for a couple of years. I had already written a library for an earlier version of JMAP (back then references worked differently / didn’t exist); and it was interesting to see how that improved in the IETF process.
I wrote a library [1] and a POC email client for Android [2] earlier this year. It takes a moment to fully understand a now fairly complex protocol but when you get the hang of it it becomes very powerful.
Sadly the server support isn’t really there yet. The support for Cyrus hasn’t been released yet (you need git) and some vital functionality like push [3] is still missing. Also no word from Dovecot yet.