Issues which I've been encountering recently with XMPP are all about TLS and differing threat models. It seems as if LetsEncrypt has been around for ever, but really it has only been usable in the last two or three years. During that time an increasing number of internet applications just assume that TLS authentication is in place.
Before LetsEncrypt XMPP servers typically allowed self-signed TLS certificates or no certificates. Recognition by Certificate Authorities (CAs) wasn't mandatory. But increasingly now it is. This is all fine except in cases where you don't need TLS or where Certificate Authorities are untrusted and belong in the threat model. That's usually the case if you're running XMPP on onion addresses. After all, CAs include numerous dodgy companies and entities like the Chinese government.
So if you're setting up an XMPP server with the intention of using both clearnet and onion addresses then there's a conflict of interests between the two routing worlds. The clearnet would like CA-recognized TLS certificates to always be used. The onionspace would prefer that to be optional or not present.
In the rush to implement TLS everywhere, and thereby secure the internet from the evildoers, minority use cases like onion routing have been forgotten about and there isn't a clear solution if you want to inhabit both worlds.
As a workaround I've added a settings screen for the XMPP app within Freedombone which allows TLS authentication to be strictly enforced or not.
There has been a recent talk about Matrix at FOSDEM 2019 in which it's said:
As of Matrix 1.0, we require homeservers to present a CA-signed TLS certificate
So very much the same problems are going to apply to Matrix on onion addresses quite soon. Probably the version of Matrix on onion-only versions of Freedombone will need to be modified in order to federate, and will be non-compliant with the spec. If that's infeasible then it might be that Matrix on onion will only be non-federating, which would be disappointing.
It looks like Matrix will be ok after all. In the recently published federation API it says:
The TLS certificate provided by the target server must be signed by a known Certificate Authority. Servers are ultimately responsible for determining the trusted Certificate Authorities, however are strongly encouraged to rely on the operating system's judgement. Servers can offer administrators a means to override the trusted authorities list. Servers can additionally skip the certificate validation for a given whitelist of domains or netmasks for the purposes of testing or in networks where verification is done elsewhere, such as with .onion addresses.