[{"author": "Christopher Patton", "text": "

Richard is online!

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

one thing to note is that every client belongs to a participant, though not every participant has a client that is a member

", "time": "2023-11-09T08:36:07Z"}, {"author": "Daniel Gillmor", "text": "

in slide 5, there is no visual representation of which client belongs to which users, other than the numbers (e.g., user 2 has clients 2a and 2b). There should be arrows connecting them to explicitly represent those relationships.

", "time": "2023-11-09T08:37:35Z"}, {"author": "Rohan Mahy", "text": "

I think all the user-specific stuff is in the pink box

", "time": "2023-11-09T08:43:32Z"}, {"author": "Daniel Gillmor", "text": "

participant list is a superset of the MLS group

", "time": "2023-11-09T08:43:39Z"}, {"author": "Daniel Gillmor", "text": "

so, add to participant before adding to MLS; remove from MLS before removing from participant.

", "time": "2023-11-09T08:44:00Z"}, {"author": "Rohan Mahy", "text": "

but the participant can be banned but be in the MLS group while waiting for a Commit

", "time": "2023-11-09T08:44:32Z"}, {"author": "Jonathan Hoyland", "text": "

So before I can be banned I have to be removed. So during removal I can rejoin?

", "time": "2023-11-09T08:44:37Z"}, {"author": "Daniel Gillmor", "text": "

i think you can be banned but the ban can not have taken effect yet

", "time": "2023-11-09T08:44:54Z"}, {"author": "Konrad Kohbrok", "text": "

The MLS group state can be lagging behind the participant list.

", "time": "2023-11-09T08:45:15Z"}, {"author": "Daniel Gillmor", "text": "

not for removal

", "time": "2023-11-09T08:45:42Z"}, {"author": "Konrad Kohbrok", "text": "

That's because changes to the MLS group require a client to do a commit, while changes to the participant list can be made by servers.

", "time": "2023-11-09T08:45:47Z"}, {"author": "Daniel Gillmor", "text": "

that doesn't match slide 8, @Konrad Kohbrok

", "time": "2023-11-09T08:46:04Z"}, {"author": "Konrad Kohbrok", "text": "

It's just a result of the way that MLS works. However, if the state lags behind clients MUST do a commit before they can send messages.

", "time": "2023-11-09T08:47:08Z"}, {"author": "Konrad Kohbrok", "text": "

If you just look at the points in time where clients send application messages, it doesn't lag.

", "time": "2023-11-09T08:47:32Z"}, {"author": "Daniel Gillmor", "text": "

so when a message comes in from a client that doesn't change the MLS state as required, what happens to that message?

", "time": "2023-11-09T08:47:53Z"}, {"author": "Konrad Kohbrok", "text": "

It should be dropped by the Hub.

", "time": "2023-11-09T08:48:37Z"}, {"author": "Daniel Gillmor", "text": "

does the client know that it was dropped? how should the client respond to that?

", "time": "2023-11-09T08:49:13Z"}, {"author": "Jacques Latour", "text": "

for message transport, seems a bit similar to proposed routing intermediaries as documented in ToIP.... See section #4.

\n

https://www.trustoverip.org/blog/2023/08/31/mid-year-progress-report-on-the-toip-trust-spanning-protocol/

", "time": "2023-11-09T08:49:47Z"}, {"author": "Konrad Kohbrok", "text": "

We haven't described the error responses, but the client should do a commit first that eliminates the lag.

", "time": "2023-11-09T08:49:58Z"}, {"author": "Daniel Gillmor", "text": "

how does the client know that it is obliged to commit the MLS state change before doing other things? how does it know what state change is being forced by the server?

", "time": "2023-11-09T08:49:58Z"}, {"author": "Daniel Gillmor", "text": "

what are the range of MLS commits that the server can require?

", "time": "2023-11-09T08:50:36Z"}, {"author": "Konrad Kohbrok", "text": "

It's mandated by MLS. If the underlying MLS implementation is correct, it should error out.

", "time": "2023-11-09T08:50:37Z"}, {"author": "Daniel Gillmor", "text": "

i don't understand -- MLS doesn't know anything about the participant list

", "time": "2023-11-09T08:51:07Z"}, {"author": "Daniel Gillmor", "text": "

or the authz policy

", "time": "2023-11-09T08:51:14Z"}, {"author": "Daniel Gillmor", "text": "

i'll ask at the mic, because i'm assuming i'm not the only confused person

", "time": "2023-11-09T08:51:53Z"}, {"author": "Cullen Jennings", "text": "

+1 on unreasonable to call for adoption on stuff that missed the deadline

", "time": "2023-11-09T08:52:34Z"}, {"author": "Richard Barnes", "text": "

yeah, i don't think we intended to ask for an actual adoption call here. a sense of the room could be nice.

", "time": "2023-11-09T08:54:52Z"}, {"author": "Alissa Cooper", "text": "

also the arch doc was posted a few weeks ago and it hasn't changed much

", "time": "2023-11-09T08:56:02Z"}, {"author": "Alissa Cooper", "text": "

since the prior version

", "time": "2023-11-09T08:56:15Z"}, {"author": "Daniel Gillmor", "text": "

+1 @Richard Barnes -- there's no way to do this without specifying these things, if we want federated interop

", "time": "2023-11-09T08:58:05Z"}, {"author": "Rohan Mahy", "text": "

regarding @Daniel Gillmor 's question, your client (dkg) has a copy of the policy from the green box (it is a GroupContextExtension which is shared among all members of the MLS group). This will say which operations clients are authorized to do. A common policy is to commit pending proposals in a particular time and way. Likewise, the client might also be permitted to originate a Commit with their own Remove proposals.

", "time": "2023-11-09T08:58:36Z"}, {"author": "Rohan Mahy", "text": "

To ekr's question, draft-mahy-mimi-group-chat does actually cover all these cases and an example authorization policy

", "time": "2023-11-09T08:59:19Z"}, {"author": "Daniel Gillmor", "text": "

please not \"this is one way, here's another\". the IETF has two major curses: the curse of the deployed base, and the curse of two (or more) different ways to do a thing. MIMI is lucky because we don't currently have the curse of the deployed base, let's not embrace the other.

", "time": "2023-11-09T09:00:07Z"}, {"author": "Rohan Mahy", "text": "

Daniel Gillmor said:

\n
\n

i don't understand -- MLS doesn't know anything about the participant list

\n
\n

The client has the participant list and policy. that state is protected in MLS with a GCE

", "time": "2023-11-09T09:00:51Z"}, {"author": "Richard Barnes", "text": "

As Rohan says, we are extending the MLS state so that it can confirm higher-level state

", "time": "2023-11-09T09:01:30Z"}, {"author": "Michael B", "text": "

@Daniel Gillmor , I think MIMI has some kind of deployed base, in the form of gatekeepers!

", "time": "2023-11-09T09:01:38Z"}, {"author": "Eric Rescorla", "text": "

Rohan Mahy said:

\n
\n

To ekr's question, draft-mahy-mimi-group-chat does actually cover all these cases and an example authorization policy

\n
\n

So you'll be proposing to merge that into here?

", "time": "2023-11-09T09:02:22Z"}, {"author": "Daniel Gillmor", "text": "

@Rohan Mahy thanks, that makes it clearer to me, but the situation where ekr gets banned is such that the green box (in the GCE) got updated. how did it get updated?

", "time": "2023-11-09T09:02:30Z"}, {"author": "Daniel Gillmor", "text": "

maybe all the green boxes should just pre-emptively ban ekr so we don't need to worry about this use case.

", "time": "2023-11-09T09:05:26Z"}, {"author": "Eric Rescorla", "text": "

Yeah, but what about \"ekr2\"?

", "time": "2023-11-09T09:05:37Z"}, {"author": "Daniel Gillmor", "text": "

i think that guy is probably ok

", "time": "2023-11-09T09:05:47Z"}, {"author": "Bron Gondwana", "text": "

ask regext for a regex

", "time": "2023-11-09T09:05:53Z"}, {"author": "Bron Gondwana", "text": "

just reuse the evil bit

", "time": "2023-11-09T09:06:10Z"}, {"author": "Richard Barnes", "text": "

@EKR we have been folding in pieces from -group-chat as we work up the level of detail

", "time": "2023-11-09T09:07:33Z"}, {"author": "Jonathan Hoyland", "text": "

Isn't it better to use a better AEAD?

", "time": "2023-11-09T09:12:42Z"}, {"author": "Richard Barnes", "text": "

@Jonathan - no, as EKR says, anyone could generate a fresh valid AEAD representation

", "time": "2023-11-09T09:15:55Z"}, {"author": "Richard Barnes", "text": "

Also, this problem has been solved with proxied fetches in practice

", "time": "2023-11-09T09:16:49Z"}, {"author": "Jonathan Hoyland", "text": "

Require OHTTP?

", "time": "2023-11-09T09:17:08Z"}, {"author": "Eric Rescorla", "text": "

It's just not a feature of AEAD to prevent someone who has the key from substituting the content, because the key is not bound to the content

", "time": "2023-11-09T09:17:16Z"}, {"author": "Eric Rescorla", "text": "

Like that's the nature of AEAD

", "time": "2023-11-09T09:18:05Z"}, {"author": "Benjamin Beurdouche", "text": "

Jonathan Hoyland said:

\n
\n

Require OHTTP?

\n
\n

Would be nice, but it puts small providers in a difficult position because they have to find (and pay for) some proxy server

", "time": "2023-11-09T09:20:50Z"}, {"author": "Jonathan Lennox", "text": "

If you're distributing the content to all the hubs, that doesn't seem that different than just making them internal content in MLS, and making it selective whether the clients download them.

", "time": "2023-11-09T09:21:17Z"}, {"author": "Jonathan Hoyland", "text": "

Eric Rescorla said:

\n
\n

It's just not a feature of AEAD to prevent someone who has the key from substituting the content, because the key is not bound to the content

\n
\n

Hmm, I thought there were key and hash committing AEADs, but it's not my area of expertise.

", "time": "2023-11-09T09:21:38Z"}, {"author": "Mallory Knodel", "text": "

Not sure why you couldn't account for too large files in the client

", "time": "2023-11-09T09:22:15Z"}, {"author": "Mallory Knodel", "text": "

But I think that's only one example of the problem Cullen explained

", "time": "2023-11-09T09:22:26Z"}, {"author": "Benjamin Beurdouche", "text": "

Jonathan Lennox said:

\n
\n

If you're distributing the content to all the hubs, that doesn't seem that different than just making them internal content in MLS, and making it selective whether the clients download them.

\n
\n

The main issue I see with that is that we would keep N different encrypted copies of that data (if I understood you correctly)

", "time": "2023-11-09T09:23:09Z"}, {"author": "Richard Barnes", "text": "

@Jonathan - No, key/hash-committing AEADs prevent changing the key+content but not the AEAD tag. No AEAD stops you changing the tag as well -- otherwise you couldn't encrypt multiple values!

", "time": "2023-11-09T09:23:54Z"}, {"author": "Simon Friedberger", "text": "

Benjamin Beurdouche said:

\n
\n

Jonathan Lennox said:

\n
\n

If you're distributing the content to all the hubs, that doesn't seem that different than just making them internal content in MLS, and making it selective whether the clients download them.

\n
\n

The main issue I see with that is that we would keep N different encrypted copies of that data (if I understood you correctly)

\n
\n

Do you mean if the content is sent in multiple chats? i.e. are you talking about dedup?

", "time": "2023-11-09T09:24:23Z"}, {"author": "Benjamin Beurdouche", "text": "

yes, sorry

", "time": "2023-11-09T09:25:51Z"}, {"author": "Mallory Knodel", "text": "

only send this if you really need to? then this is not a problem for the protocol.

", "time": "2023-11-09T09:26:23Z"}, {"author": "Eric Rescorla", "text": "

O-HTTP doesn't help here b/c it's the fetch that leaks the information, more than the IP address of the client

", "time": "2023-11-09T09:26:44Z"}, {"author": "Eric Rescorla", "text": "

After all, Web bugs come from unpredicted IP addressers

", "time": "2023-11-09T09:27:02Z"}, {"author": "Daniel Gillmor", "text": "

@Eric Rescorla web bugs leak two things: read status, and network location

", "time": "2023-11-09T09:28:18Z"}, {"author": "Eric Rescorla", "text": "

@Daniel Gillmor No argument there.

", "time": "2023-11-09T09:28:40Z"}, {"author": "Ted Hardie", "text": "

I like this proposal, and I think it would be generating a PR for it.

", "time": "2023-11-09T09:28:46Z"}, {"author": "Ted Hardie", "text": "

Sorry, \"would be worth generating a PR for it\".

", "time": "2023-11-09T09:29:09Z"}, {"author": "Daniel Gillmor", "text": "

O-HTTP defends the network location part, but not the read part (though the server can't know which MLS group is reading it)

", "time": "2023-11-09T09:29:52Z"}, {"author": "Richard Barnes", "text": "

@Travis Ralston maybe we could stub this into mimi-protocol?

", "time": "2023-11-09T09:30:04Z"}, {"author": "Richard Barnes", "text": "

(this == room-associated content, fetched through MIMI)

", "time": "2023-11-09T09:30:16Z"}, {"author": "Travis Ralston", "text": "

yea, we'll need some sort of server-server API for it. It's largely been excluded while we focus on non-media message delivery first :)

", "time": "2023-11-09T09:30:54Z"}, {"author": "Richard Barnes", "text": "

@Jonathan Lennox One minor amendment -- you might want to not use the message encapsulation, just so you can have a little more flexibility with the encryption key

", "time": "2023-11-09T09:31:14Z"}, {"author": "Travis Ralston", "text": "

(as one of the Matrix guys responsible for federated media, I have Thoughts and Ideas)

", "time": "2023-11-09T09:31:19Z"}, {"author": "Richard Barnes", "text": "

@Travis Ralston server-server API is everything this group does :)

", "time": "2023-11-09T09:31:32Z"}, {"author": "Jonathan Lennox", "text": "

@Richard Barnes I am sure you are smarter than I am about how this would need to be done. :)

