XMPP

XMPP is almost 20 years old now, and I've been using it while looking for ways to get distributed messaging. New protocols and technologies are fun, but XMPP has good documentation, works, can be used in either federated or distributed fashion (as most of the other federated systems, coupled with Tor or a similar network), and has plenty of software – so now I think that it is quite sufficient for messaging.

Its specifications (see RFC 6120, RFC 6121, RFC 7622, and extensions) are well-written and apparently thought through, a small core with optional extensions is a nice approach, there is usable software, there are users. Though the situation with software could have been better.

Desirable features

XEP-0387: XMPP Compliance Suites 2018 lists rather useful and important XEPs; I'd like to focus on some of those, and a few more here:

Message handling acknowledgements
XEP-0198, needed for reliable message delivery.
Client authentication
SASL EXTERNAL authentication mechanism is needed for key-based authentication, which is not an essential feature, but nice and handy.
SCRAM is fine for password-based authentication, and required by the current standard.
Reusability
Many implementations are not easily reusable from common languages, so that's another aspect I'm paying attention to.
End-to-end encryption
OpenPGP (obsolete XEP-0027, deferred XEP-0374), which is commonly used for other purposes, has nice software such as gpg-agent, supported by smart cards, etc. Though it doesn't provide forward secrecy, has a relatively high overhead, and generally not that fancy.
OTR (deferred XEP-0364), which is generic, IM-oriented, and seemingly nice, but has (and leads to) annoying issues, partially caused by nuances of XMPP resource handling by clients. Leads to message loss all too often, with different client combinations.
OMEMO (experimental XEP-0384), which provides forward secrecy like OTR, offline and multi-user messages like OpenPGP, using a relatively new double ratchet algorithm developed for Signal, with some vendor-specific bits in the XEP (and its homepage is just a single page with little information on the Conversations website). The properties are nice, but no standalone specification or white paper in sight, the cryptographic bits are included right into XEP, and apparently there's no reusable library, increasing the risk of screw-ups in client-specific implementations. But there is a handy OMEMO integration tracker. Though it seems that the client incompabilities lead to message loss without user-visible traces at the moment, even after attempts to disable OMEMO; the kind of thing that draws users away from XMPP.

Implementations

Here is a quick summary, based on both descriptions/documentation and source code of the implementations (since rather often it's either not documented, or the documentation is imprecise):

Implementation SCRAM EXTERNAL XEP-0198 C API OMEMO Language
Pidgin/libpurple+-±+third-party pluginC
Prosody+++Lua
jabberd2+--C
bitlbee+---C
weechat/jabber.py--?-C/Python
mcabber/loudmouth---+-C
Conversations++++Java
ChatSecure/XMPPFramework+-++Java
Profanity/libstrophe+--+-C
Psi????C++
Vacuum-IM----C++
pontarius-xmpp+----Haskell
Gajim/nbxmpp+++-+Python
Dino+?++?Vala
gloox-++--C++
Swift/Swiften+++--C++
SleekXMPP/slixmpp+++-?Python

And brief comments:

Prosody
Has community modules, which should be enabled explicitly. Fortunately, it's nicely extensible, and there is plenty of modules.
jabberd2
Implements a very dated version of XEP-0198 (about 10 years old; it didn't even have a "draft" status back then); reported, but it also doesn't seem to be under active development, and has various other issues.
libpurple (Pidgin, bitlbee, etc)
Doesn't focus heavily on XMPP, hence lacks many features. I've got a patch for XEP-0198 merged there, but it'll only be available since version 2.14.0.
bitlbee's own XMPP implementation
Seems to have even more limited SASL support than that of libpurple, and also has issues similar to those of libpurple, caused by its API (which bitlbee reuses for its implementation as well): XMPP streams aren't getting closed properly there either, potentially leading to message loss in conditions where it shouldn't happen.
weechat's jabber.py
Uses an old and abandoned Python library, which implements a now-obsolete RFC even for the core; there are just PLAIN and DIGEST-MD5 authentication mechanisms (SCRAM is required to be available for authentication by the current specification).
mcabber's loudmouth library
Doesn't seem to support client certificates, or XEP-0198, or SCRAM.
Emacs's jabber.el
Uses sasl.el, but that doesn't include EXTERNAL. Also no XEP-0198. And it looks abandoned, too.
Conversations
An Android client in Java which I've checked out of curiosity, does support client certificates and XEP-0198, and many other things. It also has documented observations on implementing XMPP. Though has some warts, such as long if-else-if chains, disconnecting after Integer.MAX_VALUE of stanzas is reached, and apparently more.
ChatSecure's XMPPFramework
Doesn't seem to support SASL EXTERNAL, but supports XEP-0198. But it's just for mobile devices.
Profanity/libstrophe
Both look nice at a glance, but no SASL EXTERNAL mechanism in libstrophe, and XEP-0198 implementation got stuck between libstrophe and Profanity for more than 2 years now.
Psi
A C++ monster, it may or may not be there; quick search reveals very few traces of SASL. Apparently XEP-0198 at least was there at some point.
Vacuum-IM
A smaller C++ monster, with SASLFeatureFactory and such; seems to only support ANONYMOUS, PLAIN, and DIGEST-MD5 (roughly as with weechat), so not even quite a valid XMPP implementation. No XEP-0198 in sight.
pontarius-xmpp
A Haskell client library, but checked it at once: there are just PLAIN, DIGEST-MD5, and SCRAM-SHA-1. No XEP-0198, and apparently it's tricky to add there.
Gajim/nbxmpp
Supports plenty of XEPs, including 0198, and various SASL mechanisms, apparently including EXTERNAL. OTR and OMEMO are available via plugins, and OpenPGP – by default. Pretty good overall, apart from UI (which is actually fine, just not Emacs), and no apparent way to hook it into Emacs. There is a D-Bus interface, though it doesn't include events such as new message receiving.
Dino
I didn't check it closely, but it claims to support XEP-0198, doesn't seem to support OTR, but supports OMEMO, and no SASL EXTERNAL in sight. The UI is rather appalling, with it being based on Electron, but probably it's fine for some users.
gloox
A C++ library without C API (hence not very reusable directly): supports a bunch of XEPs (including 0198), as well as SASL EXTERNAL, but no SCRAM (which is required by the standard).
Swiften
Also a C++ library without C API, claims to be pretty good, seems to support XEP-0198, as well as SASL EXTERNAL and SCRAM-*. Much more of C++ than I'd be comfortable with, and apparently not much of documentation (had to check sources to find out what it supports – as with many client programs, but libraries are expected to provide better docs), but looks good functionality-wise.
SleekXMPP and slixmpp
A Python library and its fork: also not reusable as a library from arbitrary programs, but supports EXTERNAL and SCRAM methods, and many pluggable XEPs.

Improving the software

As it often happens, the existing implementations are imperfect, and their architectures are restrictive, yet there's also too many of them – leading to a lot of effort duplication, and multiple half-baked implementations.

In this situation it doesn't seem wise to make new clients, libraries, or protocols, and perhaps more effort should be put into incremental improvement – which may be hard and boring, but still better than poorly reinventing the wheel.