Skip to main content

Minutes interim-2023-mimi-05: Wed 16:00
minutes-interim-2023-mimi-05-202306071600-00

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

minutes-interim-2023-mimi-05-202306071600-00

MIMI Virtual Interim - June 7, 2023

Linearized Matrix - Travis Ralston

Slide 3: Architecture

  • Alissa: Would there be an initial room version that everyone would
    have to support?
    • Travis: Yes, the idea is just to specify one initial version and
      leave future versions to future spec. In practice no one
      specifies new versions.

Slide 4: Architecture

  • Richard: Does this version fix the issue where DAG-capable provider
    does not have linear event history?
    • Travis: Yes, user in provider B here would see a linear event
      history only.

Slide 5: Events

  • Konrad: Are events broadcast to all servers/hubs?

    • Travis: Yes. Hub server is the only one required to track
      everything, but other servers can if they want to.
  • Konrad: So are events in the clear?

    • Travis: Save this for discussion coming up.

Slide 6: Definition of ACLs

  • Richard: Are power levels defined as part of the room version?

    • Travis: Power levels are how Matrix maps permissions and rules.
    • Power level is a large state event mapping a string key to an
      integer -- 100 is admin, 50 is a moderator. To ban you need
      power level of >=50, e.g.
    • Definition of what requires what level is defined in power
      levels state event. Enforcement of the power level is defined in
      auth rules which are part of the room version.
  • Rohan: Ban/kick/redact/etc. -- each has a power level

  • Richard: There is a strict ordering of power levels -- any higher
    level has all the powers of a lower level.

    • Travis: We've been using this for years and it maps fine to
      every other system except Discord. Discord would need a
      different room version.
  • Ekr: What is meant by "actual enforcement"?

    • Travis: Ban event gets sent over the wire, is received by
      hub/server, runs that through the auth rules (including
      detecting that this is a ban), and auth rules tell the
      hub/server how to process the ban.
    • Ekr: But power level is specified in room version?
    • Travis: Auth rules tell you to look up the user's power level.
      The spec would say "to ban you have to have the power level X
      defined in the room config." Current I-D describes the existing
      power levels and auth rules algorithm (sec. 5.4.2).

Slide 7-8: Channel state, server side

  • Konrad: Server would make a client add someone to the group at the
    MLS level?

    • Travis: Yes. "When you see Alice with a new device, get her
      involved in the MLS group" via external join or some such.
  • Konrad: What is cross-signing? Every MLS client knows who else is in
    the group at all times. If server injects a new device for any user,
    the user would notice.

    • Travis: Damage is already done because the malicious device is
      already in the room.
  • Ekr: Need some way to have a policy that says only existing members
    can add people and a policy that says the server can add people.
    Kicking is hard part -- server cannot kick because it's not in the
    group.

    • Rohan: Server can do an external proposal, which has to be
      accepted by a member.
    • Richard: Server can propose but not commit. Someone who comes
      online can then commit the kick. Server can choose to not accept
      any events until its proposal is committed.
    • Ekr: Logic has to attach to concept of room roster. When you
      look at a new identity, if it matches one on the roster, then
      you accept the external join. Need ability to sign the roster.
  • Konrad: Do you consider MLS messages public or private? Encrypted or
    plaintext? Handshake messages can be sent encrypted or unenecrypted
    in MLS. Unencrypted leaks metadata about group membership. Server
    could easily track MLS membership if we were using public handshake
    messages. Server could also check if next commit is a kick.

    • Travis: Want to encrypt as much as we can, unless server needs
      to see this information.
    • Richard: Propose adopt the goal of using encrypted MLS messages
      everywhere, or compatability with that option. Might find out
      not everything is compatible with that. But start from
      assumption that server cannot see MLS messages sent, including
      proposals and commits. And only roll back if we encounter cases
      we can't handle that way.
    • Konrad: Started out trying to have all encrypted MLS messages in
      our DS and wound up building all the semantics outside on top of
      MLS again. So we switched to plaintext MLS messages with
      obfuscated metadata.
    • Konrad: Server verification of message construction is valuable.
    • Richard: And server already knows much of the metadata anyway.
      Just a little worried about what you could put in MLS
      extensions.
    • Travis: Also have DMLS in Matrix. Epochs become small DAG
      associated with each device and you run conflict resolution on
      them without having to make the server aware of the metadata.
      Not yet described in the draft.

Slide 9: Client-side

  • Richard: Why are we talking about client-side given that Matrix
    keeps state server-side?

    • Travis: Just wanted to address question from interim.
  • Rohan: Servers are only in the dark if commits are private messages.
    And if commits are private, we won't be able to do external joins,
    which we agreed previously was a requirement. Not aware of anyone
    building an MLS implementation that is doing encrypted MLS commits.

    • Travis: Yes, eventually you will need public commits.
      Disadvantage of client-side room model.
    • Rohan: Anything we do in MIMI is going to require public
      messages for commits, this is non-controversial.
    • Konrad: Agree with Rohan. Disagvantages of public messages can
      be mitigated.
    • Richard: Did not intend to be dogmatic about private messages.
      We ship public messages.

