[Members] MIMI update - November 2022

Winfried Tilanus winfried at tilanus.com
Fri Nov 18 01:26:19 UTC 2022

On 16-11-2022 18:18, Matthew Wild wrote:


Thanks a lot Matthew for the update. I'm lurking the MIMI list and wil 
try to respond every now and then...

Regarding the relation between MIMI and the EU Digital Markets Act 
(DMA): the European Comission (EC) still has to implement the 
technicalities of the interoperability of 'gatekeeper platforms' (and 
even that is optional), it may ask an /European/ standards body (like 
the CEN or ETSI) to draft a standard. Beside that this would be a clear 
example of deligating difficult political issues to a technical 
committee, the EC still has to move here and set the stage with the 
request at the standards body. This European standards body may adapt an 
international standard, like an IETF standard.

Many of the assumptions about the requirements made in MIMI group are 
still open in the DMA. I believe it is important to keep the work of 
MIMI up, but chances are high MIMI's work will be sidetracked for the 
DMA. (All depending on the EC). I will try to follow what is happening 
here within the EC, though I have only little access there.


> 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 :)

vanishing in a puff of logic
xmpp:winfried at tilanus.com

More information about the Members mailing list