[messaging] Matrix.org: Decentralized group chat
matthew at matrix.org
Tue Mar 10 13:39:53 PDT 2015
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
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
> 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.
More information about the Messaging