[messaging] Matrix.org: Decentralized group chat

[Matthew Hodgson]

On Sun, 8 Mar 2015, Ximin Luo wrote:

> Briefly skimming over their spec: http://matrix.org/docs/spec/ "The 
> state of the room at a given point is calculated by considering all 
> events preceding and including a given event in the graph. Where events 
> describe the same state, a merge conflict algorithm is applied."
> 
> My impression too is that they underestimate how hard this will be. 

Hi folks; Matrix is my fault - sorry for being late to the party, and 
thanks for the interest ;)

First of all - I'm hoping that the weak point here is our doc rather than 
the design/algorithm/implementation itself (although I'm very happy to be 
shown otherwise whilst Matrix is unashamedly unfrozen and in flux).  We 
currently have a major pipeline bubble in editing together all our design 
drafts and docs into a full coherent spec, although most of the material 
exists - just fragmented.

So in terms of state merge resolution: yes, this is obviously a hard 
problem to get right.  Hopefully we haven't underestimated it.  The WIP 
draft documentation for it is at 
https://github.com/matrix-org/matrix-doc/blob/master/drafts/erikj_federation.rst#state-resolution.  
Meanwhile the reference python server implementation actually implements 
this, and hasn't exploded yet.

> Also, their security practises are questionable - they do have a list of 
> threats in the spec, but there are no suggestions or even hints on 
> techniques on how they will defend against these threats. 

Again, I think reflects the quality of the doc rather than the design & 
implementation.  We haven't yet written up a response to the threats point 
by point (publishing the threat list is an attempt to show that we /have/ 
thought it through, though).  Much of the answers are currently fragmented 
between 
https://github.com/matrix-org/matrix-doc/blob/master/drafts/erikj_federation.rst#authorization 
and 
https://github.com/matrix-org/matrix-doc/blob/master/specification/11_event_signing.rst.

> I guess they will add this stuff in later, but as I'm sure everyone on 
> this list knows, you can't just "add security later". It sounds like 
> they just did the equivalent of adding partial ordering to a federated 
> protocol similar to XMPP, using TLS "for security", and hoping that 
> everything will be naturally straightforward to conceptually lock down 
> as they write the code.

I think this is a little unfair.  The reality is that we maintain a 
git-style replicated DAG of messages, nodes and thus tree signed by the 
various originating servers for integrity - a bit more than a naive 
partial ordering.  The federation protocol is then nothing like XMPP, 
being concerned with both pushing/pulling updates of the DAG across the 
mesh of servers.  XMPP MUCs run off a single logical chat server; if 
anything Matrix is more like an XMPP FMUC.

Finally, our security has at least 5 layers:

1) the message DAG is signed for integrity by the various participating 
servers (qv), proving tamper resistance by walking back through the DAG 
checking signature to the root node if needed.

2) the federation transactions are signed per-transaction (with an HTTP 
auth header) to assert identity

3) mandatory TLS to actually encrypt the federation transactions

4) all of the merge resolution conflict stuff linked to above.

5) axolotl for end-to-end encryption (not yet released, but we've written 
a C++ axolotl implementation for the various clients to use for e2e 
crypto, supporting per-room configurable PFS-ness - see 
https://lwn.net/Articles/634144/ for details of the design there).

For sure we've iterated on the design whilst implementing the reference 
server & clients, and need to finish writing it up, but hopefully we're 
not entirely making it up as we go along :)

And yes, Matrix is unashamedly inspired by Wave - but with HTTP rather 
than XMPP, and possibly more focused on open federation from the outset.


Matthew

-- 
Matthew Hodgson
Matrix.org