", "time": "2023-11-09T09:31:43Z"}, {"author": "Matthew Hodgson", "text": "

+100000 to using content hashes as IDs

", "time": "2023-11-09T09:32:38Z"}, {"author": "Matthew Hodgson", "text": "

we made the shift in ~2018 in Matrix due to lots of headaches caused by maliciously duplicate msg IDs

", "time": "2023-11-09T09:33:12Z"}, {"author": "Matthew Hodgson", "text": "

and/or maliciously mutated content

", "time": "2023-11-09T09:33:40Z"}, {"author": "Matthew Hodgson", "text": "

and haven't looked back.

", "time": "2023-11-09T09:33:43Z"}, {"author": "Konrad Kohbrok", "text": "

As long as we don't put a hash of the plain text into the AAD ...

", "time": "2023-11-09T09:33:43Z"}, {"author": "Jonathan Hoyland", "text": "

How does a duplicate message get delivered both before and after a user joins the group? If the first was sent before the second should be impossible to decrypt, no?

", "time": "2023-11-09T09:33:51Z"}, {"author": "Simon Friedberger", "text": "

Isn't the MLS layer already solving the issue of making message delivery reliable and acknowledged?

", "time": "2023-11-09T09:33:51Z"}, {"author": "Matthew Hodgson", "text": "

