[Members] MIMI update - November 2022
stpeter at stpeter.im
Fri Nov 18 00:32:26 UTC 2022
Hi Matthew, thanks for the report and sorry about the COVID. I've joined
the MIMI discussion list  and will probably post some feedback there.
Because I have a lot of experience with the IETF, I'm happy to assist
the XMPP community regarding this initiative. Feel free to ping me on or
off this list if you are curious about how things work at the IETF.
On 11/16/22 10:18 AM, Matthew Wild wrote:
> 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:
> Last week I attended the second MIMI meeting in London.
> The meeting materials can be found here:
> A (2 hour!) recording of the session can be found here:
> 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
> 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
> - 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.
> 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