# MIMI Prague {#mimi-prague} ## Richard Barnes - Archicture Overview {#richard-barnes---archicture-overview} **Explanation of CSSC** * Each room in hosted at hub server * All comms go through the hub * Not every server wants to talk to others **Terminology** * Rooms are the unit of measurement: * They have a state, has a components of * auth policy, * users (participants), * MLS * Participants can be active/inactive **Preemption** * A user may be a participant only if authed * THe client can only be a member of the MLS group if particpant **Confirmation** 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 him. 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 group? 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 {#mimi-content-format-roan-mahy} **What's new?** * Abstract format for attachments, instead of message/external-body * Added discussion of encrypting external content * clarified difference between render and inline * created message\_id and timestamp. Inner message encrypted, the exteral message as an envelope. Given our purview, we cannot determine the inside. Looking for discussion around this. * Expanded definition on mentions and confusion attacks * lastSeen field 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 * with an ephemeral 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 message. 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** * Content format has messageid and timestamp chosen by encrypting client * Expose a copy of this in the MLS AAD * Local or hub ID can reject on duplicate IDs * Message ID is a UUID 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** * Is consistent rendering of sort order 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 whatever. 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 {#mimi-design-team-report} Agreed upon previously: * signalling is crypto agnostic, but we focus on MLS * As few documents as possible * Alice and Bob Four Documents * As described above by RM **MIMI Delivery Service** * Goal: specify a relatively generic MLS delivery service * new Interface section with capabilities * Ordering of handshake * Membership management * Proposal-commit logic * MLS specific verification * Tracking public group state * Assistance for joiners * Removed specialized add/remove/update operations * Now: Propose and Commit operations * Simpler interface for use by MIMI procotol **MIMI Protocol** * Room level operations * Signaling basedon events * room state changes based on MLS proposals * signaling proposals take immediate effect on room state * Makes use of MIMI DS * Commits anchor room state with 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. **Events** * m.room.user: change a participant list * m.room.info: get room info * ds.proposal: send MLS proposals * ds.commit: send MLS commits **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 it? 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 done. 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.