well, yes. hash of the cipher text obviously.

", "time": "2023-11-09T09:33:54Z"}, {"author": "Jonathan Hoyland", "text": "

Ah, if it was resent

", "time": "2023-11-09T09:34:31Z"}, {"author": "Richard Barnes", "text": "

@Jonathan Hoyland now is the moment for key-committing AEAD!

", "time": "2023-11-09T09:35:08Z"}, {"author": "Jonathan Hoyland", "text": "

Absolutely! No to AES-GCM

", "time": "2023-11-09T09:35:34Z"}, {"author": "Raphael Robert", "text": "

Richard Barnes said:

\n
\n

Jonathan Hoyland now is the moment for key-committing AEAD!

\n
\n

I think it's always the time for that

", "time": "2023-11-09T09:35:43Z"}, {"author": "Eric Rescorla", "text": "

Daniel Gillmor said:

\n
\n

O-HTTP defends the network location part, but not the read part (though the server can't know which MLS group is reading it)

\n
\n

Well doesn't the server just generate a fresh resource? That's how web bugs work normally

", "time": "2023-11-09T09:38:02Z"}, {"author": "Travis Ralston", "text": "

Richard Barnes said:

\n
\n

Travis Ralston maybe we could stub this into mimi-protocol?

\n
\n

ftr, opened as issue: https://github.com/bifurcation/ietf-mimi-protocol/issues/24

", "time": "2023-11-09T09:38:14Z"}, {"author": "Richard Barnes", "text": "

Big fan of causal order. Wanted to do it in MLS, but we didn't get to it.

", "time": "2023-11-09T09:39:14Z"}, {"author": "Eric Rescorla", "text": "

@Richard Barnes maybe learn about Special Relativity?

", "time": "2023-11-09T09:39:32Z"}, {"author": "Richard Barnes", "text": "

Spooky Messaging at a Distance

", "time": "2023-11-09T09:39:57Z"}, {"author": "Daniel Gillmor", "text": "

consistent ordering is impossible in priniciple when you get to the UI/UX layer.

", "time": "2023-11-09T09:40:12Z"}, {"author": "Eric Rescorla", "text": "

y

", "time": "2023-11-09T09:40:39Z"}, {"author": "Richard Barnes", "text": "

yeah, the only thing we can solve here is what information the protocol can provide to guide the UI/UX

", "time": "2023-11-09T09:41:38Z"}, {"author": "Matthew Hodgson", "text": "

personally, i think we made a mistake in Matrix by doing \"stream ordering\" (i.e. the order the msg arrived at your server in) and instead we should use \"topological order\" (i.e. causal DAG-based ordering)

", "time": "2023-11-09T09:42:24Z"}, {"author": "Richard Barnes", "text": "

Fortunately we're all consistent in viewing @Cullen Jennings as batshit crazy

", "time": "2023-11-09T09:42:35Z"}, {"author": "Matthew Hodgson", "text": "

but the UX for topo ordering really ends up being exotic. plus things like read receipts end up having to be per-message rather than \"read-up-to\" markers.

", "time": "2023-11-09T09:42:46Z"}, {"author": "Konrad Kohbrok", "text": "

But in contrast to Matrix, we can agree that the Hub does the ordering.

", "time": "2023-11-09T09:42:59Z"}, {"author": "Matthew Hodgson", "text": "

plus from a user perspective, a topo ordering could be completely and utterly incoherent.

", "time": "2023-11-09T09:43:02Z"}, {"author": "Jonathan Lennox", "text": "

I feel like thinking about this in the case of about MIMI-over-DTN where one of the servers is on Mars.

", "time": "2023-11-09T09:43:16Z"}, {"author": "Richard Barnes", "text": "

Seems like causal ordering + hub-provided timestamp could be best of both worlds

", "time": "2023-11-09T09:43:19Z"}, {"author": "Matthew Hodgson", "text": "

and yup, the hub could define the consistent ordering in MIMI to help solve this problem.

", "time": "2023-11-09T09:43:19Z"}, {"author": "Richard Barnes", "text": "

@Jonathan Lennox then we really will have special relativity considerations!

", "time": "2023-11-09T09:44:24Z"}, {"author": "Simon Friedberger", "text": "

@Matthew Hodgson So, we are not assuming that we can rely on working federation for a good UX? Because if you assume that, the \"messages pop up somewhere three days ago in the history\" goes away, right?

", "time": "2023-11-09T09:44:51Z"}, {"author": "Eric Rescorla", "text": "

What I had in mind was allowing the server to sort within the causal order

", "time": "2023-11-09T09:45:10Z"}, {"author": "Valentin Go\u0219u", "text": "

Sounds like we need a consensus algorithm to agree on the timestamps :)

