[Members] MIMI update - November 2022

Matthew Wild mwild1 at gmail.com
Wed Nov 16 17:18:09 UTC 2022


Hi folks,

In July I posted about a new group being formed at the IETF about
"messaging interoperability". I won't duplicate any of the content of
that email here, so you should definitely review it before reading
further if you need a reminder:
https://mail.jabber.org/pipermail/members/2022-July/009417.html

Last week I attended the second MIMI meeting in London.

The meeting materials can be found here:
https://datatracker.ietf.org/meeting/115/session/mimi
A (2 hour!) recording of the session can be found here:
https://www.youtube.com/watch?v=MRRYGRlHYr8

Don't worry - I will summarize key points, so you don't have to sit
through the 2 hours unless you really want to :)

For the time-constrained, a 250 character summary: The meeting did not
discuss any technical specifics, but the high level goals and
milestones that should be reached. The tech stack for MIMI will
involve MLS for E2EE, but most other things are to be determined once
the working group is fully formed.

A more detailed report follows:

The first thing to know is that More Instant Messaging
Interoperability (MIMI) is not yet a fully-formed working group. The
main focus right now is finishing the group's "charter", which is a
brief document that specifies what the group's goals are, the problem
it is trying to solve, what its outcomes will be, and of course
defining the scope (including anything that it is *not* going to be
working on). Once the charter is finished, MIMI will be subject to the
IETF's approval process for new working groups.

A large portion of the session's time was therefore dedicated to
discussion about what should and shouldn't be in the charter. The
general goal is to include enough in the charter so that everyone
agrees what MIMI will work on, without getting too specific or making
premature technical decisions that should be discussed and debated by
the working group after it is formed. The current draft charter can be
found here: https://github.com/coopdanger/ietf-wg-mimi/blob/main/charter.md

Although the meeting was not very technical in nature, that will be
the most interesting part to many of us here, so I'll try to summarize
some of the early technical discussions about MIMI which happened
during the session, or during informal discussions before and after
the session with various people involved. Remember, practically none
of this is official, I'm only summarizing the current desires and
intentions of the people involved so you can get an idea of what to
expect.

The group will focus on using the IETF's existing Message Layer
Security (MLS) protocol. The EU's Digital Markets Act (DMA) says that
interoperability needs to be achieved without compromising on
security, though it ignores how difficult this is to achieve in
reality now that most messaging apps already employ end-to-end
encryption. Although many systems have adopted variants of Signal's
E2EE protocol over recent years (including XMPP as OMEMO), it has some
issues, such as limited scalability in large groups and each variant
is incompatible due to differences in how it has been integrated into
each platform. MLS aims to solve all these problems and serve as a
secure, reviewed, open standard that anyone can implement.

Even if two services use MLS, that doesn't automatically achieve
interoperability. To state the basic problem: each platform/protocol
has a different format for messages. XMPP's is XML-based of course,
and Matrix uses JSON. Proprietary services invent their own formats
too. Traditionally bridges between messaging systems perform some
translation between e.g. the XMPP message format and the message
format used by the external system. However, with end-to-end
encryption the majority of the message is encrypted and can't be
viewed or modified by the server or bridge. To be able to read and
convert the message data, the bridge would need to break the
encryption, making it so that your E2EE is between you and the bridge,
rather than between you and your contact. This is not an acceptable
definition of E2EE for most people!

Therefore for MIMI to work, we'll need to standardize the E2EE layer
(MLS will be used for this) as well as standardizing the format that
goes *inside* the encrypted message. Whatever format MIMI defines will
need to be implemented by clients (the server/bridge cannot convert it
to XMPP's usual message format due to the encryption).

MIMI will also need to define a "transport protocol", which specifies
exactly how service A will actually connect to service B to send the
encrypted messages. Needless to say, XMPP is a possible candidate.
Other options that have been suggested include Matrix, or inventing
something entirely new (e.g. this proposal for a new protocol called
CAST: https://datatracker.ietf.org/doc/html/draft-nandakumar-mimi-transport-00
).

The final big piece is about discovery or "the introduction problem".
For example, if someone gives you an identifier (e.g. their phone
number) and tells you to contact them, somehow your chosen platform
needs to work out how to reach that identifier (e.g. is it a phone
number registered Signal, or WhatsApp? is it a Telegram username?).

A concern raised by a few people was the topic of spam/abuse. The
current MIMI draft charter explicitly puts spam and abuse out of
scope, however they are major concerns for the kinds of large
providers that we are hoping will adopt MIMI.

Okay, that's all for the technical part for now (if you have
questions, I'm happy to answer them).

Here are some of my personal concerns about MIMI (though they are
probably not unique to me):

- Currently none of the gatekeeper organizations (e.g. Facebook) have
expressed any official or unofficial interest in supporting MIMI. That
may change of course, but it may not. However there is the possibility
that this work will be completed, and the gatekeepers will simply roll
out their own proprietary solutions to comply with the DMA.

- XMPP currently has no specification for MLS. We will need to define
something if XMPP is to be an option for MIMI (there are multiple
reasons we might want to work on MLS support even without MIMI).

- MLS is still very new. It has two leading implementations, both in
Rust. Both implementations are currently not up to date with the
latest version of the MLS spec, but that is expected to change soon.

- There is a deadline for the Digital Markets Act to be implemented by
the gatekeepers. The earliest date this can happen is the end of 2023.

- If MIMI is successful and does not use XMPP as the transport
protocol and/or content format, we will likely all have significant
work to do to support it if we want to bridge with MIMI-compatible
platforms.

- If MIMI is unsuccessful, but the DMA is successful, we will have
significant work to do for each and every single platform we might
ever want to bridge to.

If you made it this far, congratulations! Seems like you're interested
in this stuff and should consider joining the mailing list :)

Happy to answer any questions on the topic here or directly via email/XMPP.

Regards,
Matthew

PS. Apologies for the delay in getting this email out - I wrote the
majority of it last week while it was fresh, but it turns out large
conferences in closed spaces and inter-city travel are a great recipe
for catching COVID. I'm fine and getting back on track though :)


More information about the Members mailing list