Slide 10: Server-side or client-side?

  • Travis: Hearing we want server-side.
  • Ekr: What do we want our design to provide in terms of server
    security? Server can't read messages, falsely inject a user into the
    group. But it's not practical at the moment to conceal the group
    structure from the server. Server may or may not be able to modify
    the configuration. If room has to be cryptographically protected,
    then config needs to be as well.

    • Travis: I think we're saying we want cryptographic proof of room
      changes.
  • Tim: To what extent can existing gatekeeper server operators add
    members to a group? If MIMI says this is impossible, that will be a
    deal-breaker.

    • Travis: Gatekeepers today have ability to impersonate their own
      users. Social contract is what prevents that from happening.
    • Rohan: iMessage does not allow for adding users to existing
      groups -- this is broken and we shouldn't design around it
  • Konrad: Wanted to support what Ekr said -- we need to decide what
    security/metadata requirements we want to meet.

  • Ekr: Regarding Tim's question, we want to be compatible with
    existing systems while having better security properties.
  • Matthew posted gatekeeper comparison:
    https://docs.google.com/spreadsheets/d/1FiR4yhU5BpLtoeFFda5ORr86qwT33fYZowY_bWDlPas/edit#gid=1722388534
  • Alissa:
  • Travis: Sounds like we have rough consensus around doing something
    server-side with public MLS messages. Cryptographically bound
    question is still open.
    • Ekr: WG is not at state of calling consensus on specific design
      decisions for linearized Matrix, but whether linearized Matrix
      is the right starting point.

Ekr: What are the benefits and challenges you see based on starting from
linearized Matrix, beyond the fact that it's based on something we know
works?

  • Travis: Already working is the big benefit. Auth rules have already
    been narrowed down a lot. Downside is server-side model. Matrix has
    its own encryption, so many of the issues are fixed at that level.
    With MLS, servers could theoretically inject devices and we need to
    come up with rules in a greenfield to protect against that.

Ekr: Do you see there being signiciant architectural differences between
LM and draft-rosenberg?

  • Travis: UUIDs -- we already ran into that problem, already started
    using hashes. But architectures are very similar -- hub with
    participant server. (Later question about ability to move hub server
    to a different provider.)

    • Matthew: Moving the hub around could be easier in LM because the
      decentralized Matrix machinery makes this easier.
    • Matthew: In Matrix messages are mutable, whereas in MTP they are
      immutable.
  • Konrad: How does LM accommodate longer term net splits?

    • Travis: [note-taker missed the net split answer]
    • Matthew: Disabling key gossiping functionality altogether in new
      client, just tell users they can't see the old messages because
      of network problems. But this doesn't happen in LM.

Richard: What is state of the art of implementation and interop testing?

  • Travis: We wrote "eigenserver" as an LM example server. Took days,
    not months, for it to function. Proven it can work with Synapse,
    wich is traditional Matrix server. Working out details of making it
    work with something not Matrix branded.
  • Richard: Would be nice to have someone starting from the spec and
    see if they can interop.
  • Matthew: We have compliance test suites for traditional Matrix
    server and client published by Matrix Foundation. Superset of
    requirements for MIMI use case. Building one for LM.
  • Matthew: Would be interesting to take existing Matrix server and
    make it speak LM. Or one of the independent ones (e.g., Conduit).
  • Richard: Not just down from regular Matrix, but build up from
    nothing.
  • Travis: Aware of a couple of implementations planned, but not
    written by us.
  • Ekr: Standard here is I need to be able to read the spec and nothing
    else and build the thing.
  • Travis: Current draft has no references to spec.matrix.org.
  • Matthew: Been talking to 2 independent outfits to plug into non-chat
    servers -- Mastodon-style things that don't have DMs. Can nudge
    those guys. Or people who can pretend to be independent.

Richard: Since participant servers don't do much, is a client-server API
better for this use case?

  • Travis: LM is based on federation API. Matrix client-server API is
    way too complicated for MIMI. Although there are implied
    constraints.
  • Matthew: Is a subset of client-server API enough? I asked myself
    this question in 2015. We need different flavors because we're
    optimizing for totally different things. Client never gets info
    about rooms they're not looking at, bare minimum is just lazy
    loaded. This is how Discord and Telegram are doing it. Fundamentally
    different problem to how do you synchronize server state.
  • Konrad: We thought about this too. Can have partial overlap between
    c-s and s-s API. In sending case, server is just a dumb pipe.
    Allowing this partially might be interesting.
  • Matthew: What really is the difference between c-s API and s-s API
    other than the prefix of the API call? For Matrix, when you send c-s
    API, don't need to understand DAG or linked list.
  • Konrad: With LM, state is kept on the hub, which mimics MLS.
  • Travis: Benefit of MTP is that there is just one API. LM could be
    characterized as either c-s or s-s -- will maybe adjust so it's just
    "an API."

Alissa: Homework assignments for the WG --

  • Review latest LM I-D and have discussion on the list
  • Review gatekeeper comparison and raise questions/comments on the
    list
  • Get interop testing doing for LM, for those interested
  • Alissa to take an initial stab at synthesizing requirements
    discussed from IETF 116 going forward