# MIMI BoF IETF 115 London

2022-11-09 09:30 GMT - Kensington 1 - IETF 115 London

_notes: Brian Trammell + Phillip Hallam-Baker + Ryo Yanagida + (add yourself here)_

## Agenda Bash / Administrativia (Chairs) 5 minutes

agenda remains unbashed

note from the chair: interaction with regulatory requirements, not new for IETF. But today we're focused on the best technical solutions for the internet and its users.

## Problem statement (Rohan Mahy) 20 minutes

[slides](https://datatracker.ietf.org/meeting/115/materials/slides-115-mimi-mimi-problem-statement)

### Clarifying questions on problem statement

**Brian Trammell**: Question came up is are we looking for client-service interop or service-service interop? Is this left open, or will we make a decision.

**Rohan**: We are not up to making that decision now. If we are using MLS, the MLS clients on the services we use will have to have an intersecting set of policies that make things work. We need interoperability that makes this work.

**Brian**: What I am hearing is we don't know yet but this will be constrained by the MLS architecture.

**AJ. Beal**: ...want to make sure that identifier provides enough information to route to end-client, is this in scope?

**Rohan**: Not concerned; our system (e.g.) has this as a core part of the product.

**Matthew Hodgson**: giving the users ability to opt-in or out of being linked through to other services at all might be a thing that's out of scope. e.g. do you have an ability/semantics for a Signal group chat's members have message privacy control over which other _services_ are involved in a chat... users should be able to select where their conversations are going so they can maintain their metadata footprint.

**Rohan**: rephrasing, they can require metadata policies on a conversation-by-converation basis. think the current text covers that _recieves robocall_

**Alissa**: charter captures this as "respects user preferences re: discoverability"

**ekr**: three layers of requirements -- service-specific identifiers, unqualified names. eg. `@ekr`. next level is (hidden or unhidden) qualified indentfiers. e.g. `@ekr@wire`...  

**Rohan**: think that's requirements, not PS. 

**Jim Fenton**: re: need to understand what service a particular user uses. if these services become interoperable, why do you need to know?

**Rohan**: If I have a friend who is only on Mastodon, and I'm not, I need to somehow start the process, get an introduction, so I can route that message to them. 

**Jim**: You're saying the system needs to do that, or the users?

**Rohan**: Second problem: if you have something to search on, you need to get to something you can intro on. Not trying to be specific about this, person you are trying to contact needs to have control over what gets exposed where, there are privacy considerations, etc. 

**Jim**: Do you have to say "rafael on signal" or just "rafael"?

**Rohan**: Need a service to turn "rafael" into "which services does rafael prefer to be contacted on", then from there to "contact rafael on service"

**Alissa**: questions about how you do this are solution questions, not problem questions.

**Ben Campbell**: notably absent on your list of examples are phone numbers. is it in the identity draft?

**Rohan**: On the slide, in the PS.

**Ben**: Oops, missed that.

**Hans-jörg Happel**: interop driven by DMA. does this include GDPR portability? There seems to be quite some overlap in the data model. Don't just focus on interop, portability is also important.

**Rohan**: Thats an interesting problem but not in scope of DMA, and not in scope of this PS. Scope is already large.

**Harald Alvestrand**: Presence, this proposal never talks about presence and every single messaging system has one. And this is a major scaling issue, do we want to leave it out of scope.

**Rohan**: If your opinion is we need to have it... we can talk about that. My opinion is most people ignore it now. 

**Harald Alvestrand**: We should either rule this out of scope, or find a solutions.

**PHB**: We keep discussing end-to-end encryption of messages as if that is what gives security. It does not, it is a necessary but not sufficient condition. I do not have end-to-end security unless the endpoint I control provides or validates the public key. Depends very much where the mapping to identity happens. Appears there is an assumption that what's being built is a series of gateways. Analogy to pre-SMTP, we learned a while ago that manageability of this didn't scale very well.

**Rohan**: You're in full support of e2e identity, from your comments?

**PHB**: Yes

**Rohan**: There are proposals for hierarchical PKI, but there are also ways to do this with a mesh-based architecture

**PHB**: I do want e2e. But we need to be very careful about what "identity" means, it can be very fluffy.

**Jonathan Rosenberg**: Focus is not to build a whole new client and a whole new server and a chat system from scratch. That might be a side effect, but we start with an assumption that large, existing systems with billions of users already exist. So that points toward s2s. So for example, scale of presence systems isn't something we have to fix in the WG, but if providers have that information we'll need to figure out whether we want to interop that.

**Cullen Jennings**: I understand that phone numbers are in scope, and that if I have a phone number I can find them on one of multiple systems. Fundamental UX service -- if I have that, I don't want to have to know which service they are on.

**Rohan**: Let's look at the charter wording.

**Joris Baum**: You mentioned you wanted to prevent impersonation. There are some use-cases that wants impersonation. e.g. businesses where staffs represent one entity

**Rohan**: That's delegation.

**Antoine Fressencourt**: you want to specify an LCD among systems that provide IM? Or you're more interested in consisten experience? 

**Rohan**: Not sure I got the second option. Want to be able to send an IM to people on multiple different services. I want them to be able to reply with cat pictures. We're going to have a discussion about requirements... if rings are knocks or window vibe is a feature on some systems but not others,  a proprietary format might support that but base connectivity UX is good.

## Charter discussion (Chairs) 50 minutes

**Pete Resnick**: clarification on charter versus requirements. Not necessary to convince the IETF en plenary needs to be on board with a given requirement at the chartering stage, we can work out requirements (at the sub charter level) in the group.

**Alissa Cooper**: We have a couple of open PRs that I'd like to get to first.

### [PR 6 - Remove constraint that MIMI cannot specify new signalling protocols](https://github.com/coopdanger/ietf-wg-mimi/pull/6) 

There was some confusion here -- language here was meant to say "no new audio/video signaling", have edited the charter and closed the PR as addressed. Thumbs up in the room. No discussion

### [PR 5 - Add federation and message delivery](https://github.com/coopdanger/ietf-wg-mimi/pull/5)

**Raphael**: I think all the concerns have been addressed on this one. 

**Alissa**: including centralized control of content? clear on the list 

**Rohan**: Do you want the IETF to discuss this, or do you want us to discuss it in a WG? Adding more text here will cause confusion. Adding "avoid centralized control over content" will open up a can of worms at this stage 

**ekr**: I agree, this seems like overspec in the charter. Raphael's words look good to me.

**Matthew Hodgson**: may be missing some of the politics as to why this is an IETF level concern -- the charter now seemt ot imply this has to be centralized. If everyone is happy that it doesn't, then I'm happy.

**ekr**: if you can make this "not prescibing centralized" please do, but at this stage we don't want to prescribe "not centralizes"

**Matthew**: agreed

### [PR 4 - Which IM service(s)/vendor(s) shoud be decoupled from rest of user introduction](https://github.com/coopdanger/ietf-wg-mimi/pull/4) 

**Alissa**: Introduction problem. Solution is to add text to say the WG MAY investigate protocol for preferred application 

**Ted Hardie, Optimism Enthusiast**: way this PR is currently written needs a complete rewrite. as it is written it's completely separable. you could spin up a WG to do introduction without interop with this text. that's not, I think, what you want. what you want is "WILL consider protocol to allow conformant systems to introduce their subscribers across other conformant systems"

**Pete**: intro and discovery seem like different kinds of things. do you think they're intertwined?

**Ted**: That's a requirements question for the WG?

**Rohan**: "the working group may investigate a protocol for use with MIMI..."?

**Pete**: that seems like less restrictive than what I am protocol 

**Rohan**: if we add those four words that becomes a WG requirements question...

**Alissa**: I thought you were concerned about the prior sentence about the introduction problem as well

**Ted**: I have an AI to propose a PR. The general problem of solving introduction outide the MIMI scope 

**ekr**: given ID + service, arrange to connect A+B. that's introduction. consensus that we need to solve that. given unqualified ID, determine set of services. that's discovery. i can live with text that doesn't commit us to solving that.

**Cullen**: Want the WG to be able to decide that we can't do this if we can't. I don't like "new protocol" in the charter text because I think there are non-protocol solutions to the discovery problem

**PHB**: we seem to use "identity" and "user identifier" interchangeably. please nix the first usage for clarity. second, text on oracle to do user lookup isn't necessary. 

**Alissa**: I thought we meant two different things for "identity" and "user identifier". I'd like some input on that then.

**Jon Peterson**: still tension in charter structure. some messaging services preclude parts of discoverability by design, as part of the service. not by policy, but by design. this interacts a lot with discovery and introduction. is that "express user preference" also "properties of the systems"? Sometimes there are implicit user preferences by "the user is using service X". e.g. Spam/abuse often uses things that aren't expressed 

**Alissa**: We need to capture that. "Expressed and implied?" _nods in room_

**Peter Kasselman**: not sure that identifier/identity collapse makes sense.

**ekr**: Just filed PR10. Also has "implied".

**Rick Taylor**: Eric asked is discovery in or out? And we're talking about identity + identifiers. I think they're the same. Should identifier/identity be out of scope if discovery is out of scope?

**Alissa**: there are obvious dependencies here yes. charter needs to land on internal consistency.

**Pete**: I'm hearing charter should allow the group to take on discoverability but not require it.

**PHB**: Looking at DMA, what is the ask? Not "sit at my keyboard and find Pete Resnick". It's "if I know Pete, Pete can send me an identifier that allows me to talk to Pete". That's discovery, but it's more narrowly constrained. Looks kind of like a URI.

**Pete**: Please see if there's text you could change in the charter 

**Mallory Knodel**: This is not the interoperable identity BoF; we want to make sure that identity is in service of messaging. Now I understand why people don't want it -- interoperable identity probably won't work. Want to make sure identifiers are always in service of the messaging piece. 

**Harald Alvestrand**: The words application and service are used in this charter also seem like they are mostly pointing to the same thing. If we are focusing on the gateway problem, we should use "service".

### [PR 10 - Discovery vs introduction](https://github.com/coopdanger/ietf-wg-mimi/pull/10) 

**Rohan**: If people like PR10, I'm happy to drop PR4.

**Alissa**: Ted should look at this.

**Ted**: We need to rebase but we're converging.

**Alissa**: We can resolve differences after the BoF.


### [PR 7 - explicitly include user data/metadata residency preference](https://github.com/coopdanger/ietf-wg-mimi/pull/7) 

**ekr**: Too detailed/specific. 

**Raphael**: Agree. Metadata has not been introduced as a term so far. This is oddly specific. If you want to bring it in needs to be much more comprehensive.

**Jonathan**: Expressed and implied preferences allows the WG to have this discussion, don't think PR7 is needed.

**Brendan Moran**: Data and metadata residency is an important problem. Prefer this in the charter.

**Mallory**: Remove the word 'express'. Tend to agree that we don't need to be specific on metadata in the charter.

**Alissa**: Do user preferences imply expression?

**Mallory**: No. You need to ask now. We're not okay with it being implied anymore; we need to make implied preferences invisible. Remove "expressed/implied" and we can tackle this in the WG.

**Vittorio Bertola**: Need to keep the ability for user to specify data/metadata residency.

**Jon Peterson**: People choose systems based on their properties. Social media fundamentally altered this dynamic. Think it's unrealistic to make *all* preferences expressed, and orthogonal to the problem we're trying to solve.

**Jon**: Unfortunate interaction among spam-not-in-scope, taking on introduction, and expressed/implied interaction, think we need to discuss this more before convering on charter.

**Alissa**: Contradicting myself 20 minutes ago. Given that all closed systems offer controls, if you are already controlling who can reach you, that needs to extend to the wider system. Do you not think systems will offer those controls to their systems? Mallory's point about making things explcit -- that's going to happen as part of opening up those systems.

**Jon**: Many platforms have default out of the box behavior. We don't want to force MIMI compliant systems to drop those defaults. We obviously need to take this to the list. "Expressed and implied user prefs" work for me; just "user prefs"

**Mark Nottingham**: the language "must be respected" seems odd, because this is effectively untestable. "must be respected" seems regulatory. Do we mean "must be able to be expressed"? Enforcing data residency in the protocol is very hard.

**Alissa**: Agreed, but there are some mechanisms we're envisioning that are more or less compatible with enforcing some preferences.

**Philip**: Language is not right. Now we're talking about access control. We have an authorization problem. 

**Pete**: I'm hearing PR7 doesn't handle the problem. This needs to go back to the list.

**Alissa**: Closing the queue on this.

**Jonathan Rosenberg**: All of this should happen in the WG. Also: the DMA has a deadline.

**Ted Hardie, Scope Enthusiast**: Some of the problem goes back to Brian's question at the beginning - are you building an overlay? That overlay may have noninherited defaults. The WG has to define the properties of that overlay -- we're not solving this broadly, just per overlay. 

**Cullen**: given timing would like to resolve some text right now for "leave it to the WG".

**David**: Happy to close the PR if... 

## BOF questions (Chairs) 15 minutes

### Does anyone think the PR is unclear or poorly scoped?

**David Venhoek**: Worried about the impact of putting spam out of scope. 

**Jim Fenton**: Draft charter is motivated by user experience. Rohan's draft talks about the DMA. If we need to satisfy particular regulatory requirements, it needs to be in the charter. UX is not sufficient for deployment.

**Alissa**: Left out of the charter because reference to external regulation is odd in an IETF context. Does that have an impact on PS scope.

**Vittorio**: agree, don't leave spam out. needs to be clear DMA is a motivating factor, if not in charter.

**Eric Rescorla**: Don't put DMA in charter, DMA requirements are quite vague. I'm torn on spam and abuse. We're not going to solve it. Platform-specific ways of solving it. Wonder how we can finesse this in the charter. But no charter is find.

**Alissa**: Closing the queue on this now. 

**Matthew Wild**: Understand not wanting to make the WG about the DMA, but do need to recognize that it's a motivation.

**Rohan**: Spam is specifically mentioned. Problem statement does include it but needs work in the later phase. 

**Jonathan Rosenberg**: We will not not discuss spam. Probability is zero. We all understand risks and challenges. Charter is fine as it is. Charter is not to build a spam mitigation. We're doing messaging interop, inclusive of minimizing spam

**Jon Peterson**: PS is clear. Want to make sure we encompass how these services work.

### Does anyone object to forming a working group with this proposed charter, modulo changes discussed today? 

No.

Positive feedback: loud hum and several +1. 

### Documents - review?

A third of the room

### Documents - authors?

Many. Murray has photos.

### Chair/Co-chair?

A few. Please go talk to Murray.

### Anyone interested in implementing?

Some. Murray has photos.

## Solution space discussion (time permitting)