Matrix – An Open Standard for Decentralised Persistent Communication
matrix.org
matrix.org
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 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.)
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.
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.
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...
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.
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...
Multiple device support is definitely a second class citizen in XMPP, and is just plain Hard (if not impossible) in a P2P world.
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.
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.
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!
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?
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.
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 ?
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 :)
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.
{ [...] "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 ...