MIMI interim 02

Tim G, Chair slides:

Raphael: Transport vs. delivery service

Following from Yokohama discussion
Let's look at status quo and general understanding and discuss that
MLS is at the core of MIMI, let's clarify the architectural requirements
on it

Status quo: 3 proposals for delivery service/transport:
- linearized matrix (replaces prior Matrix proposal)
- rosenberg MIMI protocol
- raphael MIMI delivery service

Consensus:
Groups are "owned" by one of the providers
Other providers are guests or participants
RESTful API is used to coordinate

How does a client on the guest provider talk to someone on the owning
provider?

Disensus:
- Client-to-server vs. server-to-server protocol
- Unclear what operations or data are in scope of the protocol
- Unclear whether fanout of messages from provider to clients is pull
vs push
One proposal uses long polling, another (Matrix) uses push
- Consumer vs. enterprise
Is metadata private? Are expectations different in those two use cases?

How does linearized Matrix address these points?
- Relaxes adherence to P2P philosophy
- Stores history server-side
- Unclear how metadata is handled

How does rosenberg-mimi-protocol address these points?
- Batteries included approach
- Incorporates delivery service and transport
- Blurs abstraction layers
- Will the long poll model scale to open federation?

How does robert-mimi-delivery-service address these points?
- Not a transport protocol, only specifies messages
- agnostic to underlying transport
- agnostic of client-to-server or server-to-server model
- deliberately narrow scope, confines itself to MLS operations

Delivery service

rosenberg-mimi-protocol describes a server to server transport
Unclear how this fits onto MLS as cleint interaction is unclear

Fanout
- When a guest provider commits to the owning provider, that message
must be fanned-out to all over guest providers
- Distinct second phase of the protocol
- rosenberg-mimi-protocol calls for guest providers to long-poll the
owning provider
- prevents owning provider from spamming guests
- unclear how this works with open federation

MIMI-over-HTTPS (MoH)
- transport for robert-delivery-service

What's the stack?
- Consensus is HTTP+TLS on the bottom
- Then MoH over that for message transport
- Components like delivery service, discovery, etc. on MoH

Questions/queue:
- Travis Ralston: Matrix authors working on tying their proposal to MLS

Raphael: what should be the scope of the draft?
Travis: batteries included may be better
Rohan: Do we have a document that shows the big picture?
MoH draft could be separate
Tim G: How does MLS "enforce" ACLs?
Rohan: MLS guarantees participants have a consistent view of ACLs, but
of course can't guarantee that the ACLs are applied by any given
participant
Raphael: Putting this at MLS layer also ensures no participant can add a
member without other participants noticing
Rohan (to Robert): Let's go through the latest delivery service draft to
unpack tricky MLS concepts

Reviewing
https://datatracker.ietf.org/doc/html/draft-robert-mimi-delivery-service-02

• Discussion of how MIMI-level concepts map to MLS operations
• Client can authenticate to delivery service in a group-specific
  manner
• MLS key packages akin to Signal "pre-keys"
• Resyncing group state is a critical protocol feature
  Experience with implementing, deploying Signal protocol shows this goes
  wrong in production and recovery is needed
  Resync must be part of any mature protocol
  Rohan: re: resync: is this a re-init or a participant missing some
  epochs?
  Raphael: re-init means restarting the whole group for all participants.
  Re-sync specific to a client.
  Rohan: "resync" implies catching up on event/message history. Calling it
  "rejoin" has right semantics without baggage.
• Queueing service addresses fanout
• MIMI must specify how messages fan out from owning provider to other
  client providers
  Rohan: We can tap IETF expertise on this question, and lots of prior art
  on message queues.
  Raphael: Maybe some of this can be out of scope?

Reviewing
https://datatracker.ietf.org/doc/html/draft-kohbrok-mimi-moh-00
- HTTP message definitions for messages from draft above
- Rate limiting can be done by client IP, but also on group IDs

Back to ekr transport requirements deck:
Privacy for metadata?
Raphael: very important for consumer messaging, less so for enterprise
messaging
MLS E2E protects messages, but what about metadata?
- Group membership
- Contact list
- Who is messaging who?
MLS can protect metadata, so for example you can have a message to a
group where the sender is only visible to group members
Can't protect all metadata, because some of it must be visible to
servers for message routing
Raphael+Konrad trying to design a delivery service that allows
pseudonymous groups
Server doesn't know for sure who group members are
Rohan: Desire for seeing metadata will vary across providers. How do we
interop across metadata-philic and metadata-phobic systems?
Raphael: Will depend on the groups involved. Perhaps an owning server
gets to dynamically advertise metadata requirements, akin to advertising
supported ciphersuites?
Mallory Knodel: IETF should define bare minimum requirements for sharing
metadata to make it clear where individual providers have opted to
require or share extra metadata.
Raphael: this might be too big of an ask for enterprise messaging
services
Tim: Is capturing both consumer and enterprise messaging in one protocol
(i.e. interop between iMessage and MS Teams) too much?
Rohan: Yeah, there are such use cases
Travis: Protocol should require minimal metadata to handle moderation or
trust&safety issues, then allow providers to require more metadata(?)
Raphael: Very tricky to identify minimal required metadata to enable
moderation. e.g.: how do you rate-limit if all clients are totally
anonymous?
-- note taker lost track here --
Rohan: Users can see each other's messages and identities, so could we
specify a mechanism for users to report abuse instead of enabling
servers to do it?
Travis: Is there a draft with this anywhere?
Raphael: There are some notes, but hope is to integrate this into
delivery service.
We need to do some threat modeling to understand how to enable
moderation and trust & safety stuff
Tim: Sounds like we want a draft discussing abuse threat models and
minimal moderation capabilities and corresponding required metadata
Mallory, Raphael and Travis volunteered to get that started