Skip to main content

Minutes interim-2023-mimi-01: Wed 16:00

Meeting Minutes More Instant Messaging Interoperability (mimi) WG
Date and time 2023-05-03 16:00
Title Minutes interim-2023-mimi-01: Wed 16:00
State Active
Other versions markdown
Last updated 2023-05-23


MIMI Virtual Interim - May 3, 2023

Notes MIMI Interim May 3rd 2023


  • Wrapping up Ekrs deck from previous meeting

  • Slides by Raphael Robert


  • Different modes of connection establishment exist

  • Same goes for group membership additions

  • Which modes do we want to support? More than one? All of them?

Pete Resnick:

  • Some systems will need Version 1 (from Ekrs slides)

  • We need a permissions mechanism.

Rohan Mahy:

  • Systems that need Version 1 are broken (in that they are not a
    modern IM system)


  • Version 1 would have to work at least within a (closed) system.

Matthew Hodgson:

  • We can implement 1 through 2 and 3 with an auto-accept mechanism.


  • It’s a spam question: Can we get away with a consent-based system?

  • Do we have an inventory of what existing system does what?

  • (Essentially volunteers to create such an inventory.)

Alissa Cooper:

  • Systems support 1 mostly because it helps grow their internal

  • Is not necessarily used in an interop world.


  • Choice might depend on whether there is a searchable user index.

Joel Alwen:

  • Consent has to be able to be given asynchronously.


  • Only service without consent is Apple.

Wes Hardaker:

  • In the context of interoperability, the important question is how do
    you recognize if something has been delivered.


  • Discovery and key package access are key topics, both tying into

  • Key packages have to be available for offline consent.

  • We seem to have consent on supporting 2 and 3 with the option of
    enabling 1 through 2 or 3.

  • (No objections)

  • It might be different for later additions of users to groups, but
    for now, we’re assuming that once a connection has been made, people
    can add others to groups.


  • How to model groups/channels? Named/unnamed, 1-to-1 etc.

  • What about overlapping groups (same participants, etc.)

Richard Barnes:

  • Ad-hoc survey by himself and Alissa finds that there is no coherent
    approach across messengers.

  • The group is the basic element. Everything else is a specialization
    of that.

Raphael Robert:

  • Agrees with Richard.

  • Is essentially what MLS is built around.

Rohan Mahy:

  • This can be seen as an authorization problem in that it depends on
    who can add whom.

  • Wire is built like that.


  • Matrix is built like that, too.

  • Fixing a specific approach here might require big changes for
    existing providers that use a different approach.


  • Using a different approach can lead to oddities in terms of group


  • This is especially the case in an interoperability scenario.


  • Ad-hoc groups are confusing for people.

  • For interop, we should agree on a modality regardless of the
    underlying protocol.

  • MLS-native access control doesn’t solve this problem.

  • 1-to-1 channels are well-understood by users and thus may be

