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.
> Have a single monolithic versioned protocol rather than a finely granular cloud of XEPs which may or may not be compatible or best practices or implemented at any given point.
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'd counter and suggest that the super frustrating thing is XMPP zealots saying "oh my god how dare you try to create a different protocol".
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.
When incompatible changes are applied, the namespace used for feature negotiation is usually version-bumped, so implementations can choose to support and negotiate different versions of a given extension whenever that seems sensible.
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").
> We've been evolving it quite rapidly so far, adding modules for the various different use cases out there [...], and I don't see that rate of evolution slowing down any time soon.
> 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"?
> as long as Matrix is at the forefront of usable federated open secure extensible private messaging
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.
Yes, but I think the claim was that a persistent TCP connection has a negative effect on battery life, which is not obvious to me. An idle connection should have no impact whatsoever.
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.