>Bridging to other protocols and defragmenting existing communication apps and networks is very much a second class citizen feature

Not sure what this means. XMPP gateways have been around forever, tend to actually work and are completely standardized with a specification and everything. The reason you don't hear more about them is because there is nothing much to gateway to any more. All the other IM systems have managed to close off their gardens to such an extent that gateways are pointless...

I guess that raises an obvious question. Is there an XMPP gateway to Matrix? I know there are some projects that are about gatewaying from Matrix to XMPP. One potential complication is that Matrix isn't an IM network as such, it is more of a IRC like distributed conference. There is a XMPP to IRC gateway, so it must be possible at some level...

It does exist, via libpurple. I think it was one of the first bridges. It is not currently maintained, AFAICT due to lack of general interest. Telegram, IRC, discord, slack, gitter etc. bridges are actively maintained, for comparison.

I was not aware that libpurple supported Matrix but there is a plugin:

* https://github.com/matrix-org/purple-matrix

... which in theory would work with:

* https://spectrum.im/

... running in XMPP gateway/transport mode...

thank you

on xmpp clients: "Baseline feature set is so minimal that fragmentation of features between clients and servers is common, especially as interoperability profiles for features have fallen behind (as of July 2015)"

they are spot on in this one.

Indeed, there are a large number of people still using Jabber/XMPP today with "popular" clients like Pidgin or Adium that haven't stayed up to date with modern advancements in messaging.

It leads many people to believe that XMPP is incapable of many of the features that are considered normal in modern messaging applications.

A hard break in the protocol would solve it (i.e. so old clients would no longer be able to communicate with new clients), but it would also frustrate and fragment the significant existing userbase. Given that open decentralized standards-based networks are something to be treasured if we're to stem the tide of proprietary walled-garden messengers, that option would potentially be shooting the open movement in the foot.

EDIT: typo

The really great thing about XMPP is that basic messaging always works and is super simple to implement. Anything that changed that would be very bad.

We've seen hard breaks before: ssh 1 vs 2 - and we're seing it now with http2. The latter is really crazy, but seem to be actually working.

...and outdated, as it's 2018 now and XEP-0387 exists.

Actually, most of this FAQ is severely outdated, XMPP already catched-up in most of these points. Some clients are lagging, sure, but that's just a matter of time for Matrix to suffer from the same issue.

Is there an up to date wiki/guide of a subset of features and implementations that go well together for modern xmpp?

As in these mobile clients for ios and Android, these for desktop and these for cli. With these servers - Together give you in-band registration, ssl-only client/server and server/server, maybe audio/video, file-sharing, server-side history - e2e encryption (I'd settle for otr) - and sane defaults for each client and server to make it difficult to accidentally disable encryption or certificate validation?

Honest question - last time I looked I couldn't find a simple&secure, recommend setup for xmpp.

A thing I often see is people pointing to specifications and saying "look it's all fixed".

But you can't chat using a piece of digital paper. What matters not is what the protocol can theoretically do, but the experience you can have if you open a client right now.

That point that needed "fixing" was specifically about lack of specification... plus there are multiple clients and servers already implementing this spec.