Indeed. Could you also provide the number of 1:1 chats and private groupchats running on freenode, then? Both of these are way more popular use cases for XMPP than public rooms.

If it isn't, why are there so many red crosses on https://matrix.org/docs/projects/clients-matrix and so many servers that aren't even capable of talking to matrix.org?

I totally get where you came from, the fragmentation within the XMPP universe is annoying. The problem is that a monolithic spec doesn't solve this issue at all. It's not like code magically updates itself when you update a monolithic spec. The problem is missing manpower on the implementation side, and ditching modularity from the spec just makes it harder to cope with this in graceful ways.

I see no such consensus within the XMPP community, but yes personally I agree with those zealots. My interest in federation is making it possible to communicate with anyone just like I can call anyone by phone. Inventing an incompatible protocol obviously won't help with this goal, even if you ignore the issue of splitting up scarce manpower and assume bridges can act as a partial workaround (at least for geeks who can cope with their limitations).

> With this mentality, nothing would evolve and we'd be stuck on svn rather than git...

Comparing XMPP to SVN and Matrix to Git just reads like trolling to me. The obvious difference is that XMPP is highly extensible while SVN is not at all. So the discussion is not about whether or not to evolve, the question is whether evolving federated IM required starting from scratch, i.e. whether the advantages are worth the resulting fragmentation. And I just fail to see the problem in using/extending the XMPP spec to replicate your DAG.

Not sure this works as well elsewhere (e.g. the Matrix spec just states that it's "still evolving: the APIs are not yet frozen and this document is in places a work in progress or stale").

If you happen to remember specific things you were missing on https://docs.ejabberd.im/ we'd be happy to hear about them:

https://github.com/processone/docs.ejabberd.im/issues/new

> And even if we did go and entirely rearchitect Matrix (e.g. making it entirely P2P, which is certainly a thought experiment we keep in mind), one would just go bridge it into the existing Matrix ecosystem and migrate as desired.

Are you saying you might end up in a situation where "fragmentation of features between clients and servers is common"?

You say this as if the truth of this statement was obvious to everyone.

> free software developer hours are precious and wasting them are two different implementations of the same thing (much like Tox vs Ring for secret messaging) wastes a ton of effort that could be better spent making one of the two excellent rather than having two working solutions nobody uses.

That's precisely the reason I work on ejabberd/XMPP rather than just throwing everything away and starting from scratch.

FWIW, somebody is working on an ejabberd module [1], and there's some discussion [2] on the mailing list.

(And ejabberd's community edition supports the XEPs that are relevant to mobile clients too, BTW.)

[1] - https://github.com/royneary/mod_push [2] - http://mail.jabber.org/pipermail/standards/2015-March/thread...