
Matrix – An Open Standard for Decentralised Persistent Communication - reinhardt1053
http://matrix.org/
======
infogulch
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?

~~~
jkire
> 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.)

------
Klasiaster
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.

~~~
Udo
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.

~~~
jkire
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...

~~~
Udo
> 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.

------
unknownian
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?

~~~
Arnor
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?

~~~
ara4n
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)

------
ytjohn
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.

~~~
ytjohn
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).

~~~
ara4n
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](https://github.com/matrix-
org/synapse) and the doc is at [https://github.com/matrix-org/matrix-
doc/blob/application-se...](https://github.com/matrix-org/matrix-
doc/blob/application-services/drafts/application_services.rst) and
[https://github.com/matrix-org/matrix-doc/blob/as-http-
api/dr...](https://github.com/matrix-org/matrix-doc/blob/as-http-
api/drafts/as-http-api.rst) 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.

------
jsilence
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/](http://redmatrix.me/)

~~~
ara4n
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...](http://lists.w3.org/Archives/Public/public-
fedsocweb/2013May/0061.html) 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;](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!

------
gcb0
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?

~~~
ara4n
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.

~~~
gcb0
thanks for the explanation. but can't they encapsulate proprietary extensions
in the message data itself?

------
alex_duf
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 ?

~~~
ara4n
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 :)

------
mrmondo
Interesting - Would be keen on hearing more around it's end-to-end encryption
and OTR like capabilities though?

~~~
jkire
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.

~~~
ara4n
We've also been looking at Axolotl as a better-than-OTR for the E2E crypto.
But nothing is set in stone yet.

~~~
ara4n
...where "We" is the Matrix team :)

