XMPP at 11 years old would place us in the year 2010. Requirements were different in those times. Psi on my desktop and Bombus (a J2ME client) on my Nokia E71 worked great. The transition from that into the mobile-first age was rough though. The article says that too. It only improved in 2014-2015.
Everyone says this and so I believe them, but I used xmpp as my primary communication tool through the whole thing and it worked ok on my first android phone (HTC magic) and amazingly on my n900 followed by acceptably on my BB10 device and never had any issues
Indeed. And on a Google-free Android phone the XMPP client Conversations can utilize its existing, permanent XMPP connection to deliver push notifications to other (mostly open-source) apps using an alternative to Google push (FCM) called UnifiedPush.
XMPP these days often gets used as a friends-and-family style messenger (Think WhatsApp, iMessage, Signal replacement) rather than something communities would use (Discord/IRC). A lot of users of XMPP are also out of the public eye. NATO, police forces and intelligence agencies use it. The community style channels are supported though and a search engine for them can be found here: https://search.jabber.network/channels/1
The existence of "XEP-0365: Server to Server communication over STANAG 5066 ARQ" suggests military usage. Isode advertises XMPP as "The NATO Standard for instant messaging" (https://www.isode.com/secure-xmpp/) and it is one of their core offerings. I remember seeing NATO command posts using IRC long ago - makes sense because it is ultra light, and therefore usable on extremely low bitrate degraded links... XMPP seems to be the successor for that purpose.
https://www.sigidwiki.com/wiki/XMPP_trials says "On shortwave, you can see the military use this protocol. They are known for using MIL 188-110A Serial HF waveform (fixed 600bps/S) and 6-bit code clear text with dual bursts of STANAG 4539 and STANAG-5066 as for XMPP Multi-User Chat (MUC) messages, over a bandwidth of 34 kHz. Multi-User Chat (MUC) is a central service for military communication. [..] XMPP is widely used for military deployments, where operation over constrained and degraded networks is often essential, particularly for tactical operation"
Thanks! That was exactly the kind of "hidden usage" I was interested in as it seems to not be publicly used by a lot of people these days (As you can see by the user numbers on https://search.jabber.network/channels/1).
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.
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.
* 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)
> * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202.
Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway.
"Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.
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.
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.
JMAP (IMAP+Submission replacement) has support for WebPush. If I have a minute I’ll implement UnifiedPush in https://Ltt.rs - Sadly JMAP doesn’t have a lot of server implementations. (Yet? Maybe)
That'd be quite cool :) I've been using maddy for a self hosted mail server, itd be nice to replace it with stalwart and give ltt.rs a try... and convince the hosted mail i use to start using a JMAP supported server
AFAIK Cyrus has JMAP support. We are using it for more than 20 years at work without any issues. However, we are lacking compelling client support for JMAP (via using SoGo via IMAP currently). Would be great to have a good static webclient for security reasons. Configurable notifications would be another plus.
Is there a way to sign up to it which is as simple for tech-illiterate people as WhatsApp/Signal? I recall the last few times I, a developer, have tried to functionally use any sort of XMPP based thing it has been a confusing and inconsistent experience.