", "time": "2023-11-09T09:46:19Z"}, {"author": "Cullen Jennings", "text": "

+1 DKG

", "time": "2023-11-09T09:46:34Z"}, {"author": "Eric Rescorla", "text": "

Maybe we could modify MLS so only one person can write at a time, like token ring

", "time": "2023-11-09T09:47:13Z"}, {"author": "Eric Rescorla", "text": "

Then we would have a full order

", "time": "2023-11-09T09:47:18Z"}, {"author": "Richard Barnes", "text": "

Causal ordering conveniently gets you loss detection for free

", "time": "2023-11-09T09:47:20Z"}, {"author": "Richard Barnes", "text": "

@Benjamin Beurdouche ^^^

", "time": "2023-11-09T09:47:34Z"}, {"author": "Richard Barnes", "text": "

(for cheaper than AppAck)

", "time": "2023-11-09T09:47:39Z"}, {"author": "Eric Rescorla", "text": "

Richard Barnes said:

\n
\n

Causal ordering conveniently gets you loss detection for free

\n
\n

Only partial loss detection, I think

", "time": "2023-11-09T09:47:41Z"}, {"author": "Eric Rescorla", "text": "

Because of tails

", "time": "2023-11-09T09:47:44Z"}, {"author": "Richard Barnes", "text": "

