Matrix: a new specification for federated realtime chat

By Nathan Willis
February 11, 2015

The free-software community has frequently advocated the development of new decentralized, federated network services—for example, promoting XMPP as an alternative to AOL Instant Messenger, StatusNet as an alternative to Twitter, or Diaspora as an alternative to Facebook. The recently launched Matrix project takes on a different service: IRC-like multi-user chat. If the thought of replacing IRC sounds like a strange goal for a new project, though, Matrix is extensible, and the developers have already added support for one-to-one audio and video calling. Though it is still in development, Matrix is simple enough that one can already get a feel for how it works.

Matrix was launched in mid-2014, with most of the developers coming from the enterprise software firms Amdocs and OpenMarket. The Matrix site hosts the main specification as well as a description of the client-to-server API. There is also a server-to-server API which, so far, has not been published on its own (although it is referred to in the Matrix specification). At GitHub, the project maintains repositories for a reference Matrix server called synapse and for Android and iOS client libraries.

The synapse repository also includes two demo clients: one that runs as a web application, and one command-line client written in Python. The most recent release is version 0.6.1f, from February 10. Interested users can test out the system by connecting to the Matrix demo server through the web client at https://matrix.org/beta/ or through the IRC gateway at irc://irc.freenode.net/matrix.

Matrix basics

The Matrix system allows individual users to join persistent realtime chat rooms (hence the comparison to IRC and its channels). But the messages posted in any particular room are continuously synchronized between every participating Matrix server, thus protecting against the single-point-of-failure problem well known to IRC users. Whenever a new server connects a room—which it would only do when a user attempts to join that room—the other participating servers propagate the room's history to the new server, so that all servers eventually reach a consistent state, and all users have access to the full message history.

Matrix rooms feature management functions similar to those found in IRC, such as inviting, kicking, and banning room members. While the general-purpose Matrix message format is text, the protocol also supports presence (so that users can advertise "here" or "away" status as desired) and public user profiles. It can also be extended to support other message types. As published, it already supports emoticon messages, geolocation references, and file attachments.

Rooms can have user-friendly names, like #help:example.org, that are similar to IRC channel names. But those user-friendly names are actually aliases: under the hood, the real room identifier is a randomly-generated string. All that matters to someone wishing to join the room is that the server running at example.org maintains the current mapping between the alias and the room identifier. Furthermore, the real room identifier could change over time—rooms persist even if the alias becomes unavailable (such as the original server going offline).

The purpose of separating room identifiers and user-friendly aliases is two-fold. First, the domain component of the alias identifies the server that is advertising the alias-to-room mapping; this is intended to provide a globally unique namespace—as long as two users on example.org do not both try to start #help rooms, it does not matter that there may be other, disjoint #help rooms originating somewhere else. Second, users that want to connect to a persistent room need only remember the alias to join—if the original server is restarted, the room identifier might change, but the alias can remain the same.

User identities use a syntax much like room identifiers; the format is @username:example.com. Interestingly enough, the specification also advertises a way for users to publicly link a Matrix user ID to a "third-party identifier" (3PID), such as an email address or phone number. To do this, the Matrix network would support a global, federated network of identity servers that maintains the links between accounts and 3PIDs. The goal would seem to be making it simpler to invite another user to join a chat. Unfortunately, the relevant section of the Matrix specification is still empty (marked with "This section is a work in progress.").

In addition to its more IRC-like facets, Matrix also includes some features geared towards one-to-one communication. Users can send invitation messages to other users, and the basic Matrix protocol supports extensions for WebRTC audio and video. Together, those functions allow Matrix to provide a VoIP-like service. Users can also create a chat room and invite others to it without advertising it via a public alias; that functionality more closely resembles traditional instant messaging.

There are also some interesting features to the Matrix system without a clear analogue to other network services. For example, each user connects by signing in from their client application to the Matrix server where they have an account. But the chat room is a server-to-server construct. Users can log on to their server with more than one client simultaneously (e.g., a desktop machine and a mobile device), and the other servers participating in the room never need to know. The synapse reference server provides this feature. With IRC or IM, each client application connects directly to the central server, and logging in from two locations creates a variety of problems.

Networks and security

One of the more fundamental questions a new project like Matrix must answer is why an entirely new protocol is required to do what the new system does—after all, XMPP, SIP, and IRC are all well-established at this point. The Matrix project's answer consists of several pieces. First, there is the general rationale for decentralized and federated services. No central server is required to connect two users, anyone can run their own server, and users with accounts on different servers can interact easily.

Second, the project has its own list of shortcomings with IRC, XMPP, and the like. Some of these are well-known—like IRC's limitation to text-only messages and the inability of users to simultaneously connect to an IRC channel from more than one device. Others are a little more subjective, such as the claim that XMPP has "no strong identity system".

Third, and perhaps the most difficult to quantify, Matrix is designed to be friendly to web implementations—and, in fact, builds heavily on web underpinnings. Client-server and server-server connections are made with HTTP on top of TLS. All of the messages (client-server and server-server) are in JSON and are exchanged with RESTful requests.

Speaking of TLS, the security model of Matrix is one area in which the project has several surprises in store. For starters, end-to-end encryption is not built in. The traffic on the wire is protected by TLS, but that does not prevent unwanted users from joining what is meant to be a private discussion room. Users who wish to restrict access to a room must rely on Matrix's room-management API: room moderators can kick out users or ban them (by user ID), but little else. Furthermore, although TLS encrypts the messages between servers, the servers themselves have access to the message content. Several spots in the specification and on the Matrix site as a whole make reference to optional end-to-end encryption (where only the users could decrypt the contents of messages), but this appears to be another unfinished component at present.

That said, Matrix does allow for room moderators to "redact" old messages. A m.room.redaction event permanently removes the content of a message, but it leaves the message's event ID and other generic metadata fields in place; that allows other servers in the room to similarly strip out the (presumably offensive) contents without causing problems for the synchronization algorithm.

