[{"author": "Konrad Kohbrok", "text": "

I can take notes.

", "time": "2023-05-03T16:01:36Z"}, {"author": "Alissa Cooper", "text": "

Thank you!

", "time": "2023-05-03T16:01:44Z"}, {"author": "Matthew Hodgson", "text": "

/me waves

", "time": "2023-05-03T16:04:17Z"}, {"author": "Matthew Hodgson", "text": "

is this the right chat for the interim, or is there a parallel XMPP MUC or something?

", "time": "2023-05-03T16:05:17Z"}, {"author": "Alissa Cooper", "text": "

this is the right chat

", "time": "2023-05-03T16:05:26Z"}, {"author": "Eric Rescorla", "text": "

I know that iMessage/SMS and Signal do (1)

", "time": "2023-05-03T16:09:43Z"}, {"author": "Eric Rescorla", "text": "

Awesome shirt, Matthew

", "time": "2023-05-03T16:11:38Z"}, {"author": "Pete Resnick", "text": "

Yep, what Matthew said.

", "time": "2023-05-03T16:12:10Z"}, {"author": "Mallory Knodel", "text": "

If you reverse this into \"receive\" rather than send, I think what Matthew and Pete are saying makes clearer sense.

", "time": "2023-05-03T16:12:35Z"}, {"author": "Mallory Knodel", "text": "

*this slide's text

", "time": "2023-05-03T16:12:46Z"}, {"author": "Mallory Knodel", "text": "

1) Alice can receive messages from Bob immediately, 2) etc.

", "time": "2023-05-03T16:13:35Z"}, {"author": "Pete Resnick", "text": "

@Mallory Knodel : \"Can\" does a bunch of work in that sentence.

", "time": "2023-05-03T16:14:12Z"}, {"author": "Mallory Knodel", "text": "

Fiar

", "time": "2023-05-03T16:14:33Z"}, {"author": "Mallory Knodel", "text": "

Fair

", "time": "2023-05-03T16:14:34Z"}, {"author": "Matthew Hodgson", "text": "

Matrix for instance does (2) at the protocol layer, but some clients just go and autoaccept (particularly if they have some out-of-band evidence that the user is trusted), at which point it falls back to (1)

", "time": "2023-05-03T16:14:55Z"}, {"author": "Pete Resnick", "text": "

Q: When this slide asks which modes we \"support\", are we just asking about the UI requirement, or the protocol requirement?

", "time": "2023-05-03T16:15:54Z"}, {"author": "Matthew Hodgson", "text": "

i get that it's a requirements question in some ways, but i don't think the protocol should be adjudicating on the UI used for antiabuse (e.g. hiding inbound messages from untrusted users).

", "time": "2023-05-03T16:16:29Z"}, {"author": "Alissa Cooper", "text": "

the point is to identify the protocol requirements, and the space of possibilities of what can or cannot be handled in UI

", "time": "2023-05-03T16:16:56Z"}, {"author": "Mallory Knodel", "text": "

I was going to say exactly what @Tim pointed out. Both Signal and iMessage (even though they are right now walled) differentiate unknown senders (iMessage) and senders one has not yet trusted (Signal)

", "time": "2023-05-03T16:17:45Z"}, {"author": "Pete Resnick", "text": "

+1 Jo\u00ebl

", "time": "2023-05-03T16:17:47Z"}, {"author": "Matthew Hodgson", "text": "

there's an adjacent security concern (which has been a major pain for Matrix) which is: how much user data do you expose on an 'invite' - even if you quarantine the message. Do you show that user's avatar? name? conversation topic? whether it's a 1:1 or a group chat? etc

", "time": "2023-05-03T16:19:22Z"}, {"author": "Matthew Hodgson", "text": "

given scope for invite-spam abuse (e.g. long user names in invite spam being used to spam URLs, or people putting spam/abuse content into their avatars)

", "time": "2023-05-03T16:20:52Z"}, {"author": "Mallory Knodel", "text": "

It's useful to see the message to determine if its spam.

", "time": "2023-05-03T16:21:51Z"}, {"author": "Pete Resnick", "text": "

What EKR just described seems right.

", "time": "2023-05-03T16:23:11Z"}, {"author": "Matthew Hodgson", "text": "

yup. and Matrix currently prohibits that (until you accept the invite), which causes significant pain from people who want to be able to 'peek' to gauge whether to accept or not. (which is a Matrix-specific thinko, but one to learn from here :)

", "time": "2023-05-03T16:23:17Z"}, {"author": "Raphael Robert", "text": "

Also agree with ekr, let's move forward!

", "time": "2023-05-03T16:23:33Z"}, {"author": "Eric Rescorla", "text": "

I don't think, btw, that we should require consent to joining groups