fair

", "time": "2023-11-09T09:47:51Z"}, {"author": "Raphael Robert", "text": "

I think AppAck covers exactly the gap causal ordering doesn't cover

", "time": "2023-11-09T09:49:22Z"}, {"author": "Rohan Mahy", "text": "

Eric Rescorla said:

\n
\n

Rohan Mahy said:

\n
\n

To ekr's question, draft-mahy-mimi-group-chat does actually cover all these cases and an example authorization policy

\n
\n

So you'll be proposing to merge that into here?

\n
\n

As we get consensus on each piece we are merging that functionality into the protocol doc, yes

", "time": "2023-11-09T09:51:06Z"}, {"author": "Eric Rescorla", "text": "

SG

", "time": "2023-11-09T09:51:15Z"}, {"author": "Matthew Hodgson", "text": "

Simon Friedberger said:

\n
\n

Matthew Hodgson So, we are not assuming that we can rely on working federation for a good UX? Because if you assume that, the \"messages pop up somewhere three days ago in the history\" goes away, right?

\n
\n

relying on working federation feels quite aspirational in a heterogenous network - look at SMTP, XMPP, Matrix etc today. or even SS7.

", "time": "2023-11-09T09:52:48Z"}, {"author": "Daniel Gillmor", "text": "

i don't think causal ordering + server-supplied timestamps alone gives you a coherent UX. for example, it could allow the server to \"pin\" a message to the future. you'd also need the server to somehow commit to the timestamping in a way that would ensure all the clients see the same state.

