Plus, XMPP can be used for great amount of stuff non-IM related, while Matrix seems very focused around its IRC-like use case, where XMPP doesn't really improve much over IRC.
I don't really agree here. While Riot is focused on a IM use of Matrix, Matrix itself is open enough to be usable in any use case requiring a payload to travel from A to B. You could think of Matrix use in IoT, social networks, forums, etc. Some people even made a working PoC of a blog using Matrix, and I heard some others are also working on building a system to bypass information censorship using Matrix as its only back-end.
I don't know XMPP enough to state which spec is wider than the other, but what I know is that Matrix isn't limited by what Riot or other Matrix-based IM clients can do.
GP already stressed it out:
> Matrix's main data primitive is synchronising conversation history within a room - not message passing.
So Matrix might be well suited for things like blogs, but XMPP will be certainly better for push notifications, for instance. However, you can easily build Matrix-like primitives on top of XMPP, while the other way around will be less flexible.
I've read in a different thread that sending a message in Matrix can be easily achieved with a simple curl. Is it true? Synchronizing my copy of room state doesn't sound so simple. Maybe it's optional or I misunderstood the "message via curl" post?
If you want to send someone a message in Matrix it's indeed a trivial HTTP PUT; something like:
curl -XPOST -d '{"msgtype":"m.text", "body":"hello"}' 'https://example.com/_matrix/client/api/r0/rooms/!CvcvRuDYDzT...
However, what's happening under the hood is that you're not saying "Hi Bob, here's a message from Alice" - instead, you're saying "Hi everyone, I've added a message to the history of this room. Please can everyone sync their copy of the room with mine?". In other words, it's talking about the way the federation (server<->server) protocol is architected.
There literally isn't a way in the federation protocol to say "please send a message from Alice to Bob"; instead the way you do it is to say "create a room and invite Bob to it (if you don't have one already); add a message to the room's history, and once the history has synchronised with Bob's server he'll have a copy of the message too".
On a more serious note, this seems to be a trend; to model chat as a converging set of edits. From an architectural pov it sounds similar to Google wave and lotus notes.
However, architecturally they really couldn't be more different:
* Matrix's main data primitive is synchronising conversation history within a room - not message passing. In fact, there is no way to just 'send a user a message' in Matrix: instead, you can only synchronise your copy of a room's state and history with someone else's copy of it.
* Matrix rooms are replicated equally over all participating servers - there is no focal point as there is in a XMPP MUC.
* Matrix provides a single monolithic (beta) spec, which compliant clients have to implement (for a given class of clients). There are no optional features or competing extension proposals for a given feature for a given class of client (e.g. 'desktop messenger'), to try to avoid fragmentation.
* Matrix's baseline transport and encoding is super-simple-stupid HTTP+JSON, but with room for folks to propose superior transports & encodings as we see fit. So far there's been WS+JSON (which nobody seems to use, as it's not that massive an improvement over HTTP+JSON), and this year there's a GSoC project to look at MQTT-and-similar as an alternative.