The final piece of the Matrix puzzle is identity management. Server-to-server Matrix messages are authenticated (in addition to TLS) using public-key signatures in the HTTP Authorization header that accompanies the message. When establishing a new connection, each Matrix server can retrieve the both the TLS certificate and the signing key of its peer server from the well-known location http://foo.com/_matrix/key/v1. Thus, the system places trust in the usual TLS certificate-authority system to verify the identity of a server.

Authenticating the identity of a remote user in a chat room is a different matter. Here again, the Matrix specification is essentially blank, and all that can be gathered about the scheme that the project has in mind are bits and pieces referred to elsewhere. The synapse repository includes a brief description on its landing page, noting that:

the role of managing trusted identity in the Matrix ecosystem is farmed out to a cluster of known trusted ecosystem partners, who run 'Matrix Identity Servers' such as sydent, whose role is purely to authenticate and track 3PID logins and publish end-user public keys.

The sydent server referenced is another GitHub repository, albeit one that has not been touched in five months. But there is slightly more detail if one is willing to dig. The authenticity of any user account is the purview of the Matrix server where the account resides. An Identity Server can only verify that a given Matrix ID has been asserted to go with a particular email address (or other 3PID), and that the assertion came from the correct Matrix server. In short: the trust eventually falls back to the Matrix server anyway.

But perhaps that is good enough; after all, one of the main purposes of designing a federated network like Matrix is that anyone has the freedom to set up a server and start some conversations. Much like one cannot automatically trust the validity of an unknown email address, other (non-technical) means will be required to determine whether or not a Matrix user is who they claim to be. It will be far more interesting, from a security standpoint, when Matrix's identity-management model is fleshed out to support things like end-to-end encryption and public-key cryptography.

Whether or not Matrix takes off as a realtime chat protocol will be interesting to watch. It is certainly true that IRC, despite all of its limitations, has resisted numerous challenges from up-and-coming communication schemes. But Matrix may have a key factor working in its favor: no reliance on a centralized server to coordinate conversations. In some circles, certainly, that is a long-requested feature.

to post comments

Matrix: a new specification for federated realtime chat

