Comment by Arathorn | Hacker News Reader

Comment by Arathorn | Hacker News Reader

Parent Full thread

One use of Matrix is defragmenting IM, and it's true that both XMPP and Matrix can be used to power chat systems.

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.

IOW, Matrix is best suited for replacing IRC or Slack, for communication around organized teams/communities or topical conversations with strangers; while Jabber/XMPP is a better Facebook Messenger, WhatsApp, Hangouts or Gadu-Gadu, best for staying in touch with friends and talking in ad-hoc group chats between them.

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.

> Plus, XMPP can be used for great amount of stuff non-IM related, while Matrix seems very focused around its IRC-like use case

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.

Of course you can (ab)use a lot of protocols in various ways, however, XMPP was designed with this extensibility in mind and that's exactly why its basic RFC is so minimal. Heck, even basic instant messaging over XMPP is defined in a separate RFC (RFC 6120 for Core and RFC 6121 for XMPP-IM).

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.

But flexibility is the problem with XMPP in the first place. None of the clients and servers have compatible feature sets.

> 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.

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?

Sorry, my point was perhaps a bit mangled.

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".

So if I understand it correctly the client-to-server API is simple but servers internally build a Git-like structure? Interesting design, I think I'll read the specs for how history is stored.

Precisely. Matrix is a shameless rip-off of Git, but applied to realtime messaging.

Seems we now just have to wait for the next generation that's a rip-off of piul[1] rather than git, and we'll be all set!

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.

[1] https://jneem.github.io/merging/

Reply on news.ycombinator.com