[MLS] Re: Comments on Leaf Operation Intents

[Konrad Kohbrok <[e-mail]>]

Good question, I had not thought that far just yet. That would either also need to be an intent or the Hub would have to create the necessary proposal when proposing the intent.

> On 3. Nov 2025, at 11:33, Rohan Mahy <[e-mail]> wrote:
> 
> 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]
> 
> _______________________________________________
> MLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]