Skip to main content

Minutes interim-2023-mimi-01: Wed 16:00
minutes-interim-2023-mimi-01-202305031600-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

minutes-interim-2023-mimi-01-202305031600-00

MIMI Virtual Interim - May 3, 2023

Notes MIMI Interim May 3rd 2023

Agenda: 

  • Wrapping up Ekrs deck from previous meeting

  • Slides by Raphael Robert

Ekr: 

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

Pete: 

  • 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.

Ekr:

  • 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
    network.

  • Is not necessarily used in an interop world.

Tim: 

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

Joel Alwen:

  • Consent has to be able to be given asynchronously.

Rohan:

  • 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.

Ekr:

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

  • 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.

Ekr:

  • 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.

Matthew:

  • Matrix is built like that, too.

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

Richard: 

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

Ekr:

  • This is especially the case in an interoperability scenario.

Joel:

  • 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
    acceptable

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
    way).

  • We could generate names for ad-hoc names.

Richard:

  • 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.

Alissa:

  • We need to analyze the current behaviour of existing messaging
    systems.

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

Joel:

  • 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.

Rohan:

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

Ekr:

  • Room ownership mechanisms may be different depending on providers.

Matthew:

  • 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.

Rohan:

  • 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.

Rohan:

  • We should not start from scratch.

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

Alissa:

  • Some core-features could be considered as in-charter (such as
    kick/ban).

  • 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.

Raphael:

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

  • Agrees with Alissa.

Matthew:

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

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

Ekr:

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

Matthew:

  • (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.

Raphael:

  • 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.

Matthew:

  • 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.

Matthew:

  • 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.

Raphael:

  • 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.

Ekr:

  • 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?

Raphael:

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

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

Joel:

  • 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
    pop-up.

  • There has to be a sane default.

Ekr:

  • 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
    level.

Raphael:

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

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

Joel:

  • Agrees with what Raphael was saying.

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

  • Agreement between clients is important, will catch bugs.

Alissa:

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

Ekr:

  • We will need more than one option.

Raphael:

  • 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.

Ekr:

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

Alissa:

  • This does not solve the problem of interoperability between
    providers.

Raphael:

  • 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.

Rohan:

  • 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.

Jonathan:

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

Joel:

  • 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.

Raphael:

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

Ekr:

  • 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.

Ekr:

  • 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.

Alissa:

  • A draft (or multiple drafts) would help.

Ekr:

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

Chairs:

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