A new basis for open, distributed, real-time communication
matrix.org
matrix.org
>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.
* 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!
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)
> 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.
IP-based Ethernet -> not realtime capable (without extensions)
Python (garbage collected language) -> not realtime capable
You can at most claim to achieve soft-realtime. As in "sub-500ms but only most of the time".. o_O
That usage makes no sense in the context of internet messaging for the reasons you describe. For human-to-human messaging, I think they're referring to a property more akin to synchronous (versus asynchronous) messaging, i.e. chat versus email. I speculate that the matrix team thinks this is an acceptable overloading because, as a practical matter, the two concepts have nothing to do with one another.
This of course clashes with the RTOS style use of the word, and we aren't claiming that Matrix has any hard realtime timing guarantees at all, other than the soft realtime behaviour media stacks like WebRTC give you by means of high priority threads.
In retrospect it's a confusing term; we should probably avoid using it :)
disclaimer: use of the word realtime in the Matrix.org blurb is all my fault...
https://confluence.freeswitch.org/display/FREESWITCH/mod_ver...
It uses WebRTC for media and JSON-RPC for signalling. On the server side it is Freeswitch module, so can have access to PSTN calling, VOIP and other signaling protocol.
I love your goal, but I really can't see why you can't use SIP to communicate and play nice with other endpoints out there. Surely that would be an advantage.
Problems with SIP:
* There are so multiple SIP standards (e.g. rfc 3261 vs rfc 2543)
* It doesn't support NAT (unless you do rfc5626, rfc5627 and ICE)
* Its support for ICE doesn't work well with webrtc which dynamically generates candidates
* SIP's reliability is bad unless you implement rfc3262
* We want to do messaging really well - and SIP's support for that is rather basic
edit: finally, I do agree with your "yet another standard" comment! (as per the xkcd in http://matrix.org/blog/2014/09/03/hello-world/)
Given that XMPP hasn't taken off as it could have done - and the fact that each large IM or VoIP application seems to end up writing their own version (and putting that in their own walled garden) - we think a new, well-defined open standard, together with open source reference server and client codebases can be the catalyst to create an interoperable and federated "message transport" solution for a multitude of services!
In terms of "jesus, not another protocol I have to support" - I completely sympathise, hence quoting http://xkcd.com/927/ in my blog post... We didn't do this lightly :)
One way of thinking of this is that right now you have LOADS of HTTP APIs out there for messaging - Twitter, FB, http://api.ihackernews.com, Reddit... they're sufficiently easy to implement that every new site goes and builds a new one, and developers have to go and learn each new one every time. Meanwhile, none of them will ever federate or interoperate - the whole thing's totally fragmented.
So whilst Matrix is indeed yet another API to support - hopefully it's one that might actually help solve this problem... so that the next time that someone wants to add a messaging HTTP API to their site, they can follow an interoperable pattern rather than reinvent the wheel again. Perhaps a better way of describing Matrix is "two-way RSS for arbitrary data, with distributed history"
Does this help justify things at all? (Disclaimer: Matrix is all my fault)
Question: Are you looking to expand beyond IM and VoIP, or do you see those as the main areas where the protocol will function?
I'd say IM and VoIP would be the obvious common cases, but Matrix can and will be used to solve all kinds of problems!
P2P protocols are distributed but not all distributed protocols are P2P.
this is already available! if you click on a user and start a one-to-one conversation, there's a handy "Voice Call" button - try it in chrome!
Overall, it makes the impression on me like it was designed by someone who doesn't know much more than how to build web apps and therefore is afraid of anything not HTTP, and so will use HTTP no matter what, even if there are essentially only disadvantages compared to pretty much any alternative you could come up with.
(Oh, and also, they claim being "RESTful", without being anything like that ...)
The "simplicity" of HTTP I mentioned in the Matrix blurb refers to the fact that RFC2616 is relatively compact and self-contained, whereas SIP/SIMPLE/MSRP involves a huge number of RFCs, different protocols (SIP,SDP,MSRP...) and really is a lot more complicated to implement than just doing GETs and PUTs.
Now, the irony is that rather than being "designed by someone who doesn't know much more than how to build web apps" - it's more the other way round. Our experience is mainly with SIP/RTP/STUN/ICE/TURN etc; genuinely RESTful APIs are relatively new territory for us.
I would genuinely love to know what aspects of the Matrix client-server (or server-server) API is 'not anything like RESTful' - it's not too late for us to change the APIs (they've already been rewritten several times, oscillating between more or less RESTful purity), and half the point of releasing Matrix in its current early proto-form is to get detailed feedback from folks on whether we've Got It All Wrong :)
(disclaimer: Matrix is all my fault)
As for the huge number of RFCs: Well, those do cover a whole lot more than passing blobs around? That aspect is fully covered by the SIP RFC, and only a relatively small part of it, the rest is concerned with session establishment and teardown, which HTTP obviously isn't concerned with at all.
Which is why I am wondering: What is the point of using HTTP? What is the functionality that it provides you with that would justify requiring an HTTP stack in every endpoint, including the security risk from all that complexity?
As for RESTfulness: REST is in conflict with a fixed URI scheme, REST allows only for a fixed entry point, beyond that, all other relevant URIs should be discoverable from the returned representations. And no, I am not saying, your stuff should be RESTful, I'm just saying that it's not.