Hacker News Reader

Comment by Sarien | Hacker News Reader

I would like to know how this is different from jabber/xmpp and how likely it is that these differences are worthwhile. They say their API is more "pragmatic" and writing a full-blown XMPP client certainly is very tricky but I wonder if improving the way XMPP works wouldn't ultimately create a better result. After all, a lot of thought and experience has by now gone into it.

View on HN

The main issues with XMPP that drove us in this direction were:

* Not particularly web-friendly – you can’t easily speak XMPP from a web browser.

* Single server per MUC is a single point of control and availability

* History synchronisation is very much a second class citizen feature

* Stanzas aren’t framed or reliably delivered (without extensions)

* Multiple device support is limited

* Baseline feature set is so minimal that good user experience cannot be guaranteed

* No strong identity system

* Not particularly well designed for mobile use cases (push; bandwidth-efficient transports)

disclaimer: I'm involved with this project!

I've read through the blog, the comment would have been useful on differentiating Matrix from XMPP. Also, sort of off topic, but Skype has a XMPP bridge and WhatsApp is built on XMPP (they just don't support federation).

Oops - I should have called it out more clearly in the blog.

The biggest difference we have over XMPP is probably that messages in Matrix get synchronised over all the participants of a conversation... so you get distributed chat history for free, and no single points of failure on group chat (as you do with XMPP MUCs). And obviously Matrix is plain HTTP+JSON rather than messing around with XML.

One of the reasons we built Matrix is because, in practice, pretty much all the current big players started off using XMPP for developing their chat solutions: Google Talk was originally XMPP; I believe Facebook Messenger was built out at first on ejabberd; WhatsApp was originally XMPP etc; even APNS was originally XMPP!

But ALL of them have ended up mutating it to a proprietary closed standard - and nobody has even tried open federation other than Google's misadventure with Talk. So, unfortunately, it seems XMPP hasn't ended up being the interoperable web-for-IM that we all hoped.

Now, I have absolutely no idea if Matrix will be more successful in solving the problem; the hope is that by keeping it simple and using HTTP APIs there's more of a chance that players of all sizes will start exposing Matrix APIs for federation. Only time will tell. It's also worth noting that end-to-end encryption is a relatively recent potential obstacle: given iMessage and Telegram etc are all end-to-end encrypted, for them to ever federate with Matrix we'll need to support the same semantics and crypto. Hopefully we're going about this the right way (although end-to-end crypto isn't formally specified or implemented yet), but will be an interesting challenge. And one that XMPP hasn't tried to solve at all, as far as I know.

(disclaimer: Matrix is my fault)

I see your problems are that core XMPP provides very little and you need extensions to actually build something interesting. Which is very true, however we have come to a state where some of them are included by default in any good server or client implementation)

> Not particularly web-friendly – you can’t easily speak XMPP from a web browser.

Is Bosh (http://xmpp.org/extensions/xep-0124.html) not good enough ?

> Single server per MUC is a single point of control and availability

Very true. There has been attempts to federate MUCS (http://xmpp.org/extensions/xep-0289.html) but the problem here is about human roles and who can do what (notwithstanding end-to-end integrity)

> History synchronisation is very much a second class citizen feature

Not yet standard, but everyone is betting on Message Archive Management (http://xmpp.org/extensions/xep-0313.html).

I could cite counterpoints for every one of your points but that's not interesting. The real issues I see with XMPP are:

* No efficient support for binary -- The official way to do it is to setup another transport with Jingle. Which is sad because a transport was already setup, and now we need another one...

* Because of previous point, any potential cryptography will waste a lot of space

* No framing (a point you cited), which is absurd considering that XMPP is a routing protocol

* XML is a non-joy to work with (Note: JSON would not be a complete solution, see previous points)

Even though it has deficiencies, I'm still betting (and working) on it. What we really lack is software, and tools built on a protocol, not a new protocol.

http://matrix.org/blog/2014/09/03/hello-world/

http://matrix.org/docs/spec

http://matrix.org/docs/howtos

http://matrix.org/docs/api

Lots of drama here.

>I would like to know how this is different from jabber/xmpp and how likely it is that these differences are worthwhile.

I thought the question was fairly content free, and something that someone would be able to answer themselves if they had enough knowledge of XMPP to actually care, and 10 minutes to read the announcement blog.

>I wonder if improving the way XMPP works wouldn't ultimately create a better result. After all, a lot of thought and experience has by now gone into it.

A vague objection and a truism. Sorry if you felt bullied or something.

Reply on news.ycombinator.com