They built something like XMPP, just a bit different. What they got is more fragmentation in the space of free messaging. None of the justifications they have how their approach is different justifies the costs of additional fragmentation they create.
This is super frustrating, people don't seem to have an understanding what the costs of incompatibilities are. You can also observe pretty much the same at the micro level of within XMPP and encryption standards, where everyone seems to think the solution is yet another encryption standard instead of having just one.
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". With this mentality, nothing would evolve and we'd be stuck on svn rather than git...
To reiterate once again, the things which Matrix tries to do differently to XMPP include:
* Be a replicated conversation database for realtime conversations, more like usenet (NNTP) if anything than IRC or XMPP or SMTP (or, alternatively, an open standard alternative to Slack, which is also focused all around syncing conversation rather than passing messages).
* All conversations are group conversations. There are no such thing as 1:1s; just a room with 2 people in it.
* To be clear: there are no APIs to send a message from one user to another in Matrix. Instead, you sync a message to a room, which updates its conversation history, and the history update is then synced to all the other servers (and users) in the room.
* Have a single monolithic versioned protocol (https://matrix.org/docs/spec) rather than a finely granular cloud of XEPs which may or may not be compatible or best practices or implemented at any given point.
* Build in E2E encryption from the outset.
* Implementation before formalising spec
* A "there is not more than one way to do it" mentality on developing the spec (i.e. a python rather than a perl approach)
Meanwhile, we have spent a lot of time writing decent bridges to ensure that we do not fragment communication with chat systems - be they open or closed. For instance, right now, I see 41 people participating in Matrix HQ from XMPP, ~200 from IRC, ~40 from discord, ~20 from telegram, 5 from slack, and the rest (~3000, including idlers) from elsewhere in Matrix.
> 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.
> 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 used to be a big fan of XMPP, but I've also come to the conclusion that it failed.
Technically, too long the clients just weren't good enough. First the desktop ones, then the mobile ones. Not losing messages if you were logged in with multiple clients was hard.
Matrix (after waiting a little) now just works. Yes, maybe I just don't have any energy left to fight on this front, but for a huge chunk of people I communicate with it has finally replaced IRC. Finally as in reuniting the people who had stopped and also didn't want Slack or Discord. And never got on the XMPP train.
Now we'd just need more native desktop clients, but so far Riot is good enough for me.
They built something like XMPP, just a bit different. What they got is more fragmentation in the space of free messaging. None of the justifications they have how their approach is different justifies the costs of additional fragmentation they create.
This is super frustrating, people don't seem to have an understanding what the costs of incompatibilities are. You can also observe pretty much the same at the micro level of within XMPP and encryption standards, where everyone seems to think the solution is yet another encryption standard instead of having just one.