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'm not sure that the problem is missing manpower on the implementation side - it's more that it's hard to know as a developer which current blend of XEPs is the recommended combination and which might have the most chance of working between a given client & server (and server & client) combo.
Things like the XMPP compliance suite XEPs have helped a bit with this, but looking at the XEP list and trying to work out which XEPs you should be using on a given day is still daunting - as well as trying to track which clients are most likely to be supporting them.
The idea on Matrix is that you say "Hi, I talk Matrix CS API 0.4" and be done with it - and you end up with much more social pressure to keep up to date with the current latest spec, because otherwise you are simply falling behind (rather than happening to chose not to implement some XEPs).
It boils down to a question of governance & social dynamics rather than anything related to writing code (magically or otherwise).
Because the world is littered with unfinished projects? The key thing being that the authors KNOW very concretely that the project is unfinished, and there is a big red X next to the feature in question.
> so many servers that aren't even capable of talking to matrix.org?
Because we only released the first stable release of our federation API a month ago?
> 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").
> WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
It means that there will be one client that supports this (Conversations for Android) and maybe one server supporting this (probably ejabberd). Good luck navigating the minefield :)
Meanwhile I can install Slack on multiple devices and have the same functionality everywhere :)
> 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.
Because TCP connections are expensive on your battery life. Especially if your network is flaky, and all those connections need to constantly repeat their handshakes.
Not really, TCP connections are how GCM does things even. Unless you're using keep alives or otherwise preventing sleep, I believe these devices are capable of sending an interrupt when there's activity on a network connection though I could be mistaken.
And on a data connectivity change, e.g. GSM <-> WiFi switch, there is a good chance that a dozen other components start trying to re-establish their connections, which means the radio is awake anyway (for, usually, at most a few seconds).
> Idle TCP connections do not consume any battery.
An idle connection doesn't consume anything, but a useful idle connection will have some keepalive every X minutes. Multiply that by the number of connections your application will have and by the number of background application you run on your phone, and the radio will never truly sleep or enter the "low" mode. The solution wanted by Google and Apple is to maintain a single connection to their server on which every push is aggregated and sent, and that the OS itself manages.
I use my mobile XMPP connections without a TCP keepalive but send a server ping if there has been stanzas received in the last 30 minutes and get a useful and reliable XMPP connection without a noticeable impact on battery. If you use Android's AlarmManager to trigger the check, then Android will even take care of scheduling the "alarm" with other alarms for efficiency.
> Multiply that by the number of connections your application will have and by the number of background application you run on your phone, and the radio will never truly sleep or enter the "low" mode.
Why would X x Y idle connections (X: TCP connections per app, Y: applictions) prevent your radio from sleeping?
> Why would X x Y idle connections (X: TCP connections per app, Y: applictions) prevent your radio from sleeping?
In the worst case, if the pings aren't sent at the same moment and all applications have a timeout set to, let's say, 30 minutes, your phone will send a ping every 30/(X*Y) minutes. I don't know what the usual X and Y would be, but if they're high enough your radio will always be up (check out these slides, 23 in particular: https://www.igvita.com/slides/2013/io-radio-performance.pdf)
And that's only counting idle applications. If you have one that periodically polls a server, it gets even worse.
Course, you shouldn't poll and if those mechanisms aren't coordinated, then you you will suffer. But that's why Android provides the AlarmManager API and I would expect other mobile platforms to provide something similar.
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.