[MLS] Re: Comments on Leaf Operation Intents

[Rohan Mahy <[e-mail]>]

Hi Konrad,
OK,I missed in the intro that you were trying to solve the problem of not
having state even when trying to remove itself it doesn't have current
state. The last sentence of paragraph 2 in the intro is dominated by the
resend phrase. Again the third paragraph talks about resending (not just
sending the first time), then finally mentions "might be offline at the
time".  I think these are two separable problems. The solution to having to
keep state for resends is to fix external commit handling of proposals. The
solution to "I want to delete state NOW NOW NOW even though I am offline",
is a motivation for intents.

In the MIMI model, a removed participant also needs to propose removing
itself from the participant list. How would this be handled?
Thanks,
-rohan

On Mon, Nov 3, 2025 at 5:06 AM Konrad Kohbrok <[e-mail]>
wrote:

> Glad to hear that you found it easy to understand. Although maybe your
> question implies that it wasn’t so easy to understand? I’m not sure.
>
> I’m not sure I understand the problem about retention of keying material.
> Sure, sending the intent doesn’t ensure that the client is immediately
> removed, but that is transparent to everyone in the group. Yes, the idea is
> that after sending the intent, someone else at some point creates a
> proposal and commits it. That could be an external sender like the DS. And
> I am totally in favour of external committers getting all pending
> proposals. Maybe you could give an example scenario where the problem
> occurs?
>
> The point of the intent is that it can be created offline, i.e. even if
> the sender doesn’t have an up-to-date group state. The main feature is that
> it acts as a SelfRemove proposal that is decoupled from the current group
> state, but instead is bound to the state of the leaf. As such, it’s
> orthogonal to the handling of proposals by external joiners.
>
> Konrad
>
> > On 3. Nov 2025, at 10:23, Rohan Mahy <[e-mail]> wrote:
> >
> > Hi,
> > First, this document was easy to understand.
> >
> > While addressing the problem of clients having to manage state for their
> own removal, this seems to just sweeps under the rug the problem that under
> some circumstances†, a client could have valid keying information for
> several future epochs after another of its clients sent an intent for all
> the user's clients to leave. Why not just make external committers get all
> pending proposals and be done with it? That would assure deletion during
> the next epoch transition. Is there a benefit I am overlooking?
> >
> > Next, I think we are overusing WireFormats. I think if we implement
> intents, we really want a new content type that reuses PrivateMessage,
> SemiPrivateMessage, or PublicMessage, but has an `intents` ContentType
> which shares the handshake ratchet with commit and proposal.
> >
> > Thanks,
> > -rohan
> >
> > †in the face of a bunch of external commits coming quickly (ex: a burst
> of join activity)
> > _______________________________________________
> > MLS mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>