[{"author": "Daniel Gillmor", "text": "

don't worry, we're all confused by timezones too

", "time": "2024-03-20T23:30:25Z"}, {"author": "Orie Steele", "text": "

Hey folks, apologies for not being in the room with you all, I'm filling in for a co-author in OAuth. ... I look forward to supporting mimi, I'm generally available by email or in the ietf slack.

", "time": "2024-03-20T23:32:49Z"}, {"author": "Alissa Cooper", "text": "

Sounds good

", "time": "2024-03-20T23:33:46Z"}, {"author": "Eric Rescorla", "text": "

I think this is a good design choice

", "time": "2024-03-20T23:35:13Z"}, {"author": "Martin D\u00fcrst", "text": "

I'll type it.

", "time": "2024-03-20T23:36:04Z"}, {"author": "Nick Sullivan", "text": "

Tempted to join the queue and ask if we can do a MIMI meeting in Turkey.

", "time": "2024-03-20T23:36:38Z"}, {"author": "Tim Geoghegan", "text": "

I'm happy to relay your question or comment to Rohan

", "time": "2024-03-20T23:36:38Z"}, {"author": "Martin D\u00fcrst", "text": "

Hands up was not accidental. I wanted to ask about 'deprecate' on slide 2. We are still working on this, why do we have to 'deprecate' something that we never used? (Please answer to this question at the end of the presentation.)

", "time": "2024-03-20T23:37:49Z"}, {"author": "Daniel Gillmor", "text": "

the attachment can be replaced

", "time": "2024-03-20T23:39:07Z"}, {"author": "Daniel Gillmor", "text": "

or served differently to different people

", "time": "2024-03-20T23:39:13Z"}, {"author": "Daniel Gillmor", "text": "

you could also put the AEAD tag in there

", "time": "2024-03-20T23:39:41Z"}, {"author": "Eric Rescorla", "text": "

I think the tag doesn't do it.

", "time": "2024-03-20T23:40:47Z"}, {"author": "Eric Rescorla", "text": "

Oh, I guess the key is committed to right here.

", "time": "2024-03-20T23:40:57Z"}, {"author": "Daniel Gillmor", "text": "

anyway, ask someone who knows :P

", "time": "2024-03-20T23:41:30Z"}, {"author": "Konrad Kohbrok", "text": "

Why isn't the tag enough?

", "time": "2024-03-20T23:41:30Z"}, {"author": "Tim Geoghegan", "text": "

Looks like someone did previously write up this problem about hashing attachments: https://github.com/ietf-wg-mimi/draft-ietf-mimi-content/issues/6

", "time": "2024-03-20T23:42:03Z"}, {"author": "Eric Rescorla", "text": "

Looks like we already filed an issue on this https://github.com/ietf-wg-mimi/draft-ietf-mimi-content/issues/6

", "time": "2024-03-20T23:42:16Z"}, {"author": "Eric Rescorla", "text": "

So presumably Richard or I can figure it out

", "time": "2024-03-20T23:42:22Z"}, {"author": "Eric Rescorla", "text": "

@TimG: yeah, me :)

", "time": "2024-03-20T23:42:35Z"}, {"author": "Richard Barnes", "text": "

yep that issue looks right

", "time": "2024-03-20T23:42:49Z"}, {"author": "Eric Rescorla", "text": "

I think the tag is enough, but I'm not 100% sure.

", "time": "2024-03-20T23:43:12Z"}, {"author": "Richard Barnes", "text": "

i wouldn't rely on the tag at least with GCM

", "time": "2024-03-20T23:43:38Z"}, {"author": "Eric Rescorla", "text": "

Is \"not being able to produce a tag collision\" a requirement for a secure MAC?

", "time": "2024-03-20T23:43:50Z"}, {"author": "Daniel Gillmor", "text": "

maybe don't design this in the chat right now and keep up with the speaker :)

", "time": "2024-03-20T23:44:14Z"}, {"author": "Eric Rescorla", "text": "

Spoilsport

", "time": "2024-03-20T23:44:31Z"}, {"author": "Richard Barnes", "text": "

@ekr i guess that's true

", "time": "2024-03-20T23:44:35Z"}, {"author": "Daniel Gillmor", "text": "

:shrug:

", "time": "2024-03-20T23:44:45Z"}, {"author": "Daniel Gillmor", "text": "

signal private messenger shows the petname for a given user

", "time": "2024-03-20T23:47:00Z"}, {"author": "Daniel Gillmor", "text": "

i agree with ekr that we should make it impossible to make the mistake

", "time": "2024-03-20T23:47:27Z"}, {"author": "Eric Rescorla", "text": "

S-expressions

", "time": "2024-03-20T23:47:51Z"}, {"author": "Daniel Gillmor", "text": "

(note that Signal also leaks your petname for the user when you reply to a message that has a mention early in it, though; that's a Bad Thing)

", "time": "2024-03-20T23:48:22Z"}, {"author": "Orie Steele", "text": "

https://datatracker.ietf.org/doc/draft-rivest-sexp/

", "time": "2024-03-20T23:49:03Z"}, {"author": "Orie Steele", "text": "

in case you need a reference for s-expressions

", "time": "2024-03-20T23:49:26Z"}, {"author": "Eric Rescorla", "text": "

https://github.com/digitalbazaar/forge

", "time": "2024-03-20T23:49:32Z"}, {"author": "Eric Rescorla", "text": "

(JS TLS parser)

", "time": "2024-03-20T23:49:45Z"}, {"author": "Eric Rescorla", "text": "

STUN TLV encoding

", "time": "2024-03-20T23:50:22Z"}, {"author": "Tim Geoghegan", "text": "

We did TypeScript parsing of TLS presentation language messages for a DAP implementation and it wasn't that bad https://github.com/divviup/divviup-ts

", "time": "2024-03-20T23:50:28Z"}, {"author": "Eric Rescorla", "text": "

This is like wrong answers only

", "time": "2024-03-20T23:50:28Z"}, {"author": "Daniel Gillmor", "text": "

I've reviewed that sexp draft. it needs work :(

", "time": "2024-03-20T23:50:35Z"}, {"author": "Cory Myers", "text": "

Daniel Gillmor said:

\n
\n

(note that Signal also leaks your petname for the user when you reply to a message that has a mention early in it, though; that's a Bad Thing)

\n
\n

I'd argue that the implication there is that local names break transcript consistency, which I've never loved in itself. The quote-reply behavior is what makes it a leak.

", "time": "2024-03-20T23:50:44Z"}, {"author": "Daniel Gillmor", "text": "

yes, agreed that quote-reply is what causes the breakage

", "time": "2024-03-20T23:51:12Z"}, {"author": "Daniel Gillmor", "text": "

i'm disappointed in you all that no one is asking for ASN.1

", "time": "2024-03-20T23:53:29Z"}, {"author": "Eric Rescorla", "text": "

ASN.2

", "time": "2024-03-20T23:53:42Z"}, {"author": "Daniel Gillmor", "text": "

or XML

", "time": "2024-03-20T23:53:46Z"}, {"author": "Eric Rescorla", "text": "

JSON

", "time": "2024-03-20T23:53:50Z"}, {"author": "Martin D\u00fcrst", "text": "

I assume that the decision for binary has been made before. But given that we don't really like any of the choices, we migth want to recheck that decision, which would give XML and JSON as additional choices.

", "time": "2024-03-20T23:54:30Z"}, {"author": "Eric Rescorla", "text": "

I concur with TimG that we should use the same binary encoding. I think that's a sort of weak argument for TLS presentation given that MLS already commits us to that for part of the stack. OTOH, I suppose that's an argument for ASN.1/DER because we have to support X.509 certificates

", "time": "2024-03-20T23:55:07Z"}, {"author": "Orie Steele", "text": "

(as an individual) of these choices I like CBOR, but I am pretty biased.

", "time": "2024-03-20T23:55:45Z"}, {"author": "Orie Steele", "text": "

IIRC mDoc uses some parts of TLS, so perhaps a mixture of TLS and CBOR could be ok.

", "time": "2024-03-20T23:56:57Z"}, {"author": "Daniel Gillmor", "text": "

polls are y/n/unknown -- hard to do for multiple options

", "time": "2024-03-20T23:57:04Z"}, {"author": "Richard Barnes", "text": "

yeah, i think this is close. seems like we can at least limit it to \"TLS or CBOR\"

", "time": "2024-03-20T23:57:05Z"}, {"author": "Thomas McCarthy-Howe", "text": "

EKR's right

", "time": "2024-03-20T23:57:40Z"}, {"author": "Thomas McCarthy-Howe", "text": "

Up or down on CBOR

", "time": "2024-03-20T23:57:44Z"}, {"author": "Tim Geoghegan", "text": "

+1 to \"TLS/CBOR/other\"

", "time": "2024-03-20T23:57:45Z"}, {"author": "Tim Geoghegan", "text": "

Hey at least now you can unmute in Meetecho in less than five seconds

", "time": "2024-03-20T23:58:36Z"}, {"author": "Richard Barnes", "text": "

progress!

", "time": "2024-03-20T23:59:02Z"}, {"author": "Daniel Gillmor", "text": "

that's fine too. i was hoping to run fewer polls

", "time": "2024-03-20T23:59:08Z"}, {"author": "Martin D\u00fcrst", "text": "

Good point, Alissa!

", "time": "2024-03-20T23:59:22Z"}, {"author": "Travis Ralston", "text": "

Unmute in Canada is still taking a bit longer than it should :p

", "time": "2024-03-20T23:59:55Z"}, {"author": "Daniel Gillmor", "text": "

there is clearly no consensus

", "time": "2024-03-21T00:03:09Z"}, {"author": "Tim Geoghegan", "text": "

OK so half the messages will be CBOR, the other half will be TLS

", "time": "2024-03-21T00:03:42Z"}, {"author": "Daniel Gillmor", "text": "

sneaky last-minute balloting techniques there

", "time": "2024-03-21T00:03:45Z"}, {"author": "Daniel Gillmor", "text": "

Rohan are you proposing to extend the pain timeline?

", "time": "2024-03-21T00:04:40Z"}, {"author": "Marvin Wi\u00dffeld", "text": "

You forgot to mention XMPP ;)

", "time": "2024-03-21T00:05:35Z"}, {"author": "Daniel Gillmor", "text": "

Subject as metadata comparable to other message metadata has been a misfeature in e-mail for decades.

", "time": "2024-03-21T00:05:55Z"}, {"author": "Tim Geoghegan", "text": "

I'd like to hear someone make an earnest case in favour, and if nobody wants to do that then... let's not do subjects.

", "time": "2024-03-21T00:07:00Z"}, {"author": "Daniel Gillmor", "text": "

+1 Tim

", "time": "2024-03-21T00:07:13Z"}, {"author": "Orie Steele", "text": "

+1 Tim

", "time": "2024-03-21T00:07:21Z"}, {"author": "Martin D\u00fcrst", "text": "

Subject in email is a positive feature (I'd not be able to handle my email without subjects), but it doesn't translate to other messaging services.

", "time": "2024-03-21T00:08:18Z"}, {"author": "Daniel Gillmor", "text": "

Martin: subject in e-mail is a positive feature, but it shouldn't have been placed on the same level as Message-ID and In-Reply-To

", "time": "2024-03-21T00:09:23Z"}, {"author": "Eric Rescorla", "text": "

My comments were before the meeting, so not really that late

", "time": "2024-03-21T00:10:17Z"}, {"author": "Martin D\u00fcrst", "text": "

Daniel: What level then? Email didn't, and still mostly doesn't have, complex structure.

", "time": "2024-03-21T00:10:18Z"}, {"author": "Daniel Gillmor", "text": "

e-mail structure is arbitrarily complex. that's a problem too :)

", "time": "2024-03-21T00:10:42Z"}, {"author": "Daniel Gillmor", "text": "

(now that we have MIME)

", "time": "2024-03-21T00:10:50Z"}, {"author": "Daniel Gillmor", "text": "

see draft-ietf-lamps-header-protection for more attempts to retcon the situation into something reasonable

", "time": "2024-03-21T00:11:24Z"}, {"author": "Daniel Gillmor", "text": "

i'd like to see this pseudonymity scheme documented clearly, because i want to make sure we're not making decisions that foreclose protecting metadata this way

", "time": "2024-03-21T00:24:16Z"}, {"author": "Daniel Gillmor", "text": "

in the ideal situation, i would prefer that the hub server doesn't even need to know how many participants are joined from one of the non-hub servers.

", "time": "2024-03-21T00:25:38Z"}, {"author": "Rohan Mahy", "text": "

Eric Rescorla said:

\n
\n

https://github.com/digitalbazaar/forge

\n
\n

last commit 2 years ago....

", "time": "2024-03-21T00:29:39Z"}, {"author": "Daniel Gillmor", "text": "

sounds stable!

", "time": "2024-03-21T00:29:54Z"}, {"author": "Rohan Mahy", "text": "

Marvin Wi\u00dffeld said:

\n
\n

You forgot to mention XMPP ;)

\n
\n

Feel free to mention XMPP as we discuss the protocol document.

", "time": "2024-03-21T00:33:24Z"}, {"author": "Tim Geoghegan", "text": "

XMPP for modern IM interop: https://engineering.fb.com/2024/03/06/security/whatsapp-messenger-messaging-interoperability-eu/

", "time": "2024-03-21T00:33:56Z"}, {"author": "Rohan Mahy", "text": "

Tim Geoghegan said:

\n
\n

XMPP for modern IM interop: https://engineering.fb.com/2024/03/06/security/whatsapp-messenger-messaging-interoperability-eu/

\n
\n

WhatsApp implements XMPP to the same extent that I am Taylor Swift.

", "time": "2024-03-21T00:35:43Z"}, {"author": "Marvin Wi\u00dffeld", "text": "

Last time I heard someone talking about it, WhatsApp was actually using a popular open source XMPP server as a base, but of course with significant modifications. Even if it's strictly speaking no longer XMPP, it's so close that for protocol documentation purposes they convert their internal format to XMPP XML

", "time": "2024-03-21T00:40:27Z"}, {"author": "Daniel Gillmor", "text": "

that doc says roughly protobuf wrapped in XML

", "time": "2024-03-21T00:41:03Z"}, {"author": "Daniel Gillmor", "text": "

best of both worlds

", "time": "2024-03-21T00:41:14Z"}, {"author": "Marvin Wi\u00dffeld", "text": "

Daniel Gillmor schrieb:

\n
\n

that doc says roughly protobuf wrapped in XML

\n
\n

That's because they use Signal protocol, which uses protobuf, to encrypt the message content

", "time": "2024-03-21T00:44:21Z"}, {"author": "Orie Steele", "text": "

triggered by client being represented with \"d\"... im sure there is a good reason for that though

", "time": "2024-03-21T00:45:33Z"}, {"author": "Daniel Gillmor", "text": "

device

", "time": "2024-03-21T00:45:44Z"}, {"author": "Tim Geoghegan", "text": "

\"device\", I think

", "time": "2024-03-21T00:45:46Z"}, {"author": "Orie Steele", "text": "

makes sense.

", "time": "2024-03-21T00:45:53Z"}, {"author": "Daniel Gillmor", "text": "

or, the d is silent

", "time": "2024-03-21T00:46:03Z"}, {"author": "Travis Ralston", "text": "

yea, device. We borrowed syntax from someone else :innocent:

", "time": "2024-03-21T00:46:04Z"}, {"author": "Tim Geoghegan", "text": "

Kinda seems like each client/device should belong to a user, such that it would be mimi://a.example/u/alice/d/ClientAt

", "time": "2024-03-21T00:46:21Z"}, {"author": "Orie Steele", "text": "

i would be more concerned if you need multiple clients on the same device for the same provider

", "time": "2024-03-21T00:46:57Z"}, {"author": "Orie Steele", "text": "

... but maybe what I am saying makes no sense

", "time": "2024-03-21T00:47:13Z"}, {"author": "Daniel Gillmor", "text": "

i'm still not convinced that it's a positive feature that we treat the MLS devices separately. i think that's an unnecessary metadata leak

", "time": "2024-03-21T00:47:18Z"}, {"author": "Tim Geoghegan", "text": "

You mean a single phone that has Signal and WhatsApp and Wire installed on it? I think those are effective three different \"devices\" (this is where client is a better word)

", "time": "2024-03-21T00:47:43Z"}, {"author": "Travis Ralston", "text": "

A device is a logical device, not a physical one. A phone could have 2+ device IDs

", "time": "2024-03-21T00:47:44Z"}, {"author": "Tim Geoghegan", "text": "

@Daniel IIUC each MLS \"device\" has distinct key packages, so the sender has to encrypt to each for them all to receive messages

", "time": "2024-03-21T00:49:51Z"}, {"author": "Daniel Gillmor", "text": "

yes, i think that's a misfeature in MLS

", "time": "2024-03-21T00:50:04Z"}, {"author": "Daniel Gillmor", "text": "

i lost that argument in MLS discussion, but that doesn't make it a misfeature

", "time": "2024-03-21T00:50:33Z"}, {"author": "Daniel Gillmor", "text": "

doesn't make it not a misfeature :P

", "time": "2024-03-21T00:50:48Z"}, {"author": "Eric Rescorla", "text": "

ITYM it doesn't make it not a misfeature.

", "time": "2024-03-21T00:50:52Z"}, {"author": "Eric Rescorla", "text": "

Hah. Race condition

", "time": "2024-03-21T00:50:57Z"}, {"author": "Daniel Gillmor", "text": "

ha ha

", "time": "2024-03-21T00:51:02Z"}, {"author": "Tim Geoghegan", "text": "

Well, OK, but the MIMI charter explicitly says to use MLS, so we're stuck with MLS' misfeatures

", "time": "2024-03-21T00:51:16Z"}, {"author": "Konrad Kohbrok", "text": "

In the upcoming MLS session we\u2019ll briefly discuss virtual clients, which might be a solution to this problem.

", "time": "2024-03-21T00:51:23Z"}, {"author": "Tim Geoghegan", "text": "

(that's a personal opinion, not a chair proclamation)

", "time": "2024-03-21T00:51:42Z"}, {"author": "Daniel Gillmor", "text": "

if MLS is going to be all about \"clients\" we ought to be able to just ignore the user,

", "time": "2024-03-21T00:53:13Z"}, {"author": "Eric Rescorla", "text": "

I ignore users all the time

", "time": "2024-03-21T00:54:10Z"}, {"author": "Tim Geoghegan", "text": "

I believe MIMI needs a concept of a user distinct from MLS clients, because of the case where every one of a human being's phones and laptops fell into a volcano. There's no longer any cryptographic entity that's in the MLS group -- no device -- but there's still a MIMI user who could add new devices in the future.

", "time": "2024-03-21T00:55:24Z"}, {"author": "Daniel Gillmor", "text": "

that lack of cryptographic binding smells like an exploitable hole in the protocol

", "time": "2024-03-21T00:55:55Z"}, {"author": "Daniel Gillmor", "text": "

i don't know why we would want to build that in.

", "time": "2024-03-21T00:56:09Z"}, {"author": "Daniel Gillmor", "text": "

if i fall in a volcano, i have a lot to deal with already, and getting someone to re-invite me to my MIMI groups is low on my list of priorities

", "time": "2024-03-21T00:56:44Z"}, {"author": "Konrad Kohbrok", "text": "

The binding should be in the authentication service which I don\u2019t think we have nailed down yet.

", "time": "2024-03-21T00:56:44Z"}, {"author": "Tim Geoghegan", "text": "

Might I suggest that you get in queue and make that point? I think others could defend this better than I can.

", "time": "2024-03-21T00:56:54Z"}, {"author": "Rohan Mahy", "text": "

Daniel Gillmor said:

\n
\n

if i fall in a volcano, i have a lot to deal with already, and getting someone to re-invite me to my MIMI groups is low on my list of priorities

\n
\n

Only your devices fell into the volcano (or into the ocean, burned in a house fire, etc), while you are still alive and well.

", "time": "2024-03-21T00:59:49Z"}, {"author": "Daniel Gillmor", "text": "

i still don't object to needing to be re-added to my groups after that event

", "time": "2024-03-21T01:00:11Z"}, {"author": "Rohan Mahy", "text": "

Tim Geoghegan said:

\n
\n

Kinda seems like each client/device should belong to a user, such that it would be mimi://a.example/u/alice/d/ClientAt

\n
\n

That could work, but it is a bit verbose.

", "time": "2024-03-21T01:00:47Z"}, {"author": "Eric Rescorla", "text": "

@DKG, I think the thing that is sort of unclear is that \"added to groups\" means \"continue chats with everyone you have been talking to\"

", "time": "2024-03-21T01:01:48Z"}, {"author": "Tim Geoghegan", "text": "

That's a good point @DKG, thank you

", "time": "2024-03-21T01:02:04Z"}, {"author": "Sean Turner", "text": "

Dude it's zero trust!

", "time": "2024-03-21T01:02:43Z"}, {"author": "Sean Turner", "text": "

half kidding

", "time": "2024-03-21T01:02:55Z"}, {"author": "Daniel Gillmor", "text": "

it's ok, half of zero is still zero

", "time": "2024-03-21T01:03:06Z"}, {"author": "Sean Turner", "text": "

We got ACME right ;)

", "time": "2024-03-21T01:03:07Z"}, {"author": "Eric Rescorla", "text": "

twice zero is also zero

", "time": "2024-03-21T01:03:14Z"}, {"author": "Sean Turner", "text": "

@dkg :)

", "time": "2024-03-21T01:03:16Z"}, {"author": "Stefan Ubbink", "text": "

+1 Alissa

", "time": "2024-03-21T01:03:43Z"}, {"author": "Sean Turner", "text": "

maybe it's not the 1st hill we try to die on ;)

", "time": "2024-03-21T01:03:48Z"}, {"author": "Daniel Gillmor", "text": "

+1 alissa

", "time": "2024-03-21T01:03:53Z"}, {"author": "Daniel Gillmor", "text": "

Eric: yes, i'm saying that destruction of all the devices under the user's control should be the equivalent of a digital death. Please don't mandate in the architecture that the provider can impersonate a dead user.

", "time": "2024-03-21T01:05:51Z"}, {"author": "Tim Geoghegan", "text": "

I'm worried that client cert validation will be an abundant source of vulnerabilities in MIMI implementations, as it has been in every mTLS deployment I've ever seen. But this WG will succeed at unambiguously specifying how to do it.

", "time": "2024-03-21T01:06:08Z"}, {"author": "Tim Geoghegan", "text": "

*But perhaps this WG will succeed

", "time": "2024-03-21T01:06:45Z"}, {"author": "Daniel Gillmor", "text": "

we won't be able to prevent providers from offering \"volcano-proof accounts\" but at least we can't require that all participants accept such an impersonation mechanism as a core protocol design choice.

", "time": "2024-03-21T01:06:45Z"}, {"author": "Eric Rescorla", "text": "

As I understand this, it's a core protocol design choice of MLS

", "time": "2024-03-21T01:07:01Z"}, {"author": "Eric Rescorla", "text": "

https://datatracker.ietf.org/doc/html/rfc9205#section-4.4

", "time": "2024-03-21T01:09:33Z"}, {"author": "Rohan Mahy", "text": "

Daniel Gillmor said:

\n
\n

we won't be able to prevent providers from offering \"volcano-proof accounts\" but at least we can't require that all participants accept such an impersonation mechanism as a core protocol design choice.

\n
\n

If you have a room for dissidents or whistleblowers for example, your hub can set a room policy that external commits/joins are not allowed.

", "time": "2024-03-21T01:10:12Z"}, {"author": "Daniel Gillmor", "text": "

in MLS everyone is all-in on the same provider. In MIMI, they're not.

", "time": "2024-03-21T01:10:18Z"}, {"author": "Rohan Mahy", "text": "

Daniel Gillmor said:

\n
\n

in MLS everyone is all-in on the same provider. In MIMI, they're not.

\n
\n

hmm, I can offer an proof to the contrary. Wire has federated MLS groups that use multiple on-prem \"providers\"

", "time": "2024-03-21T01:12:47Z"}, {"author": "Rohan Mahy", "text": "

I believe Wickr can do the same

", "time": "2024-03-21T01:12:58Z"}, {"author": "Daniel Gillmor", "text": "

Rohan: that's not particularly useful. I'd be fine with being able to exclude malicious providers from such a room (E.g. those that force their users to use their \"volcano-proof\" provider-managed clients that have a permanent \"ghost user\" for arbitrary wiretapping). But i don't want to exclude everyone on every platform. dissidents need to organize!

", "time": "2024-03-21T01:13:00Z"}, {"author": "Daniel Gillmor", "text": "

Rohan, are you then refuting ekrs claim that provider can impersonate a client is a core protocol design choice of MLS?

", "time": "2024-03-21T01:14:11Z"}, {"author": "Eric Rescorla", "text": "

I think my claim was intended to be that a core feature of the protocol was that identifiers were distinct from clients

", "time": "2024-03-21T01:14:48Z"}, {"author": "Daniel Gillmor", "text": "

that's a different claim; if the identities are cryptographically bound to keys controlled only by the clients, that's what i'm looking for.

", "time": "2024-03-21T01:15:33Z"}, {"author": "Eric Rescorla", "text": "

I think we may be talking past each other here.

", "time": "2024-03-21T01:16:01Z"}, {"author": "Daniel Gillmor", "text": "

seems likely :(

", "time": "2024-03-21T01:16:08Z"}, {"author": "Rohan Mahy", "text": "

dkg: external joins only work if the last client that committed shares their signature over the GroupInfo with the external committer (often via the hub).

", "time": "2024-03-21T01:16:36Z"}, {"author": "Daniel Gillmor", "text": "

+1 sean, this seems like the way forwaard

", "time": "2024-03-21T01:18:49Z"}, {"author": "Victor Pascual", "text": "

+1 I support adoption

", "time": "2024-03-21T01:19:22Z"}, {"author": "Rohan Mahy", "text": "

+1 to support adoption of both documents (unsurprisingly)

", "time": "2024-03-21T01:21:16Z"}, {"author": "Eric Rescorla", "text": "

\"Yes\" == \"Do not adopt\"

", "time": "2024-03-21T01:21:24Z"}, {"author": "Eric Rescorla", "text": "

\"No \" == \"Adopt\"

", "time": "2024-03-21T01:21:27Z"}, {"author": "Daniel Gillmor", "text": "

\"No opinon\" == \"use XMPP\"

", "time": "2024-03-21T01:21:46Z"}, {"author": "Sean Turner", "text": "

@Rohan: I mean you had you chance to define an encoding scheme and you passed so good on you!

", "time": "2024-03-21T01:21:47Z"}, {"author": "Daniel Gillmor", "text": "

this seems pretty clear

", "time": "2024-03-21T01:23:39Z"}, {"author": "Tim Geoghegan", "text": "

:tada:

", "time": "2024-03-21T01:24:47Z"}, {"author": "Tim Geoghegan", "text": "

Thanks everyone!

", "time": "2024-03-21T01:29:13Z"}]