", "time": "2023-05-03T16:23:52Z"}, {"author": "Eric Rescorla", "text": "

And that would need to be a new mechanism

", "time": "2023-05-03T16:23:57Z"}, {"author": "Eric Rescorla", "text": "

Yeah, the phone number has to be in the target's address book

", "time": "2023-05-03T16:24:40Z"}, {"author": "Pete Resnick", "text": "

@Rohan Mahy : Distinction without a difference between WhatsApp and Apple.

", "time": "2023-05-03T16:25:14Z"}, {"author": "Mallory Knodel", "text": "

Disagree, the DMA doesn't say anything about this level of user behaviour.

", "time": "2023-05-03T16:25:15Z"}, {"author": "Alissa Cooper", "text": "

I think his point is that the GKs might change which behaviors they support based on having to comply with the DMA.

", "time": "2023-05-03T16:25:53Z"}, {"author": "Matthew Hodgson", "text": "

(travis sends his regrets, btw, but is running tech support for some enormous canadian tech conference)

", "time": "2023-05-03T16:27:58Z"}, {"author": "Mallory Knodel", "text": "

(@AC-- Right-- and I think what I was reacting to is that compliance with the DMA sh/wouldn't precipitate those sorts of fine grained changes, but it's a side point.)

", "time": "2023-05-03T16:29:52Z"}, {"author": "Pete Resnick", "text": "

Ad-hoc groups can be done as named groups so long as the \"add\" and \"leave\" functions can return \"sorry, nope\".

", "time": "2023-05-03T16:30:35Z"}, {"author": "Jonathan Rosenberg", "text": "

I am in queue to basically say \"I agree with what Pete just said\"

", "time": "2023-05-03T16:30:55Z"}, {"author": "Alissa Cooper", "text": "

Not only is the behavior inconsistent across deployed services, in some cases it is straight up broken.

", "time": "2023-05-03T16:31:18Z"}, {"author": "Richard Barnes", "text": "

yeah, there were some funny bugs

", "time": "2023-05-03T16:32:18Z"}, {"author": "Richard Barnes", "text": "

the challenge with doing only groups is how you do the uniqueness properties for 1:1 / group DMs

", "time": "2023-05-03T16:32:55Z"}, {"author": "Richard Barnes", "text": "

... in a distributed setting

", "time": "2023-05-03T16:33:00Z"}, {"author": "Pete Resnick", "text": "

It's hard to separate the UI experience of \"thread\" with \"group\".

", "time": "2023-05-03T16:33:06Z"}, {"author": "Pete Resnick", "text": "

s/with/from

", "time": "2023-05-03T16:33:15Z"}, {"author": "Richard Barnes", "text": "

@Pete threads are a whole different thing. they are internal to a group

", "time": "2023-05-03T16:33:28Z"}, {"author": "Jonathan Rosenberg", "text": "

not sure why you cannot hear me

", "time": "2023-05-03T16:33:37Z"}, {"author": "Richard Barnes", "text": "

MeetEcho is awesome

", "time": "2023-05-03T16:33:44Z"}, {"author": "Tim Geoghegan", "text": "

Sorry about that Jonathan, please feel free to re-join the queue

", "time": "2023-05-03T16:34:04Z"}, {"author": "Pete Resnick", "text": "

@Richard Barnes Agreed, but in e.g. SMS UIs, they are relatively indistinguishable.

", "time": "2023-05-03T16:34:33Z"}, {"author": "Eric Rescorla", "text": "

Happy to have new terms. I didn

", "time": "2023-05-03T16:35:18Z"}, {"author": "Eric Rescorla", "text": "

t update these since Travis

", "time": "2023-05-03T16:35:22Z"}, {"author": "Eric Rescorla", "text": "

s doc

", "time": "2023-05-03T16:35:26Z"}, {"author": "Tim Geoghegan", "text": "

I wonder if one of the iMessage conversations involved phone numbers and the other involves emails. Apple ID historically gets ... confused about those.

", "time": "2023-05-03T16:37:01Z"}, {"author": "Matthew Hodgson", "text": "

i have a feeling iMessage might have changed protocol big-time underneath in the last few years then

", "time": "2023-05-03T16:37:51Z"}, {"author": "Pete Resnick", "text": "

Q: Does someone think that if we do only named groups that you can't implement a particular model that exists now?

", "time": "2023-05-03T16:38:07Z"}, {"author": "Richard Barnes", "text": "

If you want a Slack-like group DM in a distributed setting, you would need to enforce uniqueness of a group DM for a given set of participants, which could be challenging

", "time": "2023-05-03T16:39:02Z"}, {"author": "Jonathan Rosenberg", "text": "

not acceptable imho

