MIMI WG, IETF 116 Yokohama, 2023-03-30 Pete Resnick and Ben Campbell scribing https://datatracker.ietf.org/meeting/116/materials/agenda-116-mimi-03 # Agenda Bash, Administrativia, and WG Roadmap (Chairs) 10 minutes {#agenda-bash-administrativia-and-wg-roadmap-chairs-10-minutes} # Content format (Rohan Mahy) 30 minutes {#content-format-rohan-mahy-30-minutes} # Message transport and delivery {#message-transport-and-delivery} ## Matrix framework and linearized matrix (Matthew Hodgson) 7 minutes {#matrix-framework-and-linearized-matrix-matthew-hodgson-7-minutes} ## MIMI Transport Protocol (Jonathan Rosenberg) 7 minutes {#mimi-transport-protocol-jonathan-rosenberg-7-minutes} ## MIMI Delivery Service (Raphael Robert) 7 minutes {#mimi-delivery-service-raphael-robert-7-minutes} ## Discussion of transport requirements and trade-offs (Eric Rescorla) 40 minutes {#discussion-of-transport-requirements-and-trade-offs-eric-rescorla-40-minutes} # WG process going forward (Chairs) 10 minutes {#wg-process-going-forward-chairs-10-minutes} The Note Well was noted well. The agenda was bashed (with much silence) Chairs present a view of "building blocks" of the work being done. * Content format * Transfer and Delivery (aka transport) * MLS Profile * Identifier naming conventions * E2E identity Roadmap with prioritization proposed ( not strict ordering) 1. Content format 2. Message transfer protocol + identifier naming conventions 3. MLS profile 4. Identity Room is silently OK with the plan # Rohan Mahey presents MIMI Content format {#rohan-mahey-presents-mimi-content-format} https://www.ietf.org/archive/id/draft-mahy-mimi-content-02.html Issues that were on the list: 1. Should we repeat MLS info in the message container? Proposal to leave them out. (e.g. "To" and "From") Jonathan Rosenberg \[JDR\]: Prefer to have them in the message because the information is going to be used elsewhere. Better to have it self-contained. No harm to have it there. Daniel Gillmore \[DKG\]: I'm concerned about having them. But having them optional is worse. Need to make sure that the information is consistent between layers. Eric Rescola \[EKR\] (pretending to be DKG): There's no valid use for these in the message, and I share the concern that there could be conflicting data. Rohan: Group ID is the thing that is integrity protected. What you store might be something else that maps to the Group ID. E.g. Friend name or other local thing. Raphael Robert: Agree with EKR and DKG. The thing that you are using must be in MLS. Rohan: Sender might be pseudononymous for privacy reasons. Harald Alverstrand: It is possible to store the MLS values, because they're known to the sender beforehand. Suhas Nandakumar: (Satisfied that the information is appropriately protected.) Martin Dürst: For forwarding and similar operations where you imbed a message in another, you need this information. Rohan: By value or reference? Richard Barnes: MLS can authenticate multiple identifiers. In favor of including info. Cullen Jennings: I think this is too low level a detail to worry about now. Data will probably be copied, for example in message history. 1. How does the client know what formats are OK? MLS extensions let you advertise supported and required media types. Can be updated after creation. Request to address this on the list if there are concerns. 1. Threads vs. replies inReplyTo not for rendering order. Follows existing behavior. Some systems also have threading. Single ancestor message ID. inReplyTo in threads only useful for reactions. Does content format need specific rendering order? Proposal: no, use timestamp. Eric Rescorla: I think this is a bad idea. Prefers to specify explicit ordering. Would only do inReplyTo, not threads, let receiving system figure out how to render. Rohan: Prefers not to use inReplyTo for threads. DKG: I haven't been following closely. Trying to understand the semantics of threading. Is ancestor ID in thread? (yes). If a message in thread becomes an ancestor to another thread, what happens. Confusing, not sure how to render to user. Travis Ralston: Agrees threads and replies are different. Need replies in thread for larger conversations. Jonathan Rosenberg: Threads and replies are different. Defying user expectations is bad. Cross-system threads e.g.. Need to have both concepts. Bron Gondwana: This is different than the email model of InReplyTo. Cullen Jennings: We should provide just enough semantics so that we can map into the different clients, but not cause clients to provide different experiences. Rohan summarizes: A number of people agree that replies are different from email and for threading. Threading is underspecced and needs more work. Reasonable summary? Some folks agree, some unsure. Question on reports on multiple messages deferred to list. Next steps: Is this a reasonable start for semantics? Vittorio Bertola: Comment on earlier issue regarding message editing. Think it's a mess. Rohan suggests taking it to the list. DKG: No authorization control for editing messages. You just need to know message ID. UA needs to decide how to authorize. Draft is agnostic--this is fine, should not pretend to specificy authorization here. Chairs: Show of Hands for adoption. Lots of support, One objection, but nobody wanting to speak to it. Will confirm on the list, but looks like we will adopt. Harald: Process? Email or Github? Rohan + chairs: Both are fine, but please bring substantive changes to email. # Matrix framework and linearized matrix (Matthew Hodgson) {#matrix-framework-and-linearized-matrix-matthew-hodgson} https://datatracker.ietf.org/meeting/116/materials/slides-116-mimi-matrix-for-mimi https://datatracker.ietf.org/doc/draft-ralston-mimi-matrix-framework/ https://datatracker.ietf.org/doc/draft-ralston-mimi-linearized-matrix/ Matthew describes Matrix and how it maps to MIMI. No clariying questions. Will defer other discussion to later. # MIMI Transport Protocol (Jonathan Rosenberg) {#mimi-transport-protocol-jonathan-rosenberg} https://datatracker.ietf.org/meeting/116/materials/slides-116-mimi-mimi-transport-protocol-mtp https://datatracker.ietf.org/doc/draft-rosenberg-mimi-protocol Jonathan explains that the draft makes a series of strawman design decisions DKG: Is this message id the same as Rohan's? JDR: This one has to be different. DKG: Please use a different term. EKR: Not desirable to have both timestamps and message ids for synchronization. A hash would give you uniqueness. Get rid of timestamps and use hash. JDR: Good point. Just needs to be unique and increasing. EKR: Sync might still be tricky. Rohan: Cooperative validating is hard with encryption. Client needs to check consistency between inner thing and outer thing. DKG: \[missed comment. Seemed to be related to differentiating the inner and outer thing?\] # MIMI Delivery Service (Raphael Robert) {#mimi-delivery-service-raphael-robert} https://datatracker.ietf.org/meeting/116/materials/slides-116-mimi-mimi-delivery-service https://datatracker.ietf.org/doc/draft-robert-mimi-delivery-service Raphael describes the minimal/simplest delivery service Mallory Knodel: Owner of delivery service locks in users. Migration ability is needed for consumer services. Raphael: The only requirement is that the service decide in real-time. You could migrate so long as there is agreement in real-time. All that would be needed is an extension for moving to a new service. Mallory: May need to allow one of them to move. Raphael: Need to look at edge cases, but yes, sounds like this can be done. # Discussion of transport requirements and trade-offs (Eric Rescorla) {#discussion-of-transport-requirements-and-trade-offs-eric-rescorla} https://datatracker.ietf.org/meeting/116/materials/slides-116-mimi-mimi-transport-requirements EKR is not trying to prescribe outcome. Just discussion points. EKR time travels to last November. Q1: How much are we defining? Is client <-> server in scope? Raphael: I don't disagree with no client-server per se, but it's more nuanced. The open question is how does the delivery service fit it? We might need to have protocol from client to target service. Vittoria: I think we might want a standard protocol client-server, but not require it. DKG: This WG is more than what you're asking here. Just scoping this talk. JDR: Disagree with Raphael. I think this is strictly server-server; the entirety defines the delivery service. Travis Ralson: Client-server out of scope. Martin: Chat consistency might not be necessary. Ekr: encrypted content would break. Suhas: This should be s2s only. Timeliness of deliverables, and should put e2e in the right place. Rohan: Most people still don't understand that delivery service is abstract, and some of those pieces are going to be on the client and have client implications. We need to be clear about how we describe this to avoid bad implementation assumptions. Britta Hale: there are distributed settings where pure s2s management will not work. EKR: I think that's out of scope. Britta: Disagree. There might be temporary situations where you don't have access to servers. Joel (AWS): Ability to have client connect directly to the owning server has advantages. I think we should consider that. EKR: All of the proposals I've seen have been federated, so if we want to do that, we probably need a proposal. Matthew: +1 to others. Also, need to remember the user semantics and consider the presentation layer. Chairs: If there are non s2s proposals, please take concepts to list. Q2: Do we need to support discovery? Matthew: I (unfortunately) think it's going to be important to provide discovery. EKR: I really want to do that work, but I think it's hard and maybe for round 2. JDR: If we only support SSIs, the outcome is going to be probably unusable. Joris Baum: is feature discovery in scope? Ekr: For this work but not this layer. Jon Peterson: I think the discovery problem is interesting: Just knowing an SSI still might not get you everything you need. These might be decoupleable, but we're going to need discovery to make this workable. Chair: Sense that we landed on "Solve for SSI and plan on doing discovery eventually." Q3: Is consent required? What modes do we support? Raphael: MLS can do immediate. But we need consent mechanism. Not clear whether we want it to be a policy thing or an actual delivery thing. Cullen: Current systems sometimes tie this to something "a little expensive". I think to have a viable solution we're going to have to dig into the requirements. JDR: I was originally on consent only, but Alissa changed my mind: If it's unacceptable to the gatekeepers, we're done. We therefore should allow the protocol to allow variablity. Rohan: If we implement the full consent model, can we change later? EKR: I think we can. Travis: The quarantine mode is probably the one we want to shoot for. EKR: Any mechanism that allows immediate messages possibly leaks info, so that might tie in privacy. DKG: This is going to need to be negotiated; just one model won't work. Also, consent could be revoked. Jon: This is probably going to need a design document to sort this. Harald: The question is at the wrong level. The receiver needs to evaluate the local rules, and might need to ask the network for help to block. Policy is not part of transport protocol. Pete Resnick: Depending on scale of some providers, they might want to help before the receiver asks for help, and block before consent occurs. Need to put something in at provider level to require certain consent. Chairs: Out of time, more issues. External deadlines Need to start discussion threads on list. Kickstart series of virtual interims on regular cadence, starting in a couple of weeks. Doodle on list for timeslot. Ekr: Not a big fan of bi-weekly. Maybe interims less often? Chairs: Need process for agreeing on semi-stable draft versions as interop targets. Maybe regular deadlines for PRs. Asks for input. Discussion of whether we use github issues for discussion. Easier to have discussions on list in pre-doc phase.