Jonathan Rosenberg:

  • Whatever we choose: Will the gatekeepers adopt this? If we choose an
    incompatible mode, the gatekeeper won’t adopt MIMI.

  • We need to support all modes supported by the gatekeepers (in some

  • We could generate names for ad-hoc names.


  • Solve the different modalities one by one.

Jonathan Lennox: 

  • We need to consider UX and user expectations.

  • E.g. 1-to-1 groups can’t turn into ad-hoc groups.


  • We need to analyze the current behaviour of existing messaging

  • There are odd behaviours and it’s not clear that it makes sense to
    support them.


  • The modality of a group can be fixed by an MLS extension.

Ekr (trying to summarize)

  • Named-groups should probably be the main mode.

  • Named groups can emulate 1to1 and ad-hoc groups.

  • Inconsistencies might drop out if we rigorously define how we
    emulate the individual approaches.


  • I’ll take a stab at defining an approach.


  • Room ownership mechanisms may be different depending on providers.


  • If everyone implements their own mechanisms, it’s going to be chaos
    and hard to communicate to the user.

  • Also, we won’t be able to move ownership.

  • It might make sense to have a common language.


  • Agrees with Matthew

Jonathan Rosenberg:

  • We should support the minimal things the gatekeepers do.

  • Whatever rules there are, they should be transparent, or at least
    there should be explicit feedback in case of rejection.


  • We should not start from scratch.

  • Instead, we should agree on an established set of features.


  • Some core-features could be considered as in-charter (such as

  • W.r.t. a re-charter: Let’s focus on getting something done in this
    first phase. We can then re-iterate in the next phase.


  • Whatever we agree on we can probably easily build on top of MLS
    through group agreement.

  • Agrees with Alissa.


  • Some room management features are very elementary (e.g. naming a

  • Volunteers to draw up a grid of functionalities that might be
    elementary in the first phase.


  • Room ownership: Can we move groups from one system to another?


  • (regular) Matrix room ownership is overkill for MIMI. The result is
    linearized Matrix.

  • Being able to move room ownership is important and might solve room
    management problems.

  • The UX should be consistent across owning systems.

  • Moving ownership is important for redundancy.

  • Leaves the door open to (more) decentralization.


  • We don’t have to support portability immediately, but we should
    consider it for a later phase.

  • This is compatible with his current delivery service proposal.


  • Agrees with Raphael.

Jonathan Rosenberg:

  • Hubs will have different behaviours and might not be fully portable.

  • For portability, we would have to support the superset of all
    possible features of all existing gatekeepers.

  • We shouldn’t worry about it now.


  • Gatekeepers at the core all support very similar semantics.

  • From a lot of bridging experience with Matrix, there are only a few
    outliers in terms of what can’t be supported by basic room
    management features.


  • Gatekeepers will have to adopt to MIMI to some degree anyway.

Ekr (trying to summarize):

  • We kick the can down the road, but keep the problem in mind.

Matthew (in chat)

  • Agrees to make a list of gatekeeper provided feature.


  • Different State keeping between MLS and transport.

  • There are different ways of how to sync this state (see slides)

  • Which one should be the source of truth?

  • Different systems require different approaches (enterprise vs.
    consumer messaging)

  • Does everything have to be tied to MLS?


  • We need agreement between clients, which is facilitated by MLS.

  • The service can issue Proposals to add someone to a group.


  • We want authenticity (ACLs) via MLS, enforced by clients (do not
    trust the service).

Jonathan Rosenberg:

  • Does not agree.

  • This is a UX problem. How do we surface this to users?

  • We have to make sure that users don’t just click “Okay” on an ACL

  • There has to be a sane default.


  • Doesn’t think we should assume that ACLs are enforced by humans.

  • We’re going to need a language for access control policy on the MLS


  • (clarifies) Policy is not enforced by users, but by their clients.

  • Due to cryptographical agreement, ACLs are going to be a lot more


  • Agrees with what Raphael was saying.

  • ACL doesn’t have to be flexible between groups.

  • Agreement between clients is important, will catch bugs.


  • Do we need more than one option w.r.t. ACLs? Probably.


  • We will need more than one option.


  • MLS enforces whatever policy you choose and will ensure that there
    is agreement.

  • We don’t have to rely on clients exclusively. All current delivery
    service proposals allow server-side enforcement.

  • Any ACL approach we choose will be baked in on the MLS level.


  • We seem to close in on option 3 (MLS based ACLs).


  • This does not solve the problem of interoperability between


  • This is a charter problem, not an MLS problem.

  • MLS will support whatever we end up on.

Jonathan Rosenberg:

  • Where would the ACL come from?

  • If the ACL comes from the service, we run into problems.


  • We solve this by having the clients check the policy proposed by the
    server relative to certain ACL templates.

  • Clients and servers can verify who set a certain policy.


  • This might not be feasible in a non-greenfield system.


  • As soon as the client creates the group, the ACL proposal by the
    server is fixed.

  • We could operate with ACL templates (Meta ACLs?) that capture the
    ACLs of existing messaging providers.


  • The server can still block group creation if the ACL used is not
    legal in the eyes of the server.


  • It looks like we are converging and we might need a concrete
    proposal at this point.

Jonathan Rosenberg:

  • Consider the following scenario: The malicious provider proposes an
    ACL that allows adding a malicious participant to the group.


  • As long as we signal the general nature of the group (meta ACL) to
    the user, we should be okay. Such a group would probably be public.


  • A draft (or multiple drafts) would help.


  • Volunteers to prepare a draft on how to handle ACLs.


  • We will continue next time with Raphael’s slides. The chat seems to
    generally agree on biweekly meetings.