", "time": "2023-05-03T16:39:06Z"}, {"author": "Pete Resnick", "text": "

(And no, I don't know why I started questions with \"Q:\". I will now stop.)

", "time": "2023-05-03T16:39:09Z"}, {"author": "Matthew Hodgson", "text": "

just doing named groups (and then 1:1 and adhoc are subsets) sgtm, although you might need to special case 1:1 a bit so you can easily get uniqueness semantics

", "time": "2023-05-03T16:39:11Z"}, {"author": "Matthew Hodgson", "text": "

oh, what richard said.

", "time": "2023-05-03T16:39:15Z"}, {"author": "Matthew Hodgson", "text": "

(except for 1:1)

", "time": "2023-05-03T16:39:23Z"}, {"author": "Mallory Knodel", "text": "

I think the UX should be able to help the users pick the old group if they want the old group but not prevent creation of a new group that is different. I can see the opposite behaviour having real consequences. This scenario just feels inconvenient and messy (acceptable imo)

", "time": "2023-05-03T16:39:44Z"}, {"author": "Richard Barnes", "text": "

i actually think the uniqueness problem is more tractable for 1:1, which seems to argue for handling 1:1 as named groups

", "time": "2023-05-03T16:39:59Z"}, {"author": "Raphael Robert", "text": "

Agreed that we need to agree on 1:1 vs groups

", "time": "2023-05-03T16:40:05Z"}, {"author": "Jonathan Lennox", "text": "

I think the question is not so much whether you can implement a specific model, but whether different implementers will implement that model in a way that presents in a comprehensible way to users. So I think there will need to be some specification of how the various models map onto the group concept.

", "time": "2023-05-03T16:40:07Z"}, {"author": "Jonathan Rosenberg", "text": "

@joel we would not solve this at the MLS layer.

", "time": "2023-05-03T16:41:02Z"}, {"author": "Pete Resnick", "text": "

@Jonathan Lennox If we need to write an Informational document about UI expectations, so be it. We shouldn't try to force UIs with protocol cudgels.

", "time": "2023-05-03T16:41:43Z"}, {"author": "Raphael Robert", "text": "

Doesn't 1:1 boil down to just an access control problem?

", "time": "2023-05-03T16:42:22Z"}, {"author": "Jonathan Lennox", "text": "

It's not so much UIs, as if I create what I intend to be a 1-1 conversation, I don't want you (on a different system) to see it as an invite to the named group UUID-ADHOC-GROUP-Pete-and-Jonathan

", "time": "2023-05-03T16:42:47Z"}, {"author": "Jonathan Rosenberg", "text": "

arrggghhhh

", "time": "2023-05-03T16:42:48Z"}, {"author": "Eric Rescorla", "text": "

Maybe JDR needs to get permission to tallk

", "time": "2023-05-03T16:42:49Z"}, {"author": "Tim Geoghegan", "text": "

I don't see any admin buttons for me to press to grant permission, I'm not sure what's wrong

", "time": "2023-05-03T16:43:10Z"}, {"author": "Eric Rescorla", "text": "

it was a joke

", "time": "2023-05-03T16:43:23Z"}, {"author": "Eric Rescorla", "text": "

Like he is in mode (3

", "time": "2023-05-03T16:43:27Z"}, {"author": "Jonathan Rosenberg", "text": "

it seems like a device seleection problem for me

", "time": "2023-05-03T16:43:29Z"}, {"author": "Jonathan Rosenberg", "text": "

i thought it switcehd it but it reverted - i think? it sticked this time

", "time": "2023-05-03T16:43:40Z"}, {"author": "Jonathan Rosenberg", "text": "

i would like to try one more time.

", "time": "2023-05-03T16:43:46Z"}, {"author": "Pete Resnick", "text": "

@Jonathan Lennox Why not (as a matter of protocol)?

", "time": "2023-05-03T16:43:56Z"}, {"author": "Jonathan Lennox", "text": "

I don't care if the protocol thinks that, but the user shouldn't see it.

", "time": "2023-05-03T16:44:17Z"}, {"author": "Tim Geoghegan", "text": "

Sure jdr, let's give it a try after Rohan

", "time": "2023-05-03T16:44:18Z"}, {"author": "Jonathan Lennox", "text": "

They're different user experience semantics.

", "time": "2023-05-03T16:44:32Z"}, {"author": "Pete Resnick", "text": "

@Jonathan Lennox But that does make it a UI issue.

", "time": "2023-05-03T16:44:40Z"}, {"author": "Jonathan Lennox", "text": "

Well, UX, not UI - it's the semantics of the experience, not the presentation of it that the systems need to agree on.

", "time": "2023-05-03T16:46:21Z"}, {"author": "Matthew Hodgson", "text": "

(we haven't fixed the uniqueness problem for matrix yet - https://github.com/matrix-org/matrix-spec-proposals/blob/travis/msc/immutable-dms/proposals/2199-canonical-dms.md is the surprisingly big proposed solution - and that's just for DMs)

", "time": "2023-05-03T16:47:55Z"}, {"author": "Jonathan Rosenberg", "text": "

The hard part of uniqueness is that the group may already exist in different providers

", "time": "2023-05-03T16:47:56Z"}, {"author": "Pete Resnick", "text": "

@Jonathan Lennox Fair enough

", "time": "2023-05-03T16:48:20Z"}, {"author": "Jonathan Rosenberg", "text": "

so if a group with A,B,C exists on provider one, and then a group with A,B exists on provider 2, and a user on provider 2 adds C, then we have a hard problem

", "time": "2023-05-03T16:48:28Z"}, {"author": "Jonathan Rosenberg", "text": "

this problem also exists for the 1-1 case, i call it out in my doc there is no easy solution i dont think

", "time": "2023-05-03T16:49:09Z"}, {"author": "Richard Barnes", "text": "

@Matthew - Have you solved uniqueness for 1:1? or are 1:1 messages a different special thing?

", "time": "2023-05-03T16:49:18Z"}, {"author": "Mallory Knodel", "text": "

It's only hard if you are forcing A, B, C to only talk in one group. I think having two groups in your scenario is a feature, not a bug.

", "time": "2023-05-03T16:49:31Z"}, {"author": "Matthew Hodgson", "text": "

@Richard Barnes: haven't solved uniqueness for 1:1, beyond MSC2199 (linked above). 1:1 isn't special at all; it's just a room with 2 people and no name.

", "time": "2023-05-03T16:50:31Z"}, {"author": "Matthew Hodgson", "text": "

(actually, i lie: MSC2199 supports unique group-DMs as well as 1:1s)

", "time": "2023-05-03T16:51:59Z"}, {"author": "Jonathan Rosenberg", "text": "

I dont think this can be solved entirely at the MLS layer.

", "time": "2023-05-03T16:52:28Z"}, {"author": "Jonathan Lennox", "text": "

An explicit modality would work for me, if we can agree on all the modalities to support. (It raises the question of whether everyone needs to support all modalities, or whether there needs to be negotiation of them?)

", "time": "2023-05-03T16:53:00Z"}, {"author": "Jonathan Rosenberg", "text": "

i dont hear ekr

", "time": "2023-05-03T16:53:00Z"}, {"author": "Raphael Robert", "text": "

I might remember wrong, but isn't this question excluded by the charter?

", "time": "2023-05-03T16:56:27Z"}, {"author": "Eric Rescorla", "text": "

@Raphael, that's what I'm claiming

", "time": "2023-05-03T16:57:00Z"}, {"author": "Eric Rescorla", "text": "

But the point was to bring this out

", "time": "2023-05-03T16:57:11Z"}, {"author": "Eric Rescorla", "text": "

Note that the next slide is about room portability

", "time": "2023-05-03T16:57:25Z"}, {"author": "Alissa Cooper", "text": "

This is what the charter says is out of scope: \"Interoperable mechanisms for group administration or moderation across systems\"

", "time": "2023-05-03T16:58:09Z"}, {"author": "Eric Rescorla", "text": "

Yes.

", "time": "2023-05-03T16:58:34Z"}, {"author": "Matthew Hodgson", "text": "

hum, i totally missed that in the charter - i saw the word 'moderation' (where i totally agree that moderation mechanisms should be out of scope).

", "time": "2023-05-03T16:59:12Z"}, {"author": "Pete Resnick", "text": "

\"across systems\" seems to be the key bit, no?

", "time": "2023-05-03T16:59:37Z"}, {"author": "Matthew Hodgson", "text": "

but if I (say) want to ban a user from a conversation across systems, surely we have to define a protocol for doing so?

", "time": "2023-05-03T16:59:49Z"}, {"author": "Matthew Hodgson", "text": "

i think i agree with rohan's assertion that we need to define minimal viable semantics that match the GKs

", "time": "2023-05-03T17:00:21Z"}, {"author": "Mallory Knodel", "text": "

administration is very wide. could include adding and naming groups.

", "time": "2023-05-03T17:00:35Z"}, {"author": "Jonathan Rosenberg", "text": "

I think, @rohan is agreeing with the point I just made?

", "time": "2023-05-03T17:01:33Z"}, {"author": "Matthew Hodgson", "text": "

mallory: i'd also expect to be able to (re)name a group from (say) WhatsApp even if the conversation hub happens to be on iMessage or whatever

", "time": "2023-05-03T17:01:40Z"}, {"author": "Matthew Hodgson", "text": "

and feel super frustrated if it... just errored if i tried? (but if the group was created on WhatsApp, it happened to work)?

", "time": "2023-05-03T17:02:10Z"}, {"author": "Mallory Knodel", "text": "

agree. so what is administrative but clearly out of scope

", "time": "2023-05-03T17:02:11Z"}, {"author": "Mallory Knodel", "text": "

moderation agree-- no question that's not in scope. but admin is useful.

", "time": "2023-05-03T17:02:46Z"}, {"author": "Jonathan Lennox", "text": "

There's also the question of what needs to be in the core protocol for an MVP and what can be in a future extension

", "time": "2023-05-03T17:02:58Z"}, {"author": "Eric Rescorla", "text": "

ISTM that the fundamental operations here are closed groups and member eviction

", "time": "2023-05-03T17:03:05Z"}, {"author": "Eric Rescorla", "text": "

I.e., if you're going to have anything

", "time": "2023-05-03T17:03:58Z"}, {"author": "Matthew Hodgson", "text": "

DMA doesn't require group interop until 2026 iirc

", "time": "2023-05-03T17:04:05Z"}, {"author": "Matthew Hodgson", "text": "

so that could be an argument in favour of just ditching access control semantics for now

", "time": "2023-05-03T17:04:20Z"}, {"author": "Matthew Hodgson", "text": "

or \"group administration\", whatever that is :)

", "time": "2023-05-03T17:04:38Z"}, {"author": "Jonathan Rosenberg", "text": "

I dont think naming should be out of scope..

", "time": "2023-05-03T17:05:55Z"}, {"author": "Rohan Mahy", "text": "

I've gotta go drive to the airport

", "time": "2023-05-03T17:06:06Z"}, {"author": "Rohan Mahy", "text": "

may drop

", "time": "2023-05-03T17:06:13Z"}, {"author": "Mallory Knodel", "text": "

also me, i'm out-- see you next time

", "time": "2023-05-03T17:06:18Z"}, {"author": "Jonathan Rosenberg", "text": "

my answer is: protocol has a primitive to set the name. as a user outside of the group, i may or may not have such permissions - and i wont easily nbe able to know. But, if i try ot rename, and the owning provider doesnt authorize me, i get rejected and then i know

", "time": "2023-05-03T17:06:49Z"}, {"author": "Jonathan Rosenberg", "text": "

that is what i was trying to say

", "time": "2023-05-03T17:06:54Z"}, {"author": "Jonathan Rosenberg", "text": "

the protocol should provide a set of primitive operations that a remote user can do, and the protocol supports error messages if their request is rejected

", "time": "2023-05-03T17:07:17Z"}, {"author": "Matthew Hodgson", "text": "

jonathan: that's horrible though if the owning servers do different things (i.e. there's no protocol to coordinate them)

", "time": "2023-05-03T17:07:38Z"}, {"author": "Jonathan Rosenberg", "text": "

I am opposed to trying to support portability at this time. we can consider it in the future.

", "time": "2023-05-03T17:09:31Z"}, {"author": "Eric Rescorla", "text": "

@JDR can you say that live

", "time": "2023-05-03T17:09:54Z"}, {"author": "Jonathan Rosenberg", "text": "

it would be good to have someone do an inventory of the existing access control mechanisms implemented acorss the known gatekeepers and document it - it would make this discusion a lot less meta

", "time": "2023-05-03T17:16:25Z"}, {"author": "Matthew Hodgson", "text": "

yeah, big time

", "time": "2023-05-03T17:16:40Z"}, {"author": "Jonathan Rosenberg", "text": "

also depends on who you include in scope...

", "time": "2023-05-03T17:17:03Z"}, {"author": "Matthew Hodgson", "text": "

i kinda feel like most of the discussions so far boil down to taking the biggest N providers and looking what they do (e.g. for access control, or for 1:1 v group semantics or whatever)

", "time": "2023-05-03T17:17:18Z"}, {"author": "Matthew Hodgson", "text": "

i can do a bunch of grids as well as the access control one :)