", "time": "2023-11-09T09:53:03Z"}, {"author": "Matthew Hodgson", "text": "

plus i think Cullen had a point about avoidable human race conditions.

", "time": "2023-11-09T09:53:10Z"}, {"author": "Matthew Hodgson", "text": "

yup, the pinning problem is one of the reasons we haven't adopted topo ordering in Matrix (yet).

", "time": "2023-11-09T09:53:32Z"}, {"author": "Matthew Hodgson", "text": "

ironically we have an opposite-pinning problem where people graffiti the history of rooms by injecting msgs topologically from 1970...

", "time": "2023-11-09T09:53:59Z"}, {"author": "Richard Barnes", "text": "

:raised_hand:

", "time": "2023-11-09T09:54:14Z"}, {"author": "Richard Barnes", "text": "

:raised_hand:

", "time": "2023-11-09T09:54:33Z"}, {"author": "Eric Rescorla", "text": "

I read the old MIMI-DS has it changed?

", "time": "2023-11-09T09:54:41Z"}, {"author": "Richard Barnes", "text": "

(for protocol and DS)

", "time": "2023-11-09T09:54:43Z"}, {"author": "Richard Barnes", "text": "

@Eric Rescorla yes, but mainly to clean up the interface to the protocol

", "time": "2023-11-09T09:55:01Z"}, {"author": "Raphael Robert", "text": "

Eric Rescorla said:

\n
\n

I read the old MIMI-DS has it changed?

\n
\n

As Konrad just said, some stuff was dropped and it was a bit streamlined

", "time": "2023-11-09T09:55:10Z"}, {"author": "Simon Friedberger", "text": "

Matthew Hodgson said:

\n
\n

relying on working federation feels quite aspirational in a heterogenous network - look at SMTP, XMPP, Matrix etc today. or even SS7.

\n
\n

Yes, but optimizing the UX for the case when things are broken seems like the wrong approach.

", "time": "2023-11-09T09:56:12Z"}, {"author": "Daniel Gillmor", "text": "

the human-visible race conditions
\nMatthew Hodgson said:

\n
\n

ironically we have an opposite-pinning problem where people graffiti the history of rooms by injecting msgs topologically from 1970...

\n
\n

MLS ought to be able to provide a lower temporal bound for historic graffiti based on the epoch of the key package that was used for the message.

