[Members] MIMI update - November 2022

E.M. emus at mailbox.org
Wed Nov 16 17:38:03 UTC 2022

Hey Matt,

first of all, many many thanks for taking time and efforts. Same to other XMPP folks participating.

Do you have a suggestion on:

- How XMPP Community could act here?
- How XMPP Community should act the best way? (maybe duplicate of the first question)
- How we as XMPP Community/organisation should form around this topic?
- Anything you couldn't cover and need help from?


16 nov 2022 18:21:24 Matthew Wild <mwild1 at gmail.com>:

> 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