", "time": "2023-05-03T17:17:55Z"}, {"author": "Matthew Hodgson", "text": "

and yup, ekr speaks the truth

", "time": "2023-05-03T17:18:08Z"}, {"author": "Tim Geoghegan", "text": "

Thank you, Matthew

", "time": "2023-05-03T17:18:20Z"}, {"author": "Alissa Cooper", "text": "

great, let's record that as your action item, thank you

", "time": "2023-05-03T17:18:22Z"}, {"author": "Matthew Hodgson", "text": "

(i guess i get to be guardian of \"gah no that will design out hub portability\")

", "time": "2023-05-03T17:18:25Z"}, {"author": "Matthew Hodgson", "text": "

(n.b. this isn't portable conversations, but simply \"if the hub goes bang, can the conversation continue\"?)

", "time": "2023-05-03T17:18:51Z"}, {"author": "Alissa Cooper", "text": "

if you already know how the other services do both of those things, listing them out can't hurt. but I think the latter is more pressing, yes.

", "time": "2023-05-03T17:20:00Z"}, {"author": "Jonathan Rosenberg", "text": "

in MLS i thought the commits were signed by the participant who sent them, do i have that wrong? (sorry not as deep on mls as folks here)

", "time": "2023-05-03T17:22:34Z"}, {"author": "Matthew Hodgson", "text": "

(are ekr's slides available online somewhere? i need to flip back & forth a bit)

", "time": "2023-05-03T17:22:58Z"}, {"author": "Raphael Robert", "text": "

https://datatracker.ietf.org/meeting/interim-2023-mimi-01/materials/slides-interim-2023-mimi-01-sessa-mimi-transport-requirements-00.pdf

", "time": "2023-05-03T17:23:15Z"}, {"author": "Matthew Hodgson", "text": "

dankon

", "time": "2023-05-03T17:23:21Z"}, {"author": "Jonathan Rosenberg", "text": "

ah ok - well i would think that, the only viable rule is , \"i accept a commit from any member currently in the group, and not from anyone outside\"

", "time": "2023-05-03T17:23:29Z"}, {"author": "Eric Rescorla", "text": "

So I think this implies that we need an MLS ACL languge

", "time": "2023-05-03T17:26:22Z"}, {"author": "Matthew Hodgson", "text": "

this is the same problem as server-controlled access control (\"does bob have permission to set the room name to be Foo\") imo - just as we need a common simple ACL semantic there, you need a similar one to control group membership

", "time": "2023-05-03T17:29:41Z"}, {"author": "Matthew Hodgson", "text": "

i think language is too strong a term though

", "time": "2023-05-03T17:29:45Z"}, {"author": "Matthew Hodgson", "text": "

it could literally be \"what seniority do you need to be able to invite\"?

", "time": "2023-05-03T17:30:50Z"}, {"author": "Jonathan Rosenberg", "text": "

i understand that the acl is not enforced by the user. but, if the acl is not shown to and approved by the user, what prevents a malicious acl - one which allows anyone - to be introduced?

", "time": "2023-05-03T17:31:09Z"}, {"author": "Matthew Hodgson", "text": "

(and tough if you want to do weird access control decisions like \"only users with M in their name are allowed to invite\")

", "time": "2023-05-03T17:31:10Z"}, {"author": "Matthew Hodgson", "text": "

jonathan: you'd absolutely show it to the user

", "time": "2023-05-03T17:31:21Z"}, {"author": "Matthew Hodgson", "text": "

\"anyone can invite to this group\" versus \"only admins can invite to this group\"

", "time": "2023-05-03T17:31:49Z"}, {"author": "Britta Hale", "text": "

I have to drop off - thank you everyone for helping push this effort forward.

", "time": "2023-05-03T17:33:48Z"}, {"author": "Matthew Hodgson", "text": "

what is the point of an ACL if it's hardcoded for everyone in the protocol?

", "time": "2023-05-03T17:35:03Z"}, {"author": "Rohan Mahy", "text": "

I agree with Joel

", "time": "2023-05-03T17:35:25Z"}, {"author": "Matthew Hodgson", "text": "

i think we might have different definitions of ACL then

", "time": "2023-05-03T17:35:36Z"}, {"author": "Matthew Hodgson", "text": "

in that this sounds like a \"meta-ACL\" almost?

", "time": "2023-05-03T17:35:49Z"}, {"author": "Matthew Hodgson", "text": "

i.e. a framework for defining ACLs?

", "time": "2023-05-03T17:35:55Z"}, {"author": "Jonathan Rosenberg", "text": "

this also does intersect with the discussion we just had on flexible room moderation rules... if we support complex room moderation do we need such moderation rules expressed as mls acls???

", "time": "2023-05-03T17:36:08Z"}, {"author": "Matthew Hodgson", "text": "

jonathan: i was assuming the answer is 'yes' :)

", "time": "2023-05-03T17:36:29Z"}, {"author": "Matthew Hodgson", "text": "

+1000 to EKR

", "time": "2023-05-03T17:37:00Z"}, {"author": "Joel", "text": "

i see. no, you're right. i was confused for as second there.

\n

I also mean not only is there one \"meta-ACL\" but we also agree on the actual ACL.

", "time": "2023-05-03T17:37:01Z"}, {"author": "Eric Rescorla", "text": "

@Raphael: 100% agreed

", "time": "2023-05-03T17:37:44Z"}, {"author": "Matthew Hodgson", "text": "

so i love the idea of MLS asserting the ACL rules via a single MIMI ACL extension. But different rooms would have different (simple) rules

", "time": "2023-05-03T17:37:48Z"}, {"author": "Joel", "text": "

So for e.g. the list of current moderators in a room is part of what ends up getting fed into the cryptographic key for the room. Also we all agree on what a moderator can do.

", "time": "2023-05-03T17:37:51Z"}, {"author": "Eric Rescorla", "text": "

I'm just saying we need to have a way to make sure everyone knows what the group rule is

", "time": "2023-05-03T17:37:56Z"}, {"author": "Jonathan Rosenberg", "text": "

it is still not clear to me, how the acl would be constructed in a real system except for - the user mucking around with some UI and APIs exposed on the server, and then the server emits the acl... which introduces a risk of server attack sending wrong acl

", "time": "2023-05-03T17:39:10Z"}, {"author": "Matthew Hodgson", "text": "

jonathan: surely if you have a basic protocol for defining ACLs, then the client can just emit it.

", "time": "2023-05-03T17:39:38Z"}, {"author": "Rohan Mahy", "text": "

It's baked into the authorization policy language which is included in the MLS group

", "time": "2023-05-03T17:39:40Z"}, {"author": "Matthew Hodgson", "text": "

giving the server the ability to go wild on auth policies is a disaster in the making, imo

", "time": "2023-05-03T17:39:56Z"}, {"author": "Rohan Mahy", "text": "

You specify a profile of what is mandatory to implements and other options have well-defined semantics which is optional behavior

", "time": "2023-05-03T17:40:21Z"}, {"author": "Matthew Hodgson", "text": "

(just as different hubs implementing different auth policies would be)

", "time": "2023-05-03T17:40:21Z"}, {"author": "Matthew Hodgson", "text": "

Matrix today already effectively lets you define the ACLs on the client (given the server can be embedded in the client): these are then signed and authorised by consistent rules by the other instances. You don't have to trust a centralised server.

", "time": "2023-05-03T17:45:56Z"}, {"author": "Jonathan Rosenberg", "text": "

@Matthew but surely that is not how it works

", "time": "2023-05-03T17:46:13Z"}, {"author": "Matthew Hodgson", "text": "

so to grandfather existing stuff, the clients will have to sign their ACL rules

", "time": "2023-05-03T17:46:51Z"}, {"author": "Matthew Hodgson", "text": "

just like they'll have to speak MLS as a whole

", "time": "2023-05-03T17:47:01Z"}, {"author": "Rohan Mahy", "text": "

MLS is Greenfield for all the gatekeepers.

", "time": "2023-05-03T17:47:13Z"}, {"author": "Rohan Mahy", "text": "

Translating their existing policy rules into this policy language should just work

", "time": "2023-05-03T17:47:29Z"}, {"author": "Rohan Mahy", "text": "

should just work

", "time": "2023-05-03T17:47:29Z"}, {"author": "Matthew Hodgson", "text": "

precisely ^

", "time": "2023-05-03T17:47:37Z"}, {"author": "Tim Geoghegan", "text": "

IIUC the debate here is about whether the ACLs are expressed cryptographically at the MLS layer, or just as policy evaluated in software above MLS. That seems orthogonal to whether the server gets to push ACLs onto clients (though that remains a significant concern).

", "time": "2023-05-03T17:48:49Z"}, {"author": "Matthew Hodgson", "text": "

if they're expressed cryptographically at the MLS layer, the server can't push, as the server isn't an MLS peer, no?

", "time": "2023-05-03T17:49:24Z"}, {"author": "Matthew Hodgson", "text": "

(so it's not orthogonal, alas)

", "time": "2023-05-03T17:49:43Z"}, {"author": "Tim Geoghegan", "text": "

Ah, that makes sense, thank you

", "time": "2023-05-03T17:50:03Z"}, {"author": "Matthew Hodgson", "text": "

in terms of jonathan's security problem: if you grandfather an existing non-MIMI chat into MIMI, then yes, you have to trust the legacy server-controlled-access-control system from lying about whether a given chat was private or not. But once it's been made MIMIfied, any further ACL will need to be client-generated, no?

", "time": "2023-05-03T17:52:58Z"}, {"author": "Jonathan Rosenberg", "text": "

I dont think ekrs comments address my concern but i also feel like this is going in circles and its possible i am just misunderstanding something here.

", "time": "2023-05-03T17:56:20Z"}, {"author": "Jonathan Rosenberg", "text": "

so basically i agree with alissa - a diagram/doc is needed

", "time": "2023-05-03T17:56:33Z"}, {"author": "Eric Rescorla", "text": "

I'd be happy to try to do a draft, I suppose

", "time": "2023-05-03T17:56:51Z"}, {"author": "Matthew Hodgson", "text": "

i could propose a mini-language too (which would basically the matrix auth rule system, predictably)

", "time": "2023-05-03T17:57:34Z"}, {"author": "Konrad Kohbrok", "text": "

Sorry, who just volunteered?

", "time": "2023-05-03T17:57:51Z"}, {"author": "Jonathan Rosenberg", "text": "

Eric Rescolra

", "time": "2023-05-03T17:58:02Z"}, {"author": "Konrad Kohbrok", "text": "

Thanks!

", "time": "2023-05-03T17:58:08Z"}, {"author": "Matthew Hodgson", "text": "

or ekr: we could do it joint if you want

", "time": "2023-05-03T17:58:10Z"}, {"author": "Raphael Robert", "text": "

Happy to present next time

", "time": "2023-05-03T17:58:20Z"}, {"author": "Jonathan Rosenberg", "text": "

i think this helped to make progress

", "time": "2023-05-03T17:58:38Z"}, {"author": "Raphael Robert", "text": "

Not sure we need weekly \u2013 biweekly should be enough

", "time": "2023-05-03T17:58:56Z"}, {"author": "Jonathan Rosenberg", "text": "

i think weekly may be too frequent, not enough time perhaps to write something up as followups as needed. but dont feel that strongly

", "time": "2023-05-03T17:59:11Z"}, {"author": "Raphael Robert", "text": "

But generally agree on more interims

", "time": "2023-05-03T17:59:15Z"}, {"author": "Matthew Hodgson", "text": "

biweekly wfm

", "time": "2023-05-03T17:59:17Z"}, {"author": "Rohan Mahy", "text": "

Biweekly

", "time": "2023-05-03T17:59:20Z"}, {"author": "Eric Rescorla", "text": "

biweekly > weekly

", "time": "2023-05-03T17:59:21Z"}, {"author": "Konrad Kohbrok", "text": "

Biweekly

", "time": "2023-05-03T17:59:21Z"}, {"author": "Jonathan Rosenberg", "text": "

so biweekly

", "time": "2023-05-03T17:59:24Z"}, {"author": "Joel", "text": "

biweekly

", "time": "2023-05-03T17:59:29Z"}, {"author": "Matthew Hodgson", "text": "

(is biweekly twice a week or every 2 weeks? O:-)

", "time": "2023-05-03T17:59:34Z"}, {"author": "Rohan Mahy", "text": "

Sorry. Every 2 weeks

", "time": "2023-05-03T17:59:37Z"}, {"author": "Richard Barnes", "text": "

i assume \"biweekly is every two weeks\"

", "time": "2023-05-03T17:59:41Z"}, {"author": "Matthew Hodgson", "text": "

diweekly ;P

", "time": "2023-05-03T17:59:47Z"}, {"author": "Rohan Mahy", "text": "

Bi-weekly means twice a week

", "time": "2023-05-03T17:59:47Z"}, {"author": "Jonathan Rosenberg", "text": "

every two weeks, NOT twice a week ;)

", "time": "2023-05-03T17:59:49Z"}, {"author": "Raphael Robert", "text": "

@matthew every fortnight

", "time": "2023-05-03T17:59:50Z"}, {"author": "Richard Barnes", "text": "

semiweekly

", "time": "2023-05-03T17:59:55Z"}, {"author": "Rohan Mahy", "text": "

Yes

", "time": "2023-05-03T18:00:02Z"}, {"author": "Richard Barnes", "text": "

yes @Raphael ,fortnightly

", "time": "2023-05-03T18:00:06Z"}, {"author": "Matthew Hodgson", "text": "

(demiweekly)

", "time": "2023-05-03T18:00:15Z"}, {"author": "Jonathan Rosenberg", "text": "

thanks everyone

", "time": "2023-05-03T18:00:18Z"}, {"author": "Matthew Hodgson", "text": "

thanks all :)

", "time": "2023-05-03T18:00:19Z"}, {"author": "Richard Barnes", "text": "

hemisemdemiweekly

", "time": "2023-05-03T18:00:22Z"}, {"author": "Konrad Kohbrok", "text": "

Will do.

", "time": "2023-05-03T18:00:39Z"}, {"author": "Konrad Kohbrok", "text": "

No worries.

", "time": "2023-05-03T18:00:41Z"}, {"author": "Alissa Cooper", "text": "

https://notes.ietf.org/notes-ietf-interim-2023-mimi-01-mimi#

", "time": "2023-05-03T18:00:41Z"}]