[Mimi] Matrix and MIMI

[Matthew Hodgson <[e-mail]>]

Hi all,

Many thanks for taking the initiative to improve standardisation around 
comms interop!  It's very clear that the Digital Markets Act has shifted 
messaging interop from being an aspirational goal to something much more 
concrete and timely, and the IETF is well positioned to support such work.

Particularly, there are some very significant unsolved problems 
surrounding decentralised identity (discovering which services a given 
user has actually authorised to host their communication) and 
decentralised reputation/abuse (ensuring that open interoperable APIs 
aren't used as a mechanism for spam).  On the identity side, MIMI's 
problem space statement at 
https://www.ietf.org/archive/id/draft-mahy-mimi-identity-00.html is 
great - and it's also fantastic to see SPIN emerging as a potential 
concrete approach at 
https://www.ietf.org/archive/id/draft-rosenberg-dispatch-spin-00.txt.

Finally, it's clear that we also need a common application-layer 
communication protocol on top of MLS: it's no use having end-to-end 
encryption if everyone speaks different languages on top, necessitating 
bridges which then undermine E2EE.

However, this is also an area with significant prior art - and I'm 
really surprised to see CPIM being proposed as the content layer in 
MIMI. CPIM is almost 20 years old, and its approach reflects the 
previous generation of communication apps. Specifically, the proposal 
here seems to be to pass CPIM envelopes between participants in a 
conversation.  However, the reality is that these days the majority of 
modern collaborative communication apps (Slack, Teams, Wire, Telegram, 
etc) are focused on *consistently synchronising message history* (i.e. 
scrollback, and per-conversation metadata) across the users and devices 
participating in a conversation.

Back in 2014 we started working on Matrix (https://matrix.org) as an 
independent open standard to establish an application layer protocol for 
these semantics: specifically, modelling communication as conversation 
history which should be replicated over the participants.  Matrix 
expresses each conversation not as a loose stream of messages, but as a 
Merkle DAG (directed acyclic graph) of conversation history very similar 
to a Git repository. This gives the following main advantages over a 
message-passing approach such as XMPP MUCs, MSRP, SMTP, etc:

  * Conversation history becomes the primary first-class citizen: all 
clients automatically get synchronised consistent scrollback; lazily 
loading it in from other nodes as needed; automatically providing 
resilience to network partitions.  Everyone is guaranteed to see a 
maximally consistent view of the same conversation.

  * Conversation history is democratised and shared equitably over all 
participants - no single entity ends up becoming a defacto privileged 
node thanks to storing or relaying history: in fact, you can't 
communicate with others without equally sharing ownership of the 
conversation with them.  This is highly aligned with the various 
'avoiding internet centralisation' initiatives within IETF.

  * This highly decentralised structure also ensures that the underlying 
protocols must also be decentralised.  For instance, we've been gently 
contributing to MLS standardisation work, and particularly Decentralised 
MLS 
(https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentralised2/decentralised.org) 
- to ensure that MLS sequencing does not create an unnecessary form of 
centralisation.

  * Conversations automatically benefit from decentralised access 
controls - given there is no central point of control over rooms, access 
control is provided in a byzantine-fault tolerant manner by requiring 
each participant to include a simple proof of their permission to emit 
each event: 
https://matrix.org/blog/2020/06/16/matrix-decomposition-an-independent-academic-analysis-of-matrix-state-resolution

  * Conversations are decorated with structured key/value data, 
versioned in the timeline of the room, providing an incredibly useful 
decentralised key-value store as a first-class primitive alongside the 
conversational data itself (e.g. for room names, topics, icons, or much 
much more)

  * Account portability and multi-homed accounts become much easier: 
user history is automatically replicated onto whatever servers that host 
a given user's identity (currently WIP).

We built Matrix as a protocol for interoperability both between native 
Matrix implementations and existing communication systems. In fact, the 
name Matrix was picked because it acts as a matrix that can connect N 
platforms together in an NxN matrix.  The direct inspiration for 
Matrix's improved semantics was learning from our experiences 
implementing various RCS/IMS/MSRP/CPIM and XMPP based communication 
systems for the telco industry in 2010-2014.  We hope these learnings 
might be relevant here!

Matrix has turned out to be successful as an approach: with a vibrant 
and highly hetrogenous ecosystem, there are hundreds of bridges now 
implemented which link existing communication systems via Matrix; three 
major independently-developed server implementations (in Python, Go and 
Rust); and hundreds of clients which natively speak the protocol.  The 
public network can see over 64M addresses (of which 30M are natively on 
Matrix, and about 15M are long-term users) - spread over around 95K 
server instances.

Meanwhile, an ever increasing number of independent (and sometimes 
competitive) commercial organisations have been successfully using the 
protocol for interoperability, including IBM, Ericsson, Thales, 
Palantir, LivePerson, Beeper, Famedly, Rocket.Chat, Element and many 
more.  The French state has adopted Matrix as its official communication 
system (https://element.io/case-studies/tchap), as has the German armed 
forces (https://sifted.eu/articles/european-armies-matrix/), German 
healthcare industry 
(https://matrix.org/blog/2021/07/21/germanys-national-healthcare-system-adopts-matrix), 
and significant uptake in the UK, US and Scandanavia.  The protocol has 
also proven to go far beyond basic instant messaging, supporting 
decentralised VoIP/Video conferencing 
(https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls-to-multiparty) 
and even interoperable spatial collaboration 
(https://github.com/matrix-org/thirdroom/blob/main/README.md).

Matrix itself is currently published as an open standard 
(https://spec.matrix.org) by an independent non-profit foundation 
(https://matrix.org/foundation) and the spec evolves via an open 
governance process (https://spec.matrix.org/unstable/proposals/). 
However, we are approaching the point of maturity where Matrix could be 
ratified by a dedicated international standards body - and as such we'd 
be very interested to hear if there is interest in Matrix being 
considered as the application layer on top of MLS for interoperable 
communication.  We are already working on using MLS for Matrix's E2EE - 
and after all; we have a proven track record to date of running code and 
rough consensus as an interoperable comms standard.  We did present 
Matrix as an HotRFC at IETF-101, but at the point the protocol was still 
very much in fux - whereas nowadays we're in a much better position to 
discuss if/how Matrix could exist in IETF.

I was hoping to be present at the BOF in Philly today and raise this for 
discussion there: however, it looks like i am not going to be able to 
make it - instead Travis Ralston from the Matrix spec core team will 
hopefully be there to represent (or failing that we will try to do 
remote participation).

Otherwise, thoughts would be very welcome here on whether Matrix could 
provide a better application layer than a linear CPIM-based approach for 
MIMI?

thanks,

Matthew

-- 
Matthew Hodgson
Project Lead
Matrix.org