", "time": "2023-11-09T09:57:23Z"}, {"author": "Benjamin Beurdouche", "text": "

Remove from the MLS state first

", "time": "2023-11-09T10:00:19Z"}, {"author": "Jonathan Lennox", "text": "

When EKR said \"yesterday in MIMI\" he meant MLS, right?

", "time": "2023-11-09T10:01:05Z"}, {"author": "Benjamin Beurdouche", "text": "

It is probably better to have the Room be wrong and the user not being in the group anymore than the user being displayed removed but the removed member still being in the MLS group and able to decrypt messages

", "time": "2023-11-09T10:02:32Z"}, {"author": "Britta Hale", "text": "

Yes, this seems like last-in/first out type methodology would apply. I.e. the room state advertises/warns the user before a new member is added (vs after), and keeps the room participation advertised until after a member leaves (vs before).

", "time": "2023-11-09T10:05:04Z"}, {"author": "Simon Friedberger", "text": "

Benjamin Beurdouche said:

\n
\n

It is probably better to have the Room be wrong and the user not being in the group anymore than the user being displayed removed but the removed member still being in the MLS group and able to decrypt messages

\n
\n

Agreed. But, I hope the order of operations will prevent situations where it looks like a user still received a message because he was still in the participant list even if he was removed from the MLS group. (I assume this should be prevented by requiring a commit before new messages.)

", "time": "2023-11-09T10:05:24Z"}, {"author": "Benjamin Beurdouche", "text": "

The MLS protocol knows, but the App has to reflect that

", "time": "2023-11-09T10:06:01Z"}, {"author": "Benjamin Beurdouche", "text": "

(at the protocol level, you always know for which epoch you send/receive and whom is in that group)

", "time": "2023-11-09T10:06:54Z"}, {"author": "Daniel Gillmor", "text": "

it would be useful to have some of these sample workflows described explicitly.

", "time": "2023-11-09T10:07:50Z"}, {"author": "Richard Barnes", "text": "

@Daniel Gillmor there is a basic scenario pretty fully fleshed out in the doc

", "time": "2023-11-09T10:08:17Z"}, {"author": "Richard Barnes", "text": "

i thought that was what we were going to get to in this deck, but maybe that's still to come

", "time": "2023-11-09T10:08:33Z"}, {"author": "Britta Hale", "text": "

One difference here is between the room state in an active sense (as it appears to other members) vs an after-the-fact confirmation assured from MLS. So, basically, in a \"live\" sense, the participants should know who might be receiving the messages, while confirmation of add/remove/other commit ordering can be confirmed after the fact on who actually received messages.

", "time": "2023-11-09T10:08:37Z"}, {"author": "Simon Friedberger", "text": "

Britta Hale said:

\n
\n

One difference here is between the room state in an active sense (as it appears to other members) vs an after-the-fact confirmation assured from MLS. So, basically, in a \"live\" sense, the participants should know who might be receiving the messages, while confirmation of add/remove/other commit ordering can be confirmed after the fact on who actually received messages.

\n
\n

Yes, the UI would have to update after the fact. Some guidance would probably be good.

", "time": "2023-11-09T10:09:12Z"}, {"author": "Rohan Mahy", "text": "

Matthew Hodgson said:

\n
\n

well, yes. hash of the cipher text obviously.

\n
\n

Is this a layer violation?

", "time": "2023-11-09T10:10:19Z"}, {"author": "Simon Friedberger", "text": "

Richard Barnes said:

\n
\n

Daniel Gillmor there is a basic scenario pretty fully fleshed out in the doc

\n
\n

https://www.ietf.org/archive/id/draft-ralston-mimi-protocol-01.html#name-example-protocol-flow

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

User add/remove has to be a well-bracketing i.e. add to auth, add client, remove client, remove from policy

", "time": "2023-11-09T10:11:10Z"}, {"author": "Raphael Robert", "text": "

Rohan Mahy said:

\n
\n

Matthew Hodgson said:

\n
\n

well, yes. hash of the cipher text obviously.

\n
\n

Is this a layer violation?

\n
\n

It might be without a key committing scheme

", "time": "2023-11-09T10:11:12Z"}, {"author": "Raphael Robert", "text": "

(or maybe not, be should really discuss key commitment)

", "time": "2023-11-09T10:11:56Z"}, {"author": "Daniel Gillmor", "text": "