Posted Feb 11, 2015 22:45 UTC (Wed) by nowster (subscriber, #67) [Link] (1 responses)

Sounds like someone's reinvented the "inkblot" store-and-forward message propagation service, as used by Usenet News and FidoNet Echomail.

The idea of a "cancel" channel/group is familiar territory too.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 12:28 UTC (Thu) by Arathorn (guest, #101018) [Link]

The main algorithmic difference with Inkblot is that Matrix's federated message history is all cryptographically signed by the originating server (to avoid tampering over open federation), and is built on a replicated directed acyclic graph datastructure to provide eventual consistency semantics and elegantly handle netsplits, data loss, etc. It's obviously intended for realtime messaging, whereas NNTP isn't exactly up to the job of IM or VoIP signalling. And Matrix syncs arbitrary JSON rather than MIME envelopes. It's true that Matrix is slightly inspired by NNTP (as well as IRC, IMAP, eventually consistent DBs, etc). (I'm the tech lead on Matrix, fwiw).

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 1:16 UTC (Thu) by wahern (subscriber, #37304) [Link] (28 responses)

But Matrix may have a key factor working in its favor: no reliance on a centralized server to coordinate conversations. In some circles, certainly, that is a long-requested feature.

But XMPP has that going for it as well. XMPP is even better: Matrix relies on a centralized authority to tie a 3PID (third-party identifier, such as your e-mail address) to your Matrix ID. By contrast, your XMPP handle is almost always your e-mail address, and the only centralized authority involved is DNS.

Otherwise, Matrix works much like XMPP; they're even using DNS SRV records like XMPP. Almost everything works just like XMPP, except with JSON instead of XML and HTTP instead of a regular TCP stream. And MUC is built-in rather than bolted on.

The only novel thing seems to be the idea of a tree of events. I can imagine all kinds of cool things to do with that, including building services like Slack.com, with rich white-boarding features and archiving.

Other than XMPP, Matrix reminds me a little of Cobalt (previously Croquet). Now that is a cool project with very interesting underlying algorithms. Particularly TeaTime, a distributed, transactional, P2P messaging protocol.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 3:53 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (25 responses)

Matrix is nothing like XMPP.

XMPP is a braindead protocol that is now transitioning into a simply 'dead' state. It's made around a concept of permanent "associations" between the endpoints (so a server can store messages while endpoints are offline) and while it has some support for federation, it really works only for simple 1-to-1 messages.

Group chats were a feature bolted-on later, and was supported exceedingly poorly (some clients never really got it).

But the worst shortcoming was the message persistence (or a lack thereof). XMPP has no notion of archiving and message history synchronization. As of 2012 no major XMPP clients implemented it properly, some _servers_ (like Spark) had special server-side support for message storage accessible through their custom web-interface.

Well, also there's the fact that XMPP is built on a totally awesome idea of protocol built on top of an endless stream of XML stanzas. HTTP tunneling was added only very late in the game (and not universally supported either).

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 4:46 UTC (Thu) by pizza (subscriber, #46) [Link] (19 responses)

> XMPP is a braindead protocol that is now transitioning into a simply 'dead' state.

Yet it remains the *only* option there is if you want an IM solution that doesn't require you to sign your soul (and your messages) over to $BigCorp.

> It's made around a concept of permanent "associations" between the endpoints (so a server can store messages while endpoints are offline)

Those associations also act as a whitelist so you aren't massively spammed all the time.

> and while it has some support for federation, it really works only for simple 1-to-1 messages.

Federation was one of the core design principles of XMPP, so I'm not sure where you get this "some support" thing. Or what it has to do (or not) with "1-1 messages".

> Group chats were a feature bolted-on later, and was supported exceedingly poorly (some clients never really got it).

Yes, group chats were added later. And I suggest you blame said clients for their poor support; many others have no problems whatsoever.

> But the worst shortcoming was the message persistence (or a lack thereof). XMPP has no notion of archiving and message history synchronization.

Server-side archiving (and history synchronization) was standardized many years ago. There are multiple implementations, both on client and servers.

> Well, also there's the fact that XMPP is built on a totally awesome idea of protocol built on top of an endless stream of XML stanza

That's the first defensible criticism of XMPP you've made; the rest should be laid at the feet of the implementors (keeping in mind that there's no "XMPP Czar" enforcing feature compliance) In particular, I'd like to single out Google for effectively pulling an IE6 on the XMPP ecosystem. They didn't even properly implement the stuff they themselves specified (Hello, Jingle..) which made it nearly impossible for folks to properly interoperate properly.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 5:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

> Yet it remains the *only* option there is if you want an IM solution that doesn't require you to sign your soul (and your messages) over to $BigCorp.
"It's better than nothing" is a very weak argument, especially since it's now competing with Slack and other similar implementations.

> Those associations also act as a whitelist so you aren't massively spammed all the time.
Sure. But it's not relevant for lots of users, and in any case it should be an optional feature.

>> and while it has some support for federation, it really works only for simple 1-to-1 messages.
> Federation was one of the core design principles of XMPP, so I'm not sure where you get this "some support" thing. Or what it has to do (or not) with "1-1 messages".
Try this:
1) Create a group chat with users from several federated servers.
2) Disconnect the servers.
3) Change each group chat replica (add new users, remove users, stuff like that)
4) Reconnect the servers.
5) Watch the hilarity that will shortly ensue.

> Server-side archiving (and history synchronization) was standardized many years ago. There are multiple implementations, both on client and servers.
Nope. The original XEP-0136 has lots of inadequacies and is difficult to implement. Most of clients and servers simply don't support it: http://en.wikipedia.org/wiki/Comparison_of_XMPP_server_so... .

There's a newer http://xmpp.org/extensions/xep-0313.html which looks a little bit better but it's still a draft.

>> Well, also there's the fact that XMPP is built on a totally awesome idea of protocol built on top of an endless stream of XML stanza
> That's the first defensible criticism of XMPP you've made;
That's actually my least concern. The network layer in XMPP is crazy, but writing a parser for it doesn't take that much time.

> the rest should be laid at the feet of the implementors (keeping in mind that there's no "XMPP Czar" enforcing feature compliance) In particular, I'd like to single out Google for effectively pulling an IE6 on the XMPP ecosystem.
Yep, so the ecosystem rapidly fragmented to the point that you can't depend on ANY feature being present. It's beyond ridiculous. And I can't really blame Google - they tried hard enough to make it work.

That's why a redesign of the protocol which is built on an idea of real distributed workflow is in order.

PS: yes, my company tried to use XMPP for several mission-critical applications and we got horribly scarred as a result.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 13:40 UTC (Thu) by pizza (subscriber, #46) [Link] (14 responses)

> Yep, so the ecosystem rapidly fragmented to the point that you can't depend on ANY feature being present. It's beyond ridiculous. And I can't really blame Google - they tried hard enough to mke it work.

No.. Google didn't try all that hard in the end, and they were one of the main reasons why it didn't work. They implemented what they cared about, didn't care when others complained about Google's not-quite-spec-compliance. This was aptly demonstrated with the Jingle fiasco; Google released a reference implementation (libjingle) that differed behaviorally from what their own clients used, and never actually fixed their clients (or libjingle) to line up. They they
basically sat on that feature set (ala IE6) for many years until they basically threw Gtalk/XMPP under the bus with their "Everything is now Google+, oh, and f*ck interoperability and federation" announcement in May 2013. Even before that point it was pretty hard meaningfully innovate or improve the XMPP ecosystem as a whole when everyone else had to be bug-for-bug compatible with Google/Gtalk.

The other reason XMPP failed, and any alternatives are also doom to fail, is the old spectre of network effects and the fact that it's mostly impossible to monetize via advertising (not unlike RSS) so the big boys have no incentive to support it, much less actually help improve the standards.

So, as a result, federated XMPP's userbase is a rounding error compared to the likes of Hangouts, AIM, Whatsapp, FB Messenger, Skype, and so forth. It's only advantage at this point is its network effect, and new entrants won't even have that. I just don't see any new F/OSS entrants having the resources to buy enough mindshare/marketshare to make a greenfield design worth the effort.

Google Reader _was_ monetized

Posted Feb 12, 2015 14:50 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (2 responses)

"it's mostly impossible to monetize via advertising (not unlike RSS)"

Google Reader /was/ monetized. A key step to getting rid of Reader was to put engineering time into removing the advertising from Reader, so that its contribution to Google's bottom line would vanish and its termination could be justified as a necessary belt-tightening exercise.

We often read nonsense on LWN about how public corporations are "obliged" to do whatever makes the most profit. Google is an unusual case, but they make it clear how untrue that is. The way to make money was to kill off the me-too social network and keep Reader. But that did not suit the people who actually make the decisions, so that's not what happened. Shareholders can yell and scream and stamp their feet, but they never use their power to actually do anything, so they're irrelevant.

The biggest system-wide scandal is the paying of high salaries or even bonuses to directors who are ineffective. Shareholders are very angry about that. How angry? Well, not angry enough to actually vote those directors out and replace them. So everything continues as before.

Google Reader _was_ monetized

Posted Feb 12, 2015 18:35 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> Google Reader /was/ monetized. A key step to getting rid of Reader was to put engineering time into removing the advertising from Reader, so that its contribution to Google's bottom line would vanish and its termination could be justified as a necessary belt-tightening exercise.

I wasn't referring to Google Reader; I was referring to those entities that provide, or used to provide, RSS feeds. Monetizing the feed reader is a lot easier than monetizing the feeds themselves.

Google Reader _was_ monetized

Posted Feb 24, 2015 12:36 UTC (Tue) by nye (subscriber, #51576) [Link]

>I wasn't referring to Google Reader; I was referring to those entities that provide, or used to provide, RSS feeds. Monetizing the feed reader is a lot easier than monetizing the feeds themselves.

Why would it be harder to monetise RSS than a web page? Many of the RSS feeds I read have ads at the top just as they do on their website. What's the difference?

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 15:01 UTC (Thu) by Arathorn (guest, #101018) [Link]

We're not really not targeting the current encumbents (WhatsApp, FB, Skype etc) with Matrix (although if they want to federate up, hooray!) - but instead trying to provide a signalling layer for the next wave of chat apps, and indeed a federated layer between all the new WebRTC services which are popping up, which currently can't interoperate at all. In terms of how to monetise it: well, you can certainly sell value-added services on top of Matrix (e.g. PSTN connectivity; high-SLA hosting; translation services; voice->text transcription; etc) if you so desired. It's not all about advertising.

So hopefully there's still room for another open standard in this space :)

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 18:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

It was a little bit different. Libjingle actually worked fine with Google Talk's XMPP implementation, we used it in-house and actually ported its signaling layer to support SIP.

However, none of the major OpenSource projects were interested in adding Jingle - it simply sat there gathering dust for _years_ after Google spent literally millions to make it work. Do you remember the 3-line-text-field Pidgin fiasco? I've heard rumors that this was the trigger for Google to abandon XMPP internally.

And I can't really blame Google here.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 23:21 UTC (Thu) by jlargentaye (subscriber, #75206) [Link] (7 responses)

> Do you remember the 3-line-text-field Pidgin fiasco?

No? I'd love to have a link. Is it related to this bug: https://developer.pidgin.im/ticket/4986 ?

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 23:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Yep, exactly this one. Its Debian couterpart: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469283

In short, Pidgin developers limited the text input field to 4 lines (sorry, not 3). This change annoyed lots and lots of people, but developers refused to even make this feature optional.

There were a lot of discussions on various forums about it (Slashdot: http://tech.slashdot.org/story/08/04/30/1822237/pidgin-co... ).

I've heard from a source at Google that this very incident caused a reaction something like: "WTF are we spending millions to support XMPP if the best competing client is a toy managed by idiots?" Remember, this was 3 years after libjingle had been released.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 23:44 UTC (Thu) by jlargentaye (subscriber, #75206) [Link] (3 responses)

Huh, my initial thought following your previous comment about this being the straw to Google's XMPP efforts was that it was a silly anecdote to make a decision on... but it actually was a good illustration of the state of the XMPP client landscape.

On the other hand, Pidgin was never a good XMPP client, IMHO Psi was always much ahead, but Pidgin definitely benefited from more widespread use for being a multi-protocol client. Also Psi's stagnation and semi-fork in Psi+ didn't help it.

As a former XMPP advocate, I can only sigh.

Matrix: a new specification for federated realtime chat

Posted Feb 20, 2015 21:25 UTC (Fri) by flussence (guest, #85566) [Link] (2 responses)

Pidgin is an ego-stroking exercise, Psi is growing cobwebs and its UI is straight out of the 90s, Jitsi is stereotypical enterprise software... I gave up on desktop clients and now do my IMing from Xabber.

Most of the features I want in an XMPP client are completely missing there (there's space reserved for your avatar, when you can't *set* it), but at least its complexity feels proportional to what it *does* provide. I can send/receive text and it handles Unicode properly. It's even actively developed these days, after considerable pressure from the users.

Matrix: a new specification for federated realtime chat

Posted Feb 23, 2015 5:29 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

> after considerable pressure from the users.

They went through all the work to GPL it and then it seemed to just…die. I've seen updates go by in F-Droid, so I had guessed something picked back up. Good to hear, but I've since moved onto Conversations (which is also Android 5-ish in appearance).

Matrix: a new specification for federated realtime chat

Posted Feb 23, 2015 16:54 UTC (Mon) by flussence (guest, #85566) [Link]

I've tested the Xabber 0.10 versions in F-Droid - the UI has finally caught up, but there's zero new functionality besides that and I also ran into tons of bugs using it. (And then Google's idea of OS package management helpfully destroyed a year of chat history when I tried to downgrade...)

I might switch to Conversations for the time being, or at least keep it around as a backup client.

Matrix: a new specification for federated realtime chat

Posted Feb 20, 2015 13:22 UTC (Fri) by TRauMa (guest, #16483) [Link] (1 responses)

After reading your comment I went and looked at the issue in question just to see what was so terrible that it made Google give up on XMPP.

Boy, this is one very sad issue indeed. And not because the change by the pidgin team, they stated why and how they did it, and that many people saw a bug (tiny text entry area) and didn't know that you could just start typing without needing focus on the entry window.

Then the devs agreed to a larger max size for the window than 4, which is what happened in the next released version (so, at the next possible point in time). But in the meantime the bug report is spammed with plenty of people posting the same things again and again, even if they have been addressed already before (like said tiny field bug).

So let's be real here, this was maybe a mistake in communication, but not the reason XMPP never took on. XMPP, from it's inception, always had the problem that it was never as easy or even discoverable as other IM services, and in all the years I used it, only tech-related people ever were in my contact list, until they started to drop of, one after the other.

IM is one of those things where it doesn't matter if your solution is open and superior to one-vendor proprietary stuff if few of the people you want to message happen to have the client of your choice open. It's just that happened with mobile messaging, I have three clients, I actually like one, and I actually use WhatsApp.

Matrix: a new specification for federated realtime chat

Posted Feb 20, 2015 19:05 UTC (Fri) by pizza (subscriber, #46) [Link]

> So let's be real here, this was maybe a mistake in communication, but not the reason XMPP never took on. XMPP, from it's inception, always had the problem that it was never as easy or even discoverable as other IM services, and in all the years I used it, only tech-related people ever were in my contact list, until they started to drop of, one after the other.

You hit the nail on the head -- XMPP is a protocol, not a service.

Providing a service costs money, and if you don't charge directly for it, you have to make up for it in other ways, eg selling ads via some sort of captive client.

XMPP's open nature directly conflicted with the economic model of providing an IM service, so there was never much incentive (from the service provider's perspective) to use XMPP.

Matrix: a new specification for federated realtime chat

Posted Feb 13, 2015 4:58 UTC (Fri) by drag (guest, #31333) [Link]

I really did have high hopes for Jingle. This makes me sad.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 16:15 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

> Yes, group chats were added later. And I suggest you blame said clients for their poor support; many others have no problems whatsoever.

I think that any time you see poor support of a protocol across multiple clients like this you have to apply a simple razor when assigning blame, either all the developers of all the clients are unusually stupid or the protocol is unusually difficult to implement. Which do you really think is the more likely explanation?

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 18:32 UTC (Thu) by pizza (subscriber, #46) [Link]

> I think that any time you see poor support of a protocol across multiple clients like this you have to apply a simple razor when assigning blame, either all the developers of all the clients are unusually stupid or the protocol is unusually difficult to implement. Which do you really think is the more likely explanation?

...or, perhaps, both are true? In the case of XMPP, the specs are undeniably complex, but at the same time, so is the problem space it's trying to address.

What I've personally found disappointing is the lack of collaboration among the various client (and server) developers -- Every implementation seems to use a different language. But then there's the Android situation where you have half a dozen forks of the same underlying library, and *still* nobody's sharing. That's not a spec problem.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 22:41 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> Yet it remains the *only* option there is if you want an IM solution that doesn't require you to sign your soul (and your messages) over to $BigCorp.

You could hand out accounts to one machine and have everyone use `wall` and `talk` to message each other. You could even get fancy and have people attach to tmux sessions to do group stuff. So, no, XMPP isn't the *only* option. You just need some imagination ;) .

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 5:21 UTC (Thu) by wahern (subscriber, #37304) [Link] (4 responses)

It's made around a concept of permanent "associations" between the endpoints (so a server can store messages while endpoints are offline)

Yet Matrix has a similar setup. Clients connect to "home servers", which are relays for receiving and broadcasting message events. Basically store-and-forward. From section 5.1 of the specification:

A "Client" typically represents a human using a web application or mobile app. Clients use the "Client-to-Server" (C-S) API to communicate with their home server, which stores their profile data and their record of the conversations in which they participate.

I'm not saying that I like XMPP. I just don't see how Matrix is really different, except that it's "web scale" because it ditched XML in favor of JSON over HTTP. Plus IRC has received a resurgence of interest (if the interests of the junior engineers at my company are any indication). So I give them bonus points for mashing together HTTP, JSON, and IRC.

FWIW, I definitely prefer JSON over XML, simply because it's simpler, easier to parse, and maps more closely to language data structures, whether in C, Python, or something else. But tell me how Matrix solves the more serious problems which plague XMPP? Namely, the explosion of competing and complex extensions.

Matrix talks about supporting WebRTC and VoIP as a session initiation channel, but the devil is in the details! Matrix works no better than XMPP in this regard.

Matrix strikes me as the answer to the question, "how do you re-invent XMPP, avoiding design-by-committee, incorporating MUC, and making it easier to implement relays in your preferred language."

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 5:44 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> Yet Matrix has a similar setup. Clients connect to "home servers", which are relays for receiving and broadcasting message events. Basically store-and-forward. From section 5.1 of the specification:
XMPP is missing that distributed _stateless_ store-and-forward support. In XMPP each server has to store all of the state to remember which messages are yet to be sent to other servers while in Matrix servers can simply use an rsync-like protocol.

Matrix can be thought of as a new incarnation of USENET (now with real-time messaging!) rather than IRC.

> FWIW, I definitely prefer JSON over XML, simply because it's simpler, easier to parse, and maps more closely to language data structures, whether in C, Python, or something else. But tell me how Matrix solves the more serious problems which plague XMPP? Namely, the explosion of competing and complex extensions.
Personally, I don't really care about XML vs. JSON - both work perfectly fine and XML is actually better specified (I still miss XML schemas while using JSON, sigh).

The main feature that I like in Matrix is its use of distributed consensus protocols rather than explicit state storage like in XMPP. This single bit of design can do wonders.

Other than that, I agree that it's really early to tell if Matrix can avoid XMPP's pitfalls. But I have some hope and that's more than I can say about XMPP.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 12:50 UTC (Thu) by Arathorn (guest, #101018) [Link]

From my perspective, XMPP is all about message passing, whereas Matrix is all about state synchronisation (yes, I know they're two sides of the same coin, but they are opposite ways of addressing a similar problem). Matrix is basically an global EC DB with open federation and pubsub. A good analogy is that XMPP is like SMTP (with some storage extensions like IMAP), whilst Matrix is like NNTP. It's worth noting that XMPP does have some extensions like Buddycloud and FMUC which do provide decentralised persistent messaging - but with Matrix we wanted to see what'd happen if we just built on plain HTTP/JSON rather than the XMPP stack.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 17:23 UTC (Thu) by jnareb (subscriber, #46500) [Link] (1 responses)

> (I still miss XML schemas while using JSON, sigh)

There is JSON Schema, though

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 18:31 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, and there are several of them. And none of them are standard or even capture the actual practical JSON use.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 12:39 UTC (Thu) by Arathorn (guest, #101018) [Link] (1 responses)

Matrix absolutely doesn't rely on the logically centralised ID server to function. The ID system is currently in flux (hence not being documented properly in the spec), but we've deliberately kept it layered away from the core communication layer, so that Matrix isn't dependent on it (and so we can swap it out in future). And in fact the current implementations barely use it at all, other than to *optionally* register using an email address if you so desire.

The underlying 'opaque' Matrix IDs look like @matthew:matrix.org - and like JIDs or SIP URIs are indeed DNS backed, and works just as well (or otherwise) as XMPP.

We want to do better than XMPP & SIP (& IRC) by also linking 3PIDs to theses matrix IDs - we have no expectations of foisting yet another username@domain-style namespace on the world. Whilst right now this is logically centralised (but physically decentralised, as it happens) in ID servers, the plan is to adopt a proper decentralised ID system instead - ideally someone else's, so we don't reinvent that wheel. But we haven't got to it yet :)

In terms of novel features - yes, the git-style crypto-signed distributed DAG of conversation history with eventual consistency is the main innovation (and is shamelessly lifted from Git). Decentralised ACLs are also pretty cool. Relying on 3PID mapping for identity (when it lands) will be too.

Well done for spotting the Croquet similarity - needless to say, Matrix is about more than just instant messaging, and we want it to be a general persistent JSON distributed database with EC, pubsub and strong crypto semantics. And that could be for *any* data - be it Slack-style collaboration, or whiteboarding, or indeed Croquet-style virtual worlds & cyberspace. It's called Matrix for a reason ;D

Matrix: a new specification for federated realtime chat

Posted Jul 21, 2015 3:55 UTC (Tue) by sethml (guest, #8471) [Link]

Have you looked at Gale? It was written by a friend of mine, and had a very active community for a while. It featured quite seamless federation and end-to-end public key encryption with surprisingly easy to use key management and discovery. Its downfall was really an over-reliance on the everybody-has-an-account-on-a-*nix-server model, which kept the community tidy for a while, then killed it.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 9:18 UTC (Thu) by ptman (subscriber, #57271) [Link] (1 responses)

What about SILC, or Secure Internet Live Conferencing?

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 13:00 UTC (Thu) by Arathorn (guest, #101018) [Link]

I've never played with SILC and don't know much about it, but I think the main differences are:
* SILC doesn't seem to persist message history (which is Matrix's main defining feature)
* SILC doesn't do open federation (the networks are closed)
* SILC uses a custom binary line protocol rather than generic HTTP/JSON API
* Matrix uses TLS for encryption; history is not encrypted on the server (but E2E crypto is coming soon). SILC's encryption seems much more advanced.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 13:43 UTC (Thu) by Arathorn (guest, #101018) [Link] (6 responses)

Wow, thanks for writing all this! We (the Matrix team) are rather flattered/scared that LWN thinks it's worth writing about :)

Just to answer a few of the implicit questions in the article and clear up some of the places where the matrix.org spec and website is a bit stale or misleading:

The synapse repository also includes two demo clients: one that runs as a web application, and one command-line client written in Python. The most recent release is version 0.6.1f, from February 10.

The website is stale on this (sorry). We actually have 3 main reference clients - AngularJS (http://matrix.org/beta and http://github.com/matrix-org/matrix-angular-sdk), Android (http://github.com/matrix-org/matrix-android-sdk) and iOS (https://github.com/matrix-org/matrix-ios-sdk). The python commandline one in the synapse project just an HTTP/JSON console for debugging. (There are also other Perl and Python alpha commandline clients - come talk on #matrix:matrix.org if you want to experiment with them).

Also, we just released 0.7.0 a few hours ago, which has *huge* federation performance improvements over 0.6.x.

Second, users that want to connect to a persistent room need only remember the alias to join—if the original server is restarted, the room identifier might change, but the alias can remain the same.

Actually, the underlying opaque room ID can never change; it is shared across all the participating servers. For instance, #matrix:matrix.org is an alias to !cURbafjkfsMDVwdRDQ:matrix.org room ID (affectionately called curbaf to its friends ;). Servers can restart, and join and part from the room, but the room ID lives on. The only time a room could ever change is if a server lost all of its state (and its private key) and created a new room, and advertised an alias of it under the same name. If this happens, it doesn't impact the original room - it just means that another server will have to publish an alias to make it easier to find the original room (e.g. create a #matrix:therealmatrix.org which points to !cURbafjkfsMDVwdRDQ:matrix.org in this example).

Interestingly enough, the specification also advertises a way for users to publicly link a Matrix user ID to a "third-party identifier" (3PID), such as an email address or phone number. To do this, the Matrix network would support a global, federated network of identity servers that maintains the links between accounts and 3PIDs. The goal would seem to be making it simpler to invite another user to join a chat. Unfortunately, the relevant section of the Matrix specification is still empty (marked with "This section is a work in progress.").

...

The sydent server referenced is another GitHub repository, albeit one that has not been touched in five months.

The reason this is WIP is that it's in flux currently. We run a cluster of ID servers (using the sydent project in github) pointed to by matrix.org which work fine and are stable (hence lack of activity on the project), but logically they act as a single entity. They track email->matrix ID mappings (if you sign up with an email address). We want to fix this and make it properly federated ID system supporting multiple 3PIDs (MSISDNs, etc), but we're not there yet (and we want to borrow an existing federated ID system if we can, rather than re-inventing the wheel). Obviously we don't want this to be a SPOF - and the 3PID system is a strictly optional extra anyway.

The traffic on the wire is protected by TLS, but that does not prevent unwanted users from joining what is meant to be a private discussion room. Users who wish to restrict access to a room must rely on Matrix's room-management API: room moderators can kick out users or ban them (by user ID), but little else. Furthermore, although TLS encrypts the messages between servers, the servers themselves have access to the message content. Several spots in the specification and on the Matrix site as a whole make reference to optional end-to-end encryption (where only the users could decrypt the contents of messages), but this appears to be another unfinished component at present.

Crypto and ACLs are slightly different problems. Currently the client-server API allows both HTTP and HTTPS traffic (to support constrained devices which can't speak HTTPS, at the expense of any security/privacy whatsoever). The server-server API mandates TLS, and also signs the transactions (to protect against identity spoofing) and the history (git-style, to protect against tampering). However none of the payloads themselves are encrypted (yet) unless you do so at the application layer.

We do have good support for decentralised ACLs however - we absolutely stop unwanted users from joining private discussions, by supporting invite semantics, and decentralised ACLs where users must quote the historical events that prove that they have permission to join a room (or do some privileged action in the room). This is all relatively mature now, but is a very seperate problem from encrypted messaging.

The story on end-to-end encryption is that we've simply not specified it yet - but we'll heavily encourage people to use it once it exists. The intention is to borrow something like Axolotl (modulo its PFS characteristics).

Anyway, thanks again for writing about us. And LWN readers: please try installing a server and federating up, and come hang out in #matrix:matrix.org; tell us what you think and help us make it better!

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 15:04 UTC (Thu) by droundy (guest, #4559) [Link] (3 responses)

> We do have good support for decentralised ACLs however - we absolutely stop unwanted users from joining private discussions, by supporting invite semantics, and decentralised ACLs where users must quote the historical events that prove that they have permission to join a room (or do some privileged action in the room). This is all relatively mature now, but is a very seperate problem from encrypted messaging.

How does this work without ecrypted messaging? I.e. how do you prevent a user from running his own federated server that lets him read the messages in private rooms? Or are you only saying that you can prevent unauthorized users from chatting in a private room? That seems much less important to me than unauthorized listening.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 17:51 UTC (Thu) by Arathorn (guest, #101018) [Link] (2 responses)

Currently messages are stored in plaintext (or plaintext-equivalent) on servers, so yes, it's trivial for a malicious server admin to sniff conversations. Just like IMAP or or NNTP. It's worth noting that the conversations are 'only' stored on the servers which participate in a given room and aren't replicated arbitrarily (unlike NNTP, for instance).

To actually secure your conversation, you either need to use application-layer crypto (like PGP or OTR), or wait for us to define our 'official' end-to-end encryption semantics (using something like Axolotl). Obviously proper privacy guarantees are critical to Matrix's success, but whilst we've considered it in the design from day 1, we just haven't implemented it yet.

Seperately from the encryption question we have decentralised ACLs to stop users 'breaking into' private rooms and reading their history, as already discussed. The distinction is between protecting against inappropriate access to private data through legitimate channels (i.e. the Matrix HTTP APIs), which is a relatively hard problem in a decentralised world - and then seperately protecting against inappropriate access to private data through compromised/malicious servers (which is what end2end crypto is for).

Matrix: a new specification for federated realtime chat

Posted Feb 16, 2015 9:16 UTC (Mon) by gmaxwell (guest, #30048) [Link] (1 responses)

I think building a new communications tool which doesn't integrate end to end encryption with the participants -- (even just 'authorized channel users', in the context of channels where participants may be ambiguously defined) is really unwise and maybe even arguably unethical.

> Obviously proper privacy guarantees are critical to Matrix's success

Glad to hear it, but that it isn't in there from day one suggests that you believe that other functionality is more critical. I hope to see improvement in this area.

Matrix: a new specification for federated realtime chat

Posted Feb 16, 2015 9:28 UTC (Mon) by Arathorn (guest, #101018) [Link]

In the end it's a matter of pragmatism. We have designed the whole system to support e2e crypto (i.e. the servers never nake any assumptions about being able to read inside oayloads for routing/filtering/etc) . We just haven't got around to defining the implementation yet. (patches welcome!)

In the end, we want Matrix clients to be as trivial and tiny as possible - eg IoT connected devices talking trivial HTTP. That simply means not mandating HTTPS on the client/server API. Obviously one will be able to define rooms which are E2E only, and then you get best of both worlds.

I sympathise with the idea that "creating an unencrypted protocol in this day and age is unethical". But in the end I also like choice. If you as a user want to mandate crypto (once e2e has landed), you can. And if you as a user want to support lobotomised clients at the expense of privacy, you can too. Everybody wins.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 22:07 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

Can you do encrypting messages in the client and just make it very standardized behavior by recommending the clients behave in a particular way?

So say you have something like PGP/GPG on the client side were every message is signed by the user and encrypted using a public key generated for that particular chatroom/session. Then the encrypted messages are naturally stored and replicated just like plain text ones. To 'join' a chatroom then all that is necessary is to accept a invitation from the person/service that created the chatroom which will provide the necessary keys to decrypt previous and new messages.

That way you end up with end-to-end secrecy, the server can continue to manage chat rooms like it normally does. All the messages themselves can be in ascii-armor format or something like that so it wouldn't really change anything. It's just that they would be gibberish to anybody joining the room without a invitation.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 22:37 UTC (Thu) by Arathorn (guest, #101018) [Link]

Can you do encrypting messages in the client and just make it very standardized behavior by recommending the clients behave in a particular way?

Yup, this is precisely the idea. The catch is that you need to define how users' keys are distributed (PKI using centralised or federated keyservers? or PERSPECTIVEs? or some kind of per-session ephemeral keys? are they ratcheted?); you may need to define the mechanism for securely sharing a symmetric key for the room's content between the participants, or define the strategy for encrypting messages using all the participants keys. Do multiple devices for the same user share the same keys (if so, how?), or is each its own actor? Critically, you need to decide on whether to do PFS or deliberately make past history available to newcomers in the room.

All of this can be done at an application layer layered on top of Matrix (like PGP or OTR implementations on the clients) - but we think it's vital to mandate specific protocols for doing this, to avoid fragmentation and have some hope of ever federating with other e2e crypto systems (e.g. Axolotl-based services such as TextSecure or WhatsApp; or OTR-enabled clients; etc). And we can also provide well-defined helpers in the protocol for handling key discovery/exchange and the other administravia in-band.

We're starting work on this properly next week, so if anyone wants to help define how it works please swing by #matrix:matrix.org and give us a shout!

Matrix: a new specification for federated realtime chat

Posted Feb 15, 2015 17:49 UTC (Sun) by deepfire (guest, #26138) [Link] (3 responses)

How does Matrix relate/compare to TextSecure?

Some context: in the modern world, it seems that a protocol not grounded in security is.. counterproductive, I'd say.

Matrix: a new specification for federated realtime chat

Posted Feb 20, 2015 1:15 UTC (Fri) by Arathorn (guest, #101018) [Link] (2 responses)

To say that Matrix isn't grounded in security is a bit unfair. We've designed it with the intention of supporting E2E crypto from day 1 - but we just haven't finished implementing it yet.

The bits where crypto is fundamental to the robustness of the implementation are already in place. All server maintain keypairs. Message history integrity is all signed (like git). All replication transactions are all signed to protect against server identity spoofing. All federated traffic is TLSed.

As regards E2E, we actually (finally) started implementing it last week.

TextSecure is really nice - it uses Axolotl for a PFS key ratchet, and for group chat I believe each message is encrypted once with a ephemeral symmetric key, and the key are then sent 1:1 to all recipients using the 1:1 ratchet. The code seems good, and Moxie clearly knows his stuff.

However, if we deployed the TextSecure architecture to Matrix, we have a major problem: Matrix is all about storing history on a bunch of servers and synchronising it on demand to multiple clients. How can this ever work with PFS? New clients would never be able to replay past history by definition, as the keys to decode the old messages were ephemeral and have been lost. Moreover, existing clients could never expire history and re-lazy-load it in from the server, as the keys again will have been lost.

So our strategy in the E2E implementation for Matrix is to actually support a spectrum of PFS-ness, configurable per room. At one end of the spectrum, each room has a single symmetric key throughout its lifetime, which is shared securely 1:1 between the participants when they are invited into the room. This allows all past & future history to be decrypted. At the other end of the spectrum, you have pure PFS - each message has its own ephemeral key, and once the message has been pulled off the server, you might as well delete it from the server as you'll never be able to decode it again (unless the client keeps all the keys for all the messages it ever receives... at which point it might as well just be storing the decrypted messages).

In the middle of the spectrum it gets more interesting: you have the ability to specify encrypted subsets of data within the room, each with encrypted with its own symmetric key. In the simplest case, you could split the timeline of the room up into epochs. Only participants who have the key for that epoch can ever decrypt it. This lets you invite new participants in without leaking past history by rekeying the room when you invite someone - or lets you kick people out and rekey the room to avoid them decrypting it in future. The clients store non-ephemeral keys for as long as they care about decrypting the contents of the room on the server, and the usefulness of the matrix synchronised history is preserved.

In practice, we expect that this will be the common case. Rooms get created with a symmetric key; when users invite or kick people from the room they have the option to rekey the room to segregate history. Alternatively, the seriously tin-foil-hatted of us can enable PFS when creating the room, which will hopefully provide compatibility with TextSecure, and ensure that a single compromised key can never compromise any other history. However, this will obviously stop history synchronisation from being meaningful - your history will be stored on your clients, and only on your clients. (Don't to check for keyloggers!)

We expect to have the E2E implementation finished in the next 1-2 months. Getting the core state replication subsystem stable and performant is alas going to have to take priority in the interim.

Matrix: a new specification for federated realtime chat

Posted Feb 21, 2015 7:58 UTC (Sat) by eternaleye (guest, #67051) [Link] (1 responses)

I'd argue that even with PFS, history sync is meaningful for a few reasons:

Storage - if the client is only storing fixed-size keys, rather than variable-sized records, small clients (like phones) will be able to keep more history
Reliability - fixed-size keys can trivially be saved as a packed array, either of keys or of {timestamp, key} tuples (for searching efficiency), while variably-length messages require more complex (and failure-prone) storage
Verification - if the messages are encrypted using AEAD (and they should be!), keeping the key allows you to revalidate that yes, this _is_ the same message that was originally sent.
Simplicity - keeping the behavior of history sync the same even with PFS reduces the number of corner cases to handle in the code (and possibly the protocol).
Sharing - you want to show someone a past message, and you want them to trust that it actually happened when you say it did (and possibly the context, which are just more messages). If the server still has it, this is trivial: Send them the message identifier and the key, and let them fetch it themselves. This allows treating keys as read-capabilities for historic messages, which is a useful tool indeed.

Matrix: a new specification for federated realtime chat

Posted Feb 22, 2015 23:46 UTC (Sun) by Arathorn (guest, #101018) [Link]

Agreed on all scores. I guess we had been obsessing about throwing away PFS keys as rapidly as possible, but if we deliberately keep a cache around for these use cases it certainly make matrix's history more useful. So we'll define a configurable limit per-room for the amount of keys the user wants to cache. Thanks for the feedback :)

Matrix: a new specification for federated realtime chat

Posted Feb 19, 2015 22:55 UTC (Thu) by bjartur (guest, #67801) [Link] (1 responses)

Please start well known paths with /.well_known/. Configuration and management should automatically be easy and consistent. Grouping configuration directories under a common, well-known prefix greatly simplifies organization for administrators later on.

Regards,
Internet Engineering Task Force,
RFC 5785

Matrix: a new specification for federated realtime chat

Posted Feb 20, 2015 0:53 UTC (Fri) by Arathorn (guest, #101018) [Link]

Yup. The plan is to switch to .well_known to discover the whereabouts of both the client & server APIs real soon now. This was a thinko - my bad :)