MIMI Prague

Richard Barnes - Archicture Overview

Explanation of CSSC



Different aspects of the state are managed via control sub protocols.
Each commit reflect the current room state.
All clients have a common understanding of the room state.

EKR: Same issue as last time. Imagine the ban use cas.
RB: The servers run a little bit ahead of the MLS group in the add case,
lags in the remove case, until the device is removed. You can set the
logic to make sure it happens.
EKR: Goes over a step by step. RB agrees.
RM: It's ok if there's inconsistency as we go through the process.

Lego Bricks Slide
New slide.
Maps documents to architecture

AC: Double checking for the documentation approach.
RB: Content and arch being separate is fine. Shouldn't confuse reading
too much, maybe a easier for the engineering.
DKG: Imagine EKR banned, how does the client know that we need to eject
RB: Great protocol question. We have to work on that exact description.

RM: Architecture should be a separate document.
RR: To DKG, both in the protocol and DS
A good reason to keep the DS separate for a super clean interface, and
can be reused in a different context, on purpose because it handles
client to server, not just server to server, which is the scope of MIMI.

EKR: The question is that do we specify the semantic transitions in this
RB: Yes, I think we cannot avoid it. Our building blocks have some
flexibility, but it's clear to all of us what playbook we are following.

AC: We want to specify, just haven't gotten it yet.
RR: Only has to be good enough for adoption, not last call.
RM: We need to have one way to do things, but we need to support the
actual stuff in the wild.
DKG: We are creating semantics that might eventually be surfaced by the
client. How is that going to change? AC: Conrad's the man, in his deck.

MIMI Content Format, Roan Mahy

What's new?

Attachments via External Content
New binary format modeled on message/exernal-body RFC 4483
sending client encrypts and uploads
External content encryption
When external content is encrypted

EKR: They can do a man in the middle attack by replacing the body. It
breaks the end-to-end integrity of MLS
KK: Do you specify how we generate the message ID?
DKG: This is the webbug issue? You can easily discover privacy content
if we do this.
RM: What do you want it to do? It depends on what your client wants /
needs you to do.
DKG: We kick these issues all the time, finally to the user who knows
not much. We are recapitulate this.
CJ: Quotas a really key. DKG is right, and I hate that we kick things
down the road. The transfer of large files will make the RIA shut you
down. Either you need to solve the privacy problem or the large file
problem, but they cannot be simultaneously solved.
MH: Matrix has wrestled with this.
EKR: Blockchain was a joke. It's a problem, and we still have HTML, so
might be difficult to solve the entire problem. Three peopole: sender,
hub and the receiving provider. The more you push it away from sender,
the more you walk down the chain of who needs to know about it.
JL: What would happen if you give the option of receiving very large
RM: This creates queing problems when you can catching up.
RR: You cannot have large messages in a messaging system. The mobile use
cases make this a non-starter
RB: I read jonathan's proposal differently.
Benjamin: Expresses privacy concerns

Sharing messageID and timestamp with providers

EKR: Why are we doing this?
RM: getting two messages simultaneous with the same message ID, because
we use them in replaces and reply-to fields, I can have a message that
refers to it. We need it for replaces.
DKG: Where do we need a non-hash message ID
RM: Clients do get confused and send the same content, at different
times. The timestamp is at encryption time. We do have a problem if they
don't know if they sent a message due to transactional problems.
EKR: Put a pin in this, we can solve that. What does the timestamp do?
RM: This is the time the client encrypted the message. We do need a way
for sort order
Jonathan: Is there a reason you aren't saying that wehave to use a key
commmiting AAD and the issues just go away?

Sort Order of Messages

CJ: Yes, of course you have to have a sort order that is consistent
MH: In matrix land, we go back and forth. We basically do not do this.
Opposite of CJ. We show in order of receipt.
CJ: Everyone needs to see the same thing. The mechanism of ordering is
EKR: How do you resolve the partial ordering question?
RM: We have no way ot getting at stuff below MLS, how do we get it from
the client?
DKG: Either we are giving user interface requirements, or we give the
causal order and each client renders

MIMI Design Team Report

Agreed upon previously:

Four Documents

MIMI Delivery Service

MIMI Protocol

RB: This protocol has a stack of proposals, the delta between the
current state and the future state. These proposals must be committed
before client comes online to commit them.
EKR: I'm confused, you said they would first be removed from MLS, then
moved from the higher level state
MH: Room state includes participant room changes, should we be tracking
items like name or avatar of the room.
TR: We are focusing on messaging list.
DKG: We need to flesh out the states.


Example Flow
Alice adds Bob example flow. See presentation

MH: Events: in matrix, happens in a room. Here, we use it as an RPC
mechanism, something that is happening to the room.
KK: Yes,it seems like a query response issue. So, events is what we call
AC: Who and when sets the policy for the room?
KK: We assume that policy is set on creation of the group, for now.
Prior to the keyfetch.
RB: We need to tackle issues of consent, not there yet.
RM: Consensus on direction?
AC: With ten readers, premature.
MH: Forgot to give his feeling, and is supportive of the work that was
AD: Generally agree that we are in the right direction. Thumbs up.
RR: Design team assigned ad-hoc, to resolve these issues, and to my mind
this has happened. We need to keep iterating, it's in the right
direction, we have reached consensus.