@Simon Friedberger thanks for the pointer -- those examples don't show server-initiated banning. that's the scenario i'm getting hung up on. @Rohan Mahy's observation about an external submission is useful here.

", "time": "2023-11-09T10:12:27Z"}, {"author": "Richard Barnes", "text": "

Hashing ciphertext does not seem like a layering violation. Ciphertext is exposed to the messaging layer.

", "time": "2023-11-09T10:12:36Z"}, {"author": "Rohan Mahy", "text": "

Richard Barnes said:

\n
\n

Seems like causal ordering + hub-provided timestamp could be best of both worlds

\n
\n

provided by the Hub to the clients how? The clients don't participate in MIMI transport....

", "time": "2023-11-09T10:13:40Z"}, {"author": "Richard Barnes", "text": "

The major job of servers is to pass on information to clients @Rohan Mahy

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

Application events vs handshake events?

", "time": "2023-11-09T10:18:18Z"}, {"author": "Jonathan Hoyland", "text": "

And then alerts, because you always have to have something that doesn't fit the pattern

", "time": "2023-11-09T10:18:42Z"}, {"author": "Rohan Mahy", "text": "

Richard Barnes said:

\n
\n

The major job of servers is to pass on information to clients Rohan Mahy

\n
\n

but we can't tell the providers how to modify their proprietary protocols

", "time": "2023-11-09T10:19:11Z"}, {"author": "Rohan Mahy", "text": "

quoth the Raven \"[ever] more\"

", "time": "2023-11-09T10:19:25Z"}, {"author": "Jonathan Lennox", "text": "

It seems like the only ordering that'll be ambiguous is the relative order of messages from local users on a server vs. messages from remote users received from the hub? Because there'll be a total order inherent in the order the hub sends the messages.

", "time": "2023-11-09T10:25:22Z"}, {"author": "Benjamin Beurdouche", "text": "

Jonathan Hoyland said:

\n
\n

And then alerts, because you always have to have something that doesn't fit the pattern

\n
\n

Interestingly, there are no alerts in MLS

", "time": "2023-11-09T10:25:26Z"}, {"author": "Jonathan Lennox", "text": "

I assume submitted messages friom local users don't round-trip via the hub? If they did there would be a complete total order.

", "time": "2023-11-09T10:26:05Z"}, {"author": "Rohan Mahy", "text": "

@Benjamin Beurdouche
\nyou mentioned AppAck to have an MLS-layer notion of which messages haven't been delivered.

\n

The content format document has read receipts and delivery receipts. Is there a property we get from AppAck that we don't get from delivery receipts, or vice versa?

", "time": "2023-11-09T10:27:09Z"}, {"author": "Rohan Mahy", "text": "

Jonathan Lennox said:

\n
\n

I assume submitted messages friom local users don't round-trip via the hub? If they did there would be a complete total order.

\n
\n

that's an open question, especially for Commits. I would guess that some response from the Hub that your message was queued would be equivalent/similar

", "time": "2023-11-09T10:28:27Z"}, {"author": "Jonathan Lennox", "text": "

In which case it seems like there's a total order from the hub just implicit in the protocol. (It doesn't inherently enforce the causal order, but that could be checked by clients.)

", "time": "2023-11-09T10:29:57Z"}, {"author": "Benjamin Beurdouche", "text": "

Rohan Mahy said:

\n
\n

Benjamin Beurdouche
\nyou mentioned AppAck to have an MLS-layer notion of which messages haven't been delivered.

\n

The content format document has read receipts and delivery receipts. Is there a property we get from AppAck that we don't get from delivery receipts, or vice versa?

\n
\n

As long as we don't miss trailing messages in application chains that get silently dropped for some reason, I don't particularly care about the technical means : ) AppAck is one way for other protocols that don't want to define their own.

", "time": "2023-11-09T10:30:24Z"}, {"author": "Daniel Gillmor", "text": "

@Benjamin Beurdouche can you point me to details of \"AppAck\"? is this a specific implementation or mechanism, or is it a hand-wavy term for application acknowledgement?

", "time": "2023-11-09T10:31:38Z"}, {"author": "Tim Geoghegan", "text": "

Thanks everyone!

", "time": "2023-11-09T10:32:00Z"}]