Re: [Mimi] Matrix and MIMI

[Rohan Mahy <[e-mail]>]

Hi Matthew,
We won't be presenting any drafts today due to the short time we have.
However I encourage you and Travis to participate in the discussion about
scope and about the importance of the content format (whatever it is) and
offer suggestions for the proposed BoF / charter language.

Thanks and hope to talk to you soon.
thanks,
-rohan




*Rohan Mahy  *l  Vice President Engineering, Architecture

Chat: @rohan_wire on Wire



Wire <https://wire.com/en/download/> - Secure team messaging.

*Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178
Berlin,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
Germany
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>

Geschäftsführer/Managing Director: Morten J. Broegger

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675


On Mon, Jul 25, 2022 at 5:51 AM Matthew Hodgson <[e-mail]> wrote:

> 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
>
> --
> Mimi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mimi
>