Matrix – An Open Standard for Decentralised Persistent Communication(matrix.org)
matrix.org
Matrix – An Open Standard for Decentralised Persistent Communication
http://matrix.org/
9 comments
Alright, how is this different from the other attempts at this type of server-based system? And how is this better than Tox, which is P2P?
I tend to use at least three different devices through out the day: my laptop, my phone and my work computer. I'm constantly switching between them. This coupled with the fact my memory is utterly atrocious means that I really really need to have conversation history synced across all my devices, otherwise I tend to ramble on about the same thing again and again.
Multiple device support is definitely a second class citizen in XMPP, and is just plain Hard (if not impossible) in a P2P world.
Multiple device support is definitely a second class citizen in XMPP, and is just plain Hard (if not impossible) in a P2P world.
I'm confused as to how it's similar to Tox. Matrix seems to be a server with an API that allows you to send and subscribe to messages. This would be useful for a software engineer working with M2M communication. Unless I'm looking at the wrong `Tox`, it seems to be a P2P IM client. These seem like completely separate domains, right?
Matrix is basically an eventually consistent object database with open federation and pubsub. It's optimised for messaging at the moment - you can use it for group chat, or WebRTC signalling, or M2M/IOT stuff, or anywhere else you want to pubsub data and keep a history. The similarity with Tox is that Matrix can implement a chat system that looks like Tox. The architectures are completely different though: Tox is a big distributed hashtable smeared over lots of peers; Matrix is client/server with synchronisation between te servers. (disclaimer: Matrix is my fault)
This is absolutely the type of system I've been hoping for for quite a while. I even started drafting up a spec to build it. I wanted a federated, http based message passing pub/sub type system with device synchronization - and (here's the kicker) - encryption optional.
So why don't I want encryption? Simple, my intended use is in amateur radio, where encryption is in fact restricted (basically, you can only use it to control a satellite).
In amateur radio, we have been developing this mesh network (basically wifi mesh, but we can use much higher power and alternate, non-line-of-sight frequencies like 440Mhz). With the HSMM-Mesh system, we have built in dhcp, dns, ability to advertise services (web, irc, etc) on systems that are usually completely isolated from the Internet at large. We run this on re-purposed routers, laptops, raspberry pis, etc. So you can setup an IRC, FTP, or web server on a pi, someone else can bring a node up within range of your wireless signal, see your node, get a list of services you offer, and use them.
An issue with this is that you want to make multiple "field nodes" and deploy them
So matrix would work really well here. Since each node has its own DNS name (based on our call sign), you could run a matrix server, set people up with the clients, and if we learn of another matrix server on the mesh, federate with it. The two matrixes become consistent eventually. If we bring a node (these would all be battery powered portable) into range of a more permanent fixed station, all the days activity could end up on that fixed station. The fixed station could federate with an Internet instance as well (which would require more extensive validation to ensure users are licensed operators).
A few issues would be user registration - we'd have to disable verification in the field as there won't be email. I don't think we'll have username conflicts. USER1@SERVER1 won't conflict with USER1@SERVER2. Since all users are government issued call signs, identity will be consistent across each matrix server.
So why don't I want encryption? Simple, my intended use is in amateur radio, where encryption is in fact restricted (basically, you can only use it to control a satellite).
In amateur radio, we have been developing this mesh network (basically wifi mesh, but we can use much higher power and alternate, non-line-of-sight frequencies like 440Mhz). With the HSMM-Mesh system, we have built in dhcp, dns, ability to advertise services (web, irc, etc) on systems that are usually completely isolated from the Internet at large. We run this on re-purposed routers, laptops, raspberry pis, etc. So you can setup an IRC, FTP, or web server on a pi, someone else can bring a node up within range of your wireless signal, see your node, get a list of services you offer, and use them.
An issue with this is that you want to make multiple "field nodes" and deploy them
So matrix would work really well here. Since each node has its own DNS name (based on our call sign), you could run a matrix server, set people up with the clients, and if we learn of another matrix server on the mesh, federate with it. The two matrixes become consistent eventually. If we bring a node (these would all be battery powered portable) into range of a more permanent fixed station, all the days activity could end up on that fixed station. The fixed station could federate with an Internet instance as well (which would require more extensive validation to ensure users are licensed operators).
A few issues would be user registration - we'd have to disable verification in the field as there won't be email. I don't think we'll have username conflicts. USER1@SERVER1 won't conflict with USER1@SERVER2. Since all users are government issued call signs, identity will be consistent across each matrix server.
I also wanted to point out that it would be easy to use something like twisted to write an IRC or XMPP gateway to a specific matrix server. Then you can utilize a common IRC or XMPP client (though message ordering might be a major issue in an occasionally connected environment).
This would be a really cool use for Matrix - the eventual consistency and offline operation stuff is a perfect fit :D
You don't need an email address to sign up currently - the way it works is that it's up to the homeserver to decide how to validate new users (if at all). So Matrix.org uses a CAPTCHA to check you're human, but otherwise just sends a username & password. We also let you optionally specify a mail address, mainly just to prove that we do support validating 3rd party IDs like email (and in future MSISDNs and other IDs).
For gatewaying, the main thing we've been missing is an Application Service (AS) API on Matrix which lets your gateway masquerade multiple users & rooms/channels from the remote protocol. Currently you can write a back-to-back bot which creates, per user, an IRC user on the IRC network and a Matrix user on the Matrix network and bridges them together - this is how the current Matrix<->IRC bridge works. This sucks if you want to easily project hundreds of users & channels from IRC into Matrix and vice versa, though - you need better server support, a bit like IRC Services' architecture.
The good news is that this is very nearly implemented - we got our first AS up and running a few hours ago (it currently just logs traffic rather than bridging it anywhere). It's all happening on the application-services branch of https://github.com/matrix-org/synapse and the doc is at https://github.com/matrix-org/matrix-doc/blob/application-se... and https://github.com/matrix-org/matrix-doc/blob/as-http-api/dr... if you're interested.
Twisted is probably overkill for many ASes, but it could be a great way to do the XMPP & IRC bridging in future.
You don't need an email address to sign up currently - the way it works is that it's up to the homeserver to decide how to validate new users (if at all). So Matrix.org uses a CAPTCHA to check you're human, but otherwise just sends a username & password. We also let you optionally specify a mail address, mainly just to prove that we do support validating 3rd party IDs like email (and in future MSISDNs and other IDs).
For gatewaying, the main thing we've been missing is an Application Service (AS) API on Matrix which lets your gateway masquerade multiple users & rooms/channels from the remote protocol. Currently you can write a back-to-back bot which creates, per user, an IRC user on the IRC network and a Matrix user on the Matrix network and bridges them together - this is how the current Matrix<->IRC bridge works. This sucks if you want to easily project hundreds of users & channels from IRC into Matrix and vice versa, though - you need better server support, a bit like IRC Services' architecture.
The good news is that this is very nearly implemented - we got our first AS up and running a few hours ago (it currently just logs traffic rather than bridging it anywhere). It's all happening on the application-services branch of https://github.com/matrix-org/synapse and the doc is at https://github.com/matrix-org/matrix-doc/blob/application-se... and https://github.com/matrix-org/matrix-doc/blob/as-http-api/dr... if you're interested.
Twisted is probably overkill for many ASes, but it could be a great way to do the XMPP & IRC bridging in future.
[deleted]
Interesting! How does Matrix relate to red#matrix [1] and the Zot protocol? Not asking because both projects contain the word "matrix". Both projects seem to overlap. Would like to know more about how they differ and how they relate.
[1] http://redmatrix.me/
[1] http://redmatrix.me/
There is no link between RedMatrix and Matrix.org - the fact that both have Matrix in the name is total coincidence. On the Matrix.org side, we came across RedMatrix for the first time a few months ago when stumbling across http://lists.w3.org/Archives/Public/public-fedsocweb/2013May... in Google, which then linked from Friendica/Red to RedMatrix.
I've never played with Friendica/Red/RedMatrix/Zot, but from what I can see, it's more about federated blogging/social networking than messaging or pure JSON synchronisation like Matrix. Architecturally I'm not sure how they compare - I only just found https://github.com/friendica/red/wiki/zot; we'll have a read and see what the difference is.
Something we're very keen to do with Matrix.org is to build as many gateways and bridges through to other comms ecosystems as possible - so the fact that both Matrix.org & RedMatrix (& Diaspora & Identi.ca & all the others) are operating in a similar space isn't at all a problem - so long as they all talk to each other. It'd be a bit embarrassing if we were building federated communication systems which couldn't gateway to each other!
I've never played with Friendica/Red/RedMatrix/Zot, but from what I can see, it's more about federated blogging/social networking than messaging or pure JSON synchronisation like Matrix. Architecturally I'm not sure how they compare - I only just found https://github.com/friendica/red/wiki/zot; we'll have a read and see what the difference is.
Something we're very keen to do with Matrix.org is to build as many gateways and bridges through to other comms ecosystems as possible - so the fact that both Matrix.org & RedMatrix (& Diaspora & Identi.ca & all the others) are operating in a similar space isn't at all a problem - so long as they all talk to each other. It'd be a bit embarrassing if we were building federated communication systems which couldn't gateway to each other!
I will be the cynic and say it right away:
this is all good and dandy like jabber was. Then someone like google will provide a massive, free*, always-on server. take control of everything because it will have all the users. and dictate when features are in or not (e.g. jabber federation)
Or is this harder to happen with matrix?
this is all good and dandy like jabber was. Then someone like google will provide a massive, free*, always-on server. take control of everything because it will have all the users. and dictate when features are in or not (e.g. jabber federation)
Or is this harder to happen with matrix?
Yes, it's deliberately much harder for this failure mode to happen:
1. Matrix's baseline featureset is much more comprehensive than XMPP and doesn't yet support API extensions; only datatype extensions. So for a Google to become the defacto implementation and then start lobotomising the featureset they really would not be speaking Matrix at all any more.
2. Federation is completely fundamental to Matrix. All rooms are distributed over all participating servers with no single points of control or failure. So rooms and the network will always live on in other servers, even if a big player becomes a default provider.
1. Matrix's baseline featureset is much more comprehensive than XMPP and doesn't yet support API extensions; only datatype extensions. So for a Google to become the defacto implementation and then start lobotomising the featureset they really would not be speaking Matrix at all any more.
2. Federation is completely fundamental to Matrix. All rooms are distributed over all participating servers with no single points of control or failure. So rooms and the network will always live on in other servers, even if a big player becomes a default provider.
thanks for the explanation. but can't they encapsulate proprietary extensions in the message data itself?
It's interesting but I feel like it's redundant with XMPP.
I think we don't give enough credit / importance to XMPP because it's not "brand new", it's not what the cool kids use.
How can we make XMPP cool again ?
I think we don't give enough credit / importance to XMPP because it's not "brand new", it's not what the cool kids use.
How can we make XMPP cool again ?
XMPP and Matrix are fundamentally different things. XMPP is all about message passing. Matrix is all about state synchronisation. In many ways Matrix is more like an eventually consistent distributed DB like Cassandra or Riak, albeit optimised for storing persistent messages and with open federation (anyone can spin up a node and join the DB) and an HTTP/JSON API.
So: if you want decentralised message history as a first class citizen, use Matrix. It's not just for group chat; it's for any data.
If you want lower-latency message passing with history as an optional extra, use XMPP.
In terms of how to make XMPP cool again - projects like XMPP-FTW and Buddycloud and FMUC are pretty cool :)
So: if you want decentralised message history as a first class citizen, use Matrix. It's not just for group chat; it's for any data.
If you want lower-latency message passing with history as an optional extra, use XMPP.
In terms of how to make XMPP cool again - projects like XMPP-FTW and Buddycloud and FMUC are pretty cool :)
Interesting - Would be keen on hearing more around it's end-to-end encryption and OTR like capabilities though?
End to end encryption is probably one of the last big things we've yet to fully tackle, unfortunately. Though hopefully we'll fully begin to start spec'ing that sometime soon!
One of the major things we want is the ability for e2e encrypted messages to still be readable from all of your devices, which is kind of incompatible with OTR. Saying that, people have been talking about building OTR on top of Matrx; either by embedding OTR messages directly in the message JSON or using Matrix to negotiate a data channel with something like webrtc.
One of the major things we want is the ability for e2e encrypted messages to still be readable from all of your devices, which is kind of incompatible with OTR. Saying that, people have been talking about building OTR on top of Matrx; either by embedding OTR messages directly in the message JSON or using Matrix to negotiate a data channel with something like webrtc.
From a quick glance at the spec, it seems that everything is an event and it roughly has the following structure:
{ [...] "room_id": "...", "content": "<the actual payload>", [...] }
The way I see it, the easiest way to make OTR happen is to keep the general JSON structure in the clear so that all servers know the context (in particular the room_id must be understood by the servers to know where the message is to be routed) and have the content be encrypted in a format that only the client(s) understand:
{ [...] "room_id": "...", "content": "<encrypted payload>", [...] }
This is actually how PGP on SMTP works: the servers know where to route the message, and forward the content without looking at it or trying to understand it. The servers know the very minimum, so their implementation remain easy and understandable, and they critically don't need to be reliable for end-to-end encryption to work.
Being a fan of IM systems I'm interested in Matrix, specifically because it tries to blend in what didn't work with IRC and XMPP, so I may very well look into it a little bit more ...
{ [...] "room_id": "...", "content": "<the actual payload>", [...] }
The way I see it, the easiest way to make OTR happen is to keep the general JSON structure in the clear so that all servers know the context (in particular the room_id must be understood by the servers to know where the message is to be routed) and have the content be encrypted in a format that only the client(s) understand:
{ [...] "room_id": "...", "content": "<encrypted payload>", [...] }
This is actually how PGP on SMTP works: the servers know where to route the message, and forward the content without looking at it or trying to understand it. The servers know the very minimum, so their implementation remain easy and understandable, and they critically don't need to be reliable for end-to-end encryption to work.
Being a fan of IM systems I'm interested in Matrix, specifically because it tries to blend in what didn't work with IRC and XMPP, so I may very well look into it a little bit more ...
I think rather then federation people need real P2P systems and not only clients to a server. Specially I don't think that heavy relying on HTTP makes sense here - in addition it implies that the encryption you get is SSL, which is awkward. Things like GnuNet are of course not ready, but as you can see with people using Tox right now for communication, P2P networks allow to start a new design with respect to a good cryption model and methods improving anonymity of communication flows.
A server can do a lot for you that a standalone client can't. It's a machine that's always on, easy to back up, lets users communicate in real time, and the coordination of different client devices per account comes practically for free.
I think one of the reasons federated systems (which once were the backbone of the internet) are being phased out while the huge monoliths like Facebook are winning is that, while people do want a federated alternative, they want this alternative to be philosophically pure in a way that makes the end user experience untenable.
I'm building an open source distributed social network quite similar to this Matrix thing, actually. It's simple, scalable, and it works. It provides a good user experience, too. But fellow geeks tend to hate it. JSON over SSL? Too simplistic. 'We want a VM that runs inside a JavaScript engine which implements its own crypto and _true_ P2P, nothing else will do.'
The trouble is we do know how to make simple and "awkward" solutions work quite well, whereas I have yet to see a "pure" option I'd want to use myself. Of course, that may be personal preference in the end, but I'm kind of hoping I'm not alone.
I think one of the reasons federated systems (which once were the backbone of the internet) are being phased out while the huge monoliths like Facebook are winning is that, while people do want a federated alternative, they want this alternative to be philosophically pure in a way that makes the end user experience untenable.
I'm building an open source distributed social network quite similar to this Matrix thing, actually. It's simple, scalable, and it works. It provides a good user experience, too. But fellow geeks tend to hate it. JSON over SSL? Too simplistic. 'We want a VM that runs inside a JavaScript engine which implements its own crypto and _true_ P2P, nothing else will do.'
The trouble is we do know how to make simple and "awkward" solutions work quite well, whereas I have yet to see a "pure" option I'd want to use myself. Of course, that may be personal preference in the end, but I'm kind of hoping I'm not alone.
Multiple device support and history synchronization between devices really are table stakes to me, especially since I tend to spend a lot of time checking messages and chatting from mobile devices these days..
That distributed social network thing sounds quite exciting, and very much in a similar vein as Matrix. Does it have a website/github repo yet?
We've definitely found its not always easy to balance a philosophically pure/technically nice solution with one that actually has a usable UX. Although it sometimes seems that half the battle is figuring out what actually is a usable UX...
That distributed social network thing sounds quite exciting, and very much in a similar vein as Matrix. Does it have a website/github repo yet?
We've definitely found its not always easy to balance a philosophically pure/technically nice solution with one that actually has a usable UX. Although it sometimes seems that half the battle is figuring out what actually is a usable UX...
> Multiple device support and history synchronization between devices really are table stakes to me
I know where you're coming from.
We're working (well, it's just two guys for the moment) on the first version and we're planning to launch for early feedback soon. I'll be posting it as a Show HN, but in case it gets buried I can put you on our notify list - just shoot me an email.
I know where you're coming from.
We're working (well, it's just two guys for the moment) on the first version and we're planning to launch for early feedback soon. I'll be posting it as a Show HN, but in case it gets buried I can put you on our notify list - just shoot me an email.
Is it going to be opensourced ?
Yes, as I said. I don't think it'd work any other way.
Do you have a spec or something publicly available? :)
That would be very relevant to my interests! ^_^ Thanks.
Not yet, for the simple reason that the spec isn't stable yet. We're doing an early feedback launch soon, I can notify if you want. We'll put the reference implementation on GitHub, too.
One of the things that's important to me is the option for "3rd party software" to participate in the network as well, so we're keeping it as simple as possible to enable others to build stuff that integrates with it.
One of the things that's important to me is the option for "3rd party software" to participate in the network as well, so we're keeping it as simple as possible to enable others to build stuff that integrates with it.
nothing prevents you of bundling a server in a client.
you will have the server with the most downtime and people will hate talking to you when you are not online. but that may be a good thing...
you will have the server with the most downtime and people will hate talking to you when you are not online. but that may be a good thing...
I guess even the offline thing may not be a problem as long as the messages are in a room that is hosted over an always-on server. The bundled server will be able to sync up its history from the always-on server.
Very interesting. Lots of questions, but I'll avoid those that are listed but not yet answered in the FAQ.
How does Matrix deal with netsplits and partial-netsplits?
How are highly diverged histories (e.g. a long netsplit in an active room) supposed to be merged?
Does the protocol require O(N^2) connections for N users? (The number of users in some IRC rooms is measured in thousands.) Can it be more efficient?
How are rooms administered? E.g. how is it decided that someone is allowed in a room? That's easy with highly trusted rooms with personal acquaintances, but what about more public rooms like programming help or computer talk?
How does Matrix deal with netsplits and partial-netsplits?
How are highly diverged histories (e.g. a long netsplit in an active room) supposed to be merged?
Does the protocol require O(N^2) connections for N users? (The number of users in some IRC rooms is measured in thousands.) Can it be more efficient?
How are rooms administered? E.g. how is it decided that someone is allowed in a room? That's easy with highly trusted rooms with personal acquaintances, but what about more public rooms like programming help or computer talk?
> How does Matrix deal with netsplits and partial-netsplits?
> How are highly diverged histories (e.g. a long netsplit in an active room) supposed to be merged?
So the cool thing with the federation in matrix is that all the messages (and state changes like room memberships) are part of a directed acyclic graph (DAG), so any new messages that are sent reference the previous ones. (Very much like git). That way a server can tell if it is missing any messages as long as it can talk to a server in the room. Since everything is signed by the originating servers, servers can pull in missing messages from third parties! Thus partial-netsplits are fine, as all the messages will eventually propagate through to all servers :)
When a full netsplit happens you effectively get two separate branches in the graph, each group of servers happily talking to each other. When a netsplit is resolved, one of the servers will realise they can talk to one of the other servers, at which point one of the them will send an event that references both branches (in effect merging them). All the other servers will then realise what they are missing and pull the branches in. At that point a certain amount of state resolution needs to happen (e.g. if people joined and left on the different branches) to ensure that all the servers have a consistent view of the state of the room.
The really difficult problem we've found is how you communicate to the clients about the netsplits, and how the clients should display the netsplits (although this is more of a UX issue, but still important). Since the messages in the room are stored as a DAG, the servers can see what messages were part of which netsplit and so that information can be made available to the clients.
> Does the protocol require O(N^2) connections for N users? (The number of users in some IRC rooms is measured in thousands.) Can it be more efficient?
Currently the protocol uses full mesh to distribute the messages to all the servers (which in practice are going to be fewer than the number of users in the channel), though since it uses HTTP the servers don't need to maintain active connections to all other servers. We really want to come up with new distribution models for really large rooms at some point, but we haven't quite gotten that far yet :)
> How are rooms administered?
The user that created the room gets admin rights to the room and given a "power level". The admin can set the power level required to do different things, (e.g. kick, ban, set the name of the room etc), as well as whether you need an invite to join the room or not. They can also grant (and revoke) power levels to other members of the room. Now, if a remote server intentionally ignores these rules then other servers in the room will simply not accept the dodgy actions. All actions, whether message sending or banning someone requires the server be able to prove that they had permission to do that by supplying a list of events along the lines: "I can ban because I have power level X, which was assigned by Y, who could do that because...".
(I'm part of the matrix team ftr.)
> How are highly diverged histories (e.g. a long netsplit in an active room) supposed to be merged?
So the cool thing with the federation in matrix is that all the messages (and state changes like room memberships) are part of a directed acyclic graph (DAG), so any new messages that are sent reference the previous ones. (Very much like git). That way a server can tell if it is missing any messages as long as it can talk to a server in the room. Since everything is signed by the originating servers, servers can pull in missing messages from third parties! Thus partial-netsplits are fine, as all the messages will eventually propagate through to all servers :)
When a full netsplit happens you effectively get two separate branches in the graph, each group of servers happily talking to each other. When a netsplit is resolved, one of the servers will realise they can talk to one of the other servers, at which point one of the them will send an event that references both branches (in effect merging them). All the other servers will then realise what they are missing and pull the branches in. At that point a certain amount of state resolution needs to happen (e.g. if people joined and left on the different branches) to ensure that all the servers have a consistent view of the state of the room.
The really difficult problem we've found is how you communicate to the clients about the netsplits, and how the clients should display the netsplits (although this is more of a UX issue, but still important). Since the messages in the room are stored as a DAG, the servers can see what messages were part of which netsplit and so that information can be made available to the clients.
> Does the protocol require O(N^2) connections for N users? (The number of users in some IRC rooms is measured in thousands.) Can it be more efficient?
Currently the protocol uses full mesh to distribute the messages to all the servers (which in practice are going to be fewer than the number of users in the channel), though since it uses HTTP the servers don't need to maintain active connections to all other servers. We really want to come up with new distribution models for really large rooms at some point, but we haven't quite gotten that far yet :)
> How are rooms administered?
The user that created the room gets admin rights to the room and given a "power level". The admin can set the power level required to do different things, (e.g. kick, ban, set the name of the room etc), as well as whether you need an invite to join the room or not. They can also grant (and revoke) power levels to other members of the room. Now, if a remote server intentionally ignores these rules then other servers in the room will simply not accept the dodgy actions. All actions, whether message sending or banning someone requires the server be able to prove that they had permission to do that by supplying a list of events along the lines: "I can ban because I have power level X, which was assigned by Y, who could do that because...".
(I'm part of the matrix team ftr.)