[{"author": "Jonathan Rosenberg", "text": "

the audio volume from the mic is low, hard to hear alan

", "time": "2023-11-10T14:33:33Z"}, {"author": "Alissa Cooper", "text": "

we'll ask people to eat the mic

", "time": "2023-11-10T14:34:12Z"}, {"author": "Daniel Gillmor", "text": "

@Meetecho Robot see:
\nJonathan Rosenberg said:

\n
\n

the audio volume from the mic is low, hard to hear alan

\n
", "time": "2023-11-10T14:34:30Z"}, {"author": "Lorenzo Miniero", "text": "

Monitoring, please hang on

", "time": "2023-11-10T14:34:47Z"}, {"author": "Daniel Gillmor", "text": "

no one at the mic now, sorry :sad:

", "time": "2023-11-10T14:34:58Z"}, {"author": "Alissa Cooper", "text": "

https://github.com/bifurcation/ietf-mimi-protocol/issues/23

", "time": "2023-11-10T14:35:07Z"}, {"author": "Pete Resnick", "text": "

@Jonathan Rosenberg Can you hear the stage mic now?

", "time": "2023-11-10T14:35:25Z"}, {"author": "Ted Hardie", "text": "

Chairs, can you make the issue text larger on your screens? it's an eye chart.

", "time": "2023-11-10T14:35:32Z"}, {"author": "Raphael Robert", "text": "

+1 for encryption

", "time": "2023-11-10T14:36:00Z"}, {"author": "Tim Geoghegan", "text": "

How is that @Ted Hardie?

", "time": "2023-11-10T14:36:42Z"}, {"author": "Daniel Gillmor", "text": "

the point is that any unencrypted state will be visible to the hub and the servers.

", "time": "2023-11-10T14:37:06Z"}, {"author": "Tim Geoghegan", "text": "

https://github.com/bifurcation/ietf-mimi-protocol/issues/23 so you can follow along

", "time": "2023-11-10T14:37:08Z"}, {"author": "Jonathan Hoyland", "text": "

As long as that state doesn't leak too much information. Unencrypted room names like \"wire fraud\" might be compromising.

", "time": "2023-11-10T14:38:48Z"}, {"author": "Giles Hogben", "text": "

size limits?

", "time": "2023-11-10T14:39:11Z"}, {"author": "Jonathan Hoyland", "text": "

You just know that people will use this to share MeMoji

", "time": "2023-11-10T14:39:49Z"}, {"author": "Jonathan Hoyland", "text": "

@Konrad Kohbrok Oh ouch, that sounds really hard.

", "time": "2023-11-10T14:41:33Z"}, {"author": "Konrad Kohbrok", "text": "

Yeah, it's a very annoying problem.

", "time": "2023-11-10T14:41:53Z"}, {"author": "Benjamin Schwartz", "text": "

I do wonder about this would work in chat systems that have a room directory (like Zulip!). Is there some room metadata that is public?

", "time": "2023-11-10T14:43:05Z"}, {"author": "Richard Barnes", "text": "

+1 to Rohan planning to punt for now

", "time": "2023-11-10T14:43:14Z"}, {"author": "Daniel Gillmor", "text": "

@Benjamin Schwartz there is already room metadata made public, no? or at least, visible to the server, and which the server will provide to someone who knows how to query it.

", "time": "2023-11-10T14:45:04Z"}, {"author": "Raphael Robert", "text": "

@Benjamin Beurdouche we could look into doing an MLS extension perhaps

", "time": "2023-11-10T14:45:22Z"}, {"author": "Benjamin Beurdouche", "text": "

Definitely, and to be clear, I was thinking of the storage part not about the room data

", "time": "2023-11-10T14:46:18Z"}, {"author": "Daniel Gillmor", "text": "

@Richard Barnes yes, i intend there to be room state that is confidential (hidden from the servers)

", "time": "2023-11-10T14:46:58Z"}, {"author": "Benjamin Beurdouche", "text": "

@Richard Barnes we want encryption, relaxing it is easy enough

", "time": "2023-11-10T14:47:05Z"}, {"author": "Richard Barnes", "text": "

I guess we probably need both provider-visible and provider-confidential buckets of state

", "time": "2023-11-10T14:47:34Z"}, {"author": "Daniel Gillmor", "text": "

as a simple example, there's no reason that the server needs to know the avatar for the group

", "time": "2023-11-10T14:47:43Z"}, {"author": "Richard Barnes", "text": "

maybe to @Rohan Mahy's point, the room policy already handles the visible part

", "time": "2023-11-10T14:48:05Z"}, {"author": "Daniel Gillmor", "text": "

right, things will get stuffed into the policy if we don't care about it being visible.

", "time": "2023-11-10T14:48:43Z"}, {"author": "Richard Barnes", "text": "

it occurs to me that we probably need a scrollback mechanism here for apps that provide history to new joiners. that mechanism would also support room state encryption.

", "time": "2023-11-10T14:48:53Z"}, {"author": "Jonathan Hoyland", "text": "

So what I was thinking about was something like https://en.wikipedia.org/wiki/Proxy_re-encryption

", "time": "2023-11-10T14:50:10Z"}, {"author": "Benjamin Schwartz", "text": "

@Richard Barnes Scrollback sounds like an even harder problem, cryptographically.

", "time": "2023-11-10T14:50:13Z"}, {"author": "Konrad Kohbrok", "text": "

I would leave scrollback out of this and look at it as a separate issue with a separate set of requirements.

", "time": "2023-11-10T14:50:58Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Hoyland doesn't that use a hybrid scheme, where the underlying symmetric key will remain the same?

", "time": "2023-11-10T14:51:01Z"}, {"author": "Benjamin Beurdouche", "text": "

+1 to Raphael: encryption by default and relax for specific use cases

", "time": "2023-11-10T14:51:29Z"}, {"author": "Richard Barnes", "text": "

@Benjamin Schwartz - I think it's actually equivalent at the crypto level. Either way, you're propagating information to future members.

", "time": "2023-11-10T14:51:32Z"}, {"author": "Daniel Gillmor", "text": "

if the epoch transition is due to a user removal, then leaving the symmetric key the same leaves the data vulnerable.

", "time": "2023-11-10T14:51:35Z"}, {"author": "Jonathan Hoyland", "text": "

@Daniel Gillmor I think that's a potential optimisation, but not a necessary part of the scheme

", "time": "2023-11-10T14:51:49Z"}, {"author": "Daniel Gillmor", "text": "

i share the fear about scrollback. i'd leave that out for this first pass.

", "time": "2023-11-10T14:52:10Z"}, {"author": "Richard Barnes", "text": "

maybe scrollback is a little harder, since you won't be changing the room state in every epoch

", "time": "2023-11-10T14:52:30Z"}, {"author": "Tim Geoghegan", "text": "

https://github.com/bifurcation/ietf-mimi-protocol/issues/33

", "time": "2023-11-10T14:53:47Z"}, {"author": "Daniel Gillmor", "text": "

can someone speak to the shape of the authentication mechanism needed?

", "time": "2023-11-10T14:56:27Z"}, {"author": "Rohan Mahy", "text": "

Richard Barnes said:

\n
\n

it occurs to me that we probably need a scrollback mechanism here for apps that provide history to new joiners. that mechanism would also support room state encryption.

\n
\n

I think that is explicitly out of scope. Wasn't that one of the things we discussed excluding it in the charter?

", "time": "2023-11-10T14:57:27Z"}, {"author": "Benjamin Beurdouche", "text": "

@Konrad Kohbrok So it is more an authorization problem than an auth one right ?

", "time": "2023-11-10T14:58:48Z"}, {"author": "Rohan Mahy", "text": "

@Benjamin Beurdouche yes

", "time": "2023-11-10T14:59:08Z"}, {"author": "Daniel Gillmor", "text": "

Benjamin Beurdouche said:

\n
\n

Konrad Kohbrok So it is more an authorization problem than an auth one right ?

\n
\n

This is why we should never ever use the word \"auth\" :rolling_on_the_floor_laughing:

", "time": "2023-11-10T15:00:41Z"}, {"author": "Konrad Kohbrok", "text": "

Fair point!

", "time": "2023-11-10T15:01:02Z"}, {"author": "Richard Barnes", "text": "

authN / authZ !

", "time": "2023-11-10T15:01:50Z"}, {"author": "Rohan Mahy", "text": "

There is some information here that might help @Daniel Gillmor
\nhttps://www.ietf.org/archive/id/draft-mahy-mimi-transport-design-reqs-00.html#name-claiming-a-single-use-keypa
\nand
\nhttps://www.ietf.org/archive/id/draft-mahy-mimi-group-chat-00.html#name-fetch-keypackages

", "time": "2023-11-10T15:01:57Z"}, {"author": "Konrad Kohbrok", "text": "

I did mean authentication, though. You need to authenticate the sender before you make an authorization decision. Authentication is more my department than authorization, hence the note.

", "time": "2023-11-10T15:03:08Z"}, {"author": "Daniel Gillmor", "text": "

@Konrad Kohbrok it's certainly possible to do blinded authorization that does not require authentication, in some contexts.

", "time": "2023-11-10T15:03:34Z"}, {"author": "Jonathan Hoyland", "text": "

@Richard Barnes I think you mean authN and authS :joy: :flag_united_kingdom:

", "time": "2023-11-10T15:03:36Z"}, {"author": "Daniel Gillmor", "text": "

whether those contexts apply here, i don't know, but it's a common antipattern for people who spend their lives thinking about authentication to think that it's required for authorization.

\n

for example, the clerk at the store needs to know that i'm 21+ years old to be authorized to buy beer, but they don't need to authenticate my identity.

", "time": "2023-11-10T15:04:49Z"}, {"author": "Rohan Mahy", "text": "

Konrad Kohbrok said:

\n
\n

I did mean authentication, though. You need to authenticate the sender before you make an authorization decision. Authentication is more my department than authorization, hence the note.

\n
\n

I think the provider holding KeyPackages needs to be able to authorize someone who wants to claim them. It might be that the requestor is traditionally authenticated. It might be that the only authorization is some type of quota.

", "time": "2023-11-10T15:05:37Z"}, {"author": "Jonathan Hoyland", "text": "

We're going to end up in the \"stick a key in DNS\" solution space for this, right?

", "time": "2023-11-10T15:06:24Z"}, {"author": "Benjamin Beurdouche", "text": "

Nooooo

", "time": "2023-11-10T15:06:34Z"}, {"author": "Giles Hogben", "text": "

We have requirements in our draft too

", "time": "2023-11-10T15:08:49Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I think Jon is proposing a design team :wink:

", "time": "2023-11-10T15:09:15Z"}, {"author": "Jonathan Hoyland", "text": "

I think the previous slides need to be unshared first

", "time": "2023-11-10T15:09:59Z"}, {"author": "Jonathan Rosenberg", "text": "

I strongly disagree with the statement that the authentication part is not a problem.

", "time": "2023-11-10T15:11:09Z"}, {"author": "Jonathan Rosenberg", "text": "

I also dont agree that the harder problem is the distribution problem, but proceed ;)

", "time": "2023-11-10T15:11:37Z"}, {"author": "Benjamin Schwartz", "text": "

SSL S/MIME STIR

", "time": "2023-11-10T15:11:56Z"}, {"author": "Femi Olumofin", "text": "

The point is that the auth part isn't a new problem.

", "time": "2023-11-10T15:12:00Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Rosenberg you're saying \"authentication is part of the problem\" and \"verification is harder than distribution\", right?

\n

(i'm just trying to clarify)

", "time": "2023-11-10T15:12:21Z"}, {"author": "Jonathan Rosenberg", "text": "

This is not hard from a crypto perspective (its another cert, right?) the problem is building a system that has enough trust for such a certificate to be generated for phone number ownership.

", "time": "2023-11-10T15:14:40Z"}, {"author": "Jonathan Lennox", "text": "

Someone you message doesn't necessarily learn your SII, just your SSI, yes? Though we might want SII distribution to be part of the messaging system.

", "time": "2023-11-10T15:15:14Z"}, {"author": "Femi Olumofin", "text": "

Right. But the originator of the message needs to discover the SSI using the recipient's SII.

", "time": "2023-11-10T15:16:26Z"}, {"author": "Jonathan Hoyland", "text": "

For example MeetEcho users :flushed:

", "time": "2023-11-10T15:20:44Z"}, {"author": "Vittorio Bertola", "text": "

Jonathan Hoyland said:

\n
\n

We're going to end up in the \"stick a key in DNS\" solution space for this, right?

\n
\n

That's the core of my draft, which will come after this one

", "time": "2023-11-10T15:22:18Z"}, {"author": "Antoine Fressancourt", "text": "

in SIP / SIMPLE there is a event that alows you to monitor who is rying to discover you, and as a user you may accept or not this person as an observer of, say, your privacy

", "time": "2023-11-10T15:22:38Z"}, {"author": "Antoine Fressancourt", "text": "

s/privacy/presence

", "time": "2023-11-10T15:23:10Z"}, {"author": "Femi Olumofin", "text": "

The relationship or social graph is what the user would like to hide.

", "time": "2023-11-10T15:25:06Z"}, {"author": "Daniel Gillmor", "text": "

hiding the querier is not just an IP address property

", "time": "2023-11-10T15:25:24Z"}, {"author": "Daniel Gillmor", "text": "

especially if we're talking about authorization for these queries (which might end up being authentication steps)

", "time": "2023-11-10T15:25:54Z"}, {"author": "Femi Olumofin", "text": "

Right. The is not about being anonymous. But hiding the request and response from the Discovery Provider.

", "time": "2023-11-10T15:26:59Z"}, {"author": "Mallory Knodel", "text": "

(deleted)

", "time": "2023-11-10T15:28:17Z"}, {"author": "Vittorio Bertola", "text": "

I emphatically disagree with slide 7.

", "time": "2023-11-10T15:28:27Z"}, {"author": "Alissa Cooper", "text": "

@mallory he is not talking about the privacy of the user doing the query

", "time": "2023-11-10T15:29:03Z"}, {"author": "Mallory Knodel", "text": "

I stand corrected

", "time": "2023-11-10T15:29:04Z"}, {"author": "Femi Olumofin", "text": "

Right Mallory.

", "time": "2023-11-10T15:29:11Z"}, {"author": "Mallory Knodel", "text": "

No I wasn\u2019t either AC

", "time": "2023-11-10T15:29:23Z"}, {"author": "Richard Barnes", "text": "

@Benjamin Schwartz - nothing about this requires providers to use SIIs. are you saying that it needs to be possible for privacy-oriented providers to use SIIs without revealing whether the SIIs have presence on that service?

", "time": "2023-11-10T15:29:28Z"}, {"author": "Mallory Knodel", "text": "

But slide 7 undermined my assumption.

", "time": "2023-11-10T15:29:32Z"}, {"author": "Richard Barnes", "text": "

(tbh, using SIIs seems like kind of an anti-pattern, anyway, and we're only doing anything here because of the awful state of the art)

", "time": "2023-11-10T15:29:56Z"}, {"author": "Daniel Gillmor", "text": "

@Richard Barnes i agree that it's ugly, but it has incredibly appealing properties for driving adoption based on network effects.

", "time": "2023-11-10T15:31:18Z"}, {"author": "Benjamin Schwartz", "text": "

@Richard Barnes I think SIIs are incredibly valuable for mobility across services, and I would encourage people to use them.

", "time": "2023-11-10T15:31:22Z"}, {"author": "Daniel Gillmor", "text": "

telling adopters that they don't have a way to do that is going to limit uptake.

", "time": "2023-11-10T15:31:35Z"}, {"author": "Tim Geoghegan", "text": "

There's no disagreement on MIMI having to work with SIIs.

", "time": "2023-11-10T15:32:14Z"}, {"author": "Vittorio Bertola", "text": "

It should be up to the user to decide whether they want to be reachable on MIMI via their phone number or not.

", "time": "2023-11-10T15:32:21Z"}, {"author": "Daniel Gillmor", "text": "

if i control phone number X (an SII), and i have an account Y on service Z (an SSI), i should not be obliged to connect the two.

", "time": "2023-11-10T15:33:49Z"}, {"author": "Jonathan Rosenberg", "text": "

To answer Mallory's comment - if a provider doesnt want its users to be discoverable by SII, they would elect not to enroll in this system.

", "time": "2023-11-10T15:34:01Z"}, {"author": "Mallory Knodel", "text": "

Why would SII be different from reachability information on this slide

", "time": "2023-11-10T15:34:19Z"}, {"author": "Jonathan Lennox", "text": "

It's certainly possible to run a service that has the policy that \"the only way you can reach our users is as private-user-id@ourservice\"

", "time": "2023-11-10T15:34:29Z"}, {"author": "Femi Olumofin", "text": "

@Daniel Agree. It's the user's choice.

", "time": "2023-11-10T15:34:38Z"}, {"author": "Jonathan Rosenberg", "text": "

Not SII

", "time": "2023-11-10T15:34:43Z"}, {"author": "Mallory Knodel", "text": "

That\u2019s right and so what\u2019s the point of defining more than that

", "time": "2023-11-10T15:34:48Z"}, {"author": "Daniel Gillmor", "text": "

I think \"service reachability\" in this slide is shorthand for \"reaching the person attached to a given SII, based only on the SII itself\"

", "time": "2023-11-10T15:35:02Z"}, {"author": "Jonathan Lennox", "text": "

But many services instead have the policy that they want you to be able to look their users up by phone number, so their users can transition easily from existing address books.

", "time": "2023-11-10T15:35:18Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Lennox right, that's the seductive network effect

", "time": "2023-11-10T15:35:45Z"}, {"author": "Mallory Knodel", "text": "

How is that a protocol level consideration

", "time": "2023-11-10T15:35:50Z"}, {"author": "Richard Barnes", "text": "

i wonder if we can sort of punt on this by saying that different providers can apply different access controls on their mappings?

", "time": "2023-11-10T15:35:51Z"}, {"author": "Mallory Knodel", "text": "

This does not need defining

", "time": "2023-11-10T15:36:25Z"}, {"author": "Daniel Gillmor", "text": "

@Richard Barnes if this were all framed as \"recommended privacy enhancing strategies for those providers with a user who wants to map their accounts to an SII\" then it would be much more reasonable

", "time": "2023-11-10T15:36:42Z"}, {"author": "Richard Barnes", "text": "

like if Google wants to publish theirs, great. if SecretMessenger only wants users to be discoverable if they have an intro code, they can use the same distribtion protocol with a different access control.

", "time": "2023-11-10T15:36:52Z"}, {"author": "Antoine Fressancourt", "text": "

It becomes a protocol consideration if we want to havea message warnng the userof an ongoing discovery, and ask him to act on this request

", "time": "2023-11-10T15:37:03Z"}, {"author": "Vittorio Bertola", "text": "

In any case, I think we'd better work and reach consensus on a requirements draft before discussing discovery mechanisms.

", "time": "2023-11-10T15:38:26Z"}, {"author": "Benjamin Schwartz", "text": "

@Antoine Fressancourt Exactly. If discovery can be interactive, then I can choose whether or not to reveal to a specific requestor that my SII is mapped on this service.

", "time": "2023-11-10T15:38:34Z"}, {"author": "Pete Resnick", "text": "

VRFY vs EXPN back in old email land.

", "time": "2023-11-10T15:38:51Z"}, {"author": "Jonathan Hoyland", "text": "

What if a single phone number is bound to a number of accounts? This seems to be a many-many mapping?

", "time": "2023-11-10T15:38:53Z"}, {"author": "Antoine Fressancourt", "text": "

@Ben exactly

", "time": "2023-11-10T15:38:55Z"}, {"author": "Antoine Fressancourt", "text": "

@Pete Observer event according to RFC 3265

", "time": "2023-11-10T15:39:26Z"}, {"author": "Mallory Knodel", "text": "

If discovery is conservative by default it doesn\u2019t need defining\u2014 this is the essence of my comment (the terminology is messy but now cleared up thanks AC)

", "time": "2023-11-10T15:39:29Z"}, {"author": "Daniel Gillmor", "text": "

@Pete Resnick you don't mean to say that we've done this before, do you?

\n

:zombie::zombie::zombie::zombie::zombie:

", "time": "2023-11-10T15:39:44Z"}, {"author": "Mallory Knodel", "text": "

It\u2019s an on/off, discover me or don\u2019t.

", "time": "2023-11-10T15:40:20Z"}, {"author": "Antoine Fressancourt", "text": "

I think it is more subbtle than an On / off. I want my friends or people I value to discover me, not the commercial prospectors, for instance

", "time": "2023-11-10T15:41:15Z"}, {"author": "Rohan Mahy", "text": "

I think what Alissa said is that these are 3 different things:

\n", "time": "2023-11-10T15:41:23Z"}, {"author": "Jonathan Rosenberg", "text": "

Jon makes a great point - its sort of the old \"proxy vs. redirect\" models in SIP

", "time": "2023-11-10T15:42:37Z"}, {"author": "Vittorio Bertola", "text": "

Antoine Fressancourt said:

\n
\n

I think it is more subbtle than an On / off. I want my friends or people I value to discover me, not the commercial prospectors, for instance

\n
\n

That's the kind of thing that you achieve by having a non-guessable, specific identifier that you only give to desired parties out of band. But phone numbers nowadays are not really fit for that

", "time": "2023-11-10T15:42:45Z"}, {"author": "Mallory Knodel", "text": "

Antoine should we really make those distinctions for a protocol?

", "time": "2023-11-10T15:43:15Z"}, {"author": "Mallory Knodel", "text": "

Genuine question I guess we could but why not leave it to services to deal with that

", "time": "2023-11-10T15:44:12Z"}, {"author": "Antoine Fressancourt", "text": "

@Vittorio I disagree. If I have a publicly available identifier that i snot tied to a given service provider, then a request/answer interactive authorization model can work without multiplying pseudonyms

", "time": "2023-11-10T15:44:14Z"}, {"author": "Jonathan Lennox", "text": "

@Jon Peterson: The way TNs are used for SMS/Phone calls is very different from the way TNs are used by OTT providers like Signal or Messages or WhatsApp. This is very much thinking about the latter model, while it seems to me like you're thinking about the former?

", "time": "2023-11-10T15:44:43Z"}, {"author": "Antoine Fressancourt", "text": "

@Mallory, at least they were made in the SIP / SIMPLE days

", "time": "2023-11-10T15:44:55Z"}, {"author": "Jonathan Rosenberg", "text": "

I think Ted is basically saying this is tit-for-tat - to get this information, you need to give something in return.

", "time": "2023-11-10T15:45:32Z"}, {"author": "Benjamin Schwartz", "text": "

@Mallory Knodel As an example, discovery could work as a specially formed chat message that travels all the way to the actual client, where it can be answered interactively or automatically. If there is no matching client for the SII, the message could be dropped silently. But that requires a bunch of protocol elements to work.

", "time": "2023-11-10T15:45:52Z"}, {"author": "Jonathan Rosenberg", "text": "

@benjamin - this is exactly how my initial SPIN proposal worked...

", "time": "2023-11-10T15:47:00Z"}, {"author": "Mallory Knodel", "text": "

A bunch?

", "time": "2023-11-10T15:47:11Z"}, {"author": "Jonathan Rosenberg", "text": "

ooooh thats a good comment @daniel

", "time": "2023-11-10T15:48:09Z"}, {"author": "Jonathan Lennox", "text": "

Or even for phone numbers SIM-swapping for different countries is a thing.

", "time": "2023-11-10T15:48:38Z"}, {"author": "Benjamin Schwartz", "text": "

@Jonathan Rosenberg IIRC that was on the SMS network. This would be on the MIMI network. (Naively, this would require pinging many different providers hoping to get a response, so it's probably not workable in quite the way I'm describing it.)

", "time": "2023-11-10T15:48:48Z"}, {"author": "Mallory Knodel", "text": "

Just because someone knows my phone number doesn\u2019t mean they get to deliver a message to me. It goes to the \u201crequest\u201d inbox on my app until I accept it.

", "time": "2023-11-10T15:49:03Z"}, {"author": "Jonathan Lennox", "text": "

Mallory: sure, but that means they need to be able to reach your \"request\" inbox.

", "time": "2023-11-10T15:49:31Z"}, {"author": "Daniel Gillmor", "text": "

when all else fails, add another layer of indirection!

", "time": "2023-11-10T15:50:06Z"}, {"author": "Mallory Knodel", "text": "

My high level question is why we are not designing for the bare minimum case. Let the service implement on top if they want

", "time": "2023-11-10T15:50:07Z"}, {"author": "Antoine Fressancourt", "text": "

@Mallory to do that in an interoperable, multi-provider way there is a need to have, like, an interoperable protocol for doing this

", "time": "2023-11-10T15:50:32Z"}, {"author": "Daniel Gillmor", "text": "

@Mallory Knodel if we can see that services are likely to try to provide these mappings, it might be useful to establish a best practice baseline (and mechanism) to avoid them rolling out really horrible designs.

", "time": "2023-11-10T15:50:55Z"}, {"author": "Benjamin Beurdouche", "text": "

Mallory Knodel said:

\n
\n

Just because someone knows my phone number doesn\u2019t mean they get to deliver a message to me. It goes to the \u201crequest\u201d inbox on my app until I accept it.

\n
\n

Should it even be able to fetch a public key for your client ? Maybe no if you decided not to be discoverable ?

", "time": "2023-11-10T15:51:09Z"}, {"author": "Jonathan Lennox", "text": "

Yeah, the goal is that you don't have to be a WhatsApp customer for WhatsApp users to find you, based on address books they already have.

", "time": "2023-11-10T15:51:20Z"}, {"author": "Daniel Gillmor", "text": "

and they will try to roll these out, because it makes it much easier to onboard and interconnect users (c.f. Signal's rollout)

", "time": "2023-11-10T15:51:32Z"}, {"author": "Jonathan Hoyland", "text": "

It's also not clear to me what it means if I use the same handle on different MLS servers. Can I prove that they're all bound if I _do_ want to?

", "time": "2023-11-10T15:51:35Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Hoyland https://codeberg.org/dkg is not me :sad:

", "time": "2023-11-10T15:52:13Z"}, {"author": "Jonathan Hoyland", "text": "

Exactly, I want to be able to say \"these ones are me, those ones aren't.\"

", "time": "2023-11-10T15:52:37Z"}, {"author": "Jonathan Lennox", "text": "

It's not just individual service providers' desire to make interconnect easier - it's also regulators' desire to make it easier for competing providers not to be disadvantaged vs. dominant ones.

", "time": "2023-11-10T15:53:12Z"}, {"author": "Alissa Cooper", "text": "

yes, there is a trade-off between designing something that any provider wants to use vs. not standardizing anything

", "time": "2023-11-10T15:54:57Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Hoyland how about \"please contact me over at the dkg@foo.example SSI instead, i'd rather talk to you on FooServer\u2122\"?

", "time": "2023-11-10T15:54:57Z"}, {"author": "Jonathan Lennox", "text": "

Jonathan Hoyland: I don't think it's possible to prove \"these ones aren't\", but the former, sure - that's the PKI model, verified (probably) by the ability to receive SMS messages at the given phone number.

", "time": "2023-11-10T15:55:12Z"}, {"author": "Daniel Gillmor", "text": "

ability to receive SMS :rolling_on_the_floor_laughing: :cry:

", "time": "2023-11-10T15:55:37Z"}, {"author": "Jonathan Lennox", "text": "

(Or e-mail address equivalently)

", "time": "2023-11-10T15:55:41Z"}, {"author": "Jonathan Lennox", "text": "

That's how all these services make things work today...

", "time": "2023-11-10T15:55:57Z"}, {"author": "Rohan Mahy", "text": "

Vittorio Bertola said:

\n
\n

Antoine Fressancourt said:

\n
\n

I think it is more subbtle than an On / off. I want my friends or people I value to discover me, not the commercial prospectors, for instance

\n
\n

That's the kind of thing that you achieve by having a non-guessable, specific identifier that you only give to desired parties out of band. But phone numbers nowadays are not really fit for that

\n
\n

A non-guessable identifier like correct-horse-battery-staple?

", "time": "2023-11-10T15:55:58Z"}, {"author": "Jonathan Hoyland", "text": "

@Benjamin Beurdouche :joy:

", "time": "2023-11-10T15:56:08Z"}, {"author": "Mallory Knodel", "text": "

Alissa Cooper said:

\n
\n

yes, there is a trade-off between designing something that any provider wants to use vs. not standardizing anything

\n
\n

Maybe my comment should be more about where we start and assume as a default. And then additional modes optional with guidance

", "time": "2023-11-10T15:56:37Z"}, {"author": "Giles Hogben", "text": "

DNS as is doesn't have the privacy properties we need IMO

", "time": "2023-11-10T15:58:44Z"}, {"author": "Benjamin Schwartz", "text": "

I think \"SII\" is kind of a red herring. Every identifier is specific to some service. Some of those services are participating in MIMI, and some are not.

", "time": "2023-11-10T15:59:01Z"}, {"author": "Antoine Fressancourt", "text": "

@Giles, I agree

", "time": "2023-11-10T15:59:03Z"}, {"author": "Giles Hogben", "text": "

I think we need DNS + PIR

", "time": "2023-11-10T15:59:18Z"}, {"author": "Antoine Fressancourt", "text": "", "time": "2023-11-10T15:59:42Z"}, {"author": "Daniel Gillmor", "text": "

@Giles Hogben even assuming that we know how to cryptographically protect the labels and the contents, DNS zone enumerability is a well-understood problem -- especially with DNSSEC we don't have any particularly great solutions there.

", "time": "2023-11-10T15:59:44Z"}, {"author": "Antoine Fressancourt", "text": "

(the dot was supposed to be a plus)

", "time": "2023-11-10T16:00:00Z"}, {"author": "Daniel Gillmor", "text": "

you can do white lies or NSEC5 to limit zone enumerability

", "time": "2023-11-10T16:00:21Z"}, {"author": "Femi Olumofin", "text": "

Current DNS Infra may not be able to scale to billons of users. A provider will require several zones to host 10BN identifiers, using TXT records.

", "time": "2023-11-10T16:00:25Z"}, {"author": "Benjamin Schwartz", "text": "

I think SSI->SSI bootstrapping is really what's needed, so I can migrate from one service to another.

", "time": "2023-11-10T16:01:03Z"}, {"author": "Richard Barnes", "text": "

DIDs are in no way a solution here

", "time": "2023-11-10T16:01:15Z"}, {"author": "Simon Friedberger", "text": "

I agree with the general idea by Vittorio here. We don't need to link accounts, people can still publish a list of all their accounts and addresses in their mini bios and whatever. The real question is, how do you get a key for an account when you want to send it a message. And ISTM that this is independent of if you are on the same service or not. Am I missing something?

", "time": "2023-11-10T16:01:17Z"}, {"author": "Mallory Knodel", "text": "

If Mimi identifier messaging services can\u2019t talk to services that don\u2019t migrate to Mimi identifiers then we lost the interop part of this work

", "time": "2023-11-10T16:02:16Z"}, {"author": "Jonathan Rosenberg", "text": "

I am not in favor of work on new identifiers.

", "time": "2023-11-10T16:02:26Z"}, {"author": "Simon Friedberger", "text": "

Well, why can't the identifiers stay the same? If I want to reach somebody on whatsapp I use their whatsapp identifier and however that is currently discovered.

", "time": "2023-11-10T16:03:10Z"}, {"author": "Daniel Gillmor", "text": "

if a MIMI identifier is localpart@domainname, but it is not an e-mail address, is that a \"new identifier\"?

", "time": "2023-11-10T16:03:46Z"}, {"author": "Jonathan Hoyland", "text": "

Time to 927 -- 1 week!

", "time": "2023-11-10T16:03:47Z"}, {"author": "Benjamin Schwartz", "text": "

I want to be able tell all my XChat contacts that I'm also asdf on YChat. If XChat happens to be SMS ... that's a generalization of the same idea to non-MIMI networks.

", "time": "2023-11-10T16:04:19Z"}, {"author": "Daniel Gillmor", "text": "

+1 to @Alan Duric

", "time": "2023-11-10T16:04:57Z"}, {"author": "Jonathan Rosenberg", "text": "

well, if Alan brings some nice wine too in addition to beers... ;)

", "time": "2023-11-10T16:04:57Z"}]