Re: [Mimi] draft-mahy-mimi-content comment - message immutability

[Jonathan Rosenberg <[e-mail]>]

E2E encryption is baked into our charter (see
https://datatracker.ietf.org/doc/charter-ietf-mimi/). We are specifically
trying to solve for federation between providers of e2e encrypted
persistent chat systems.

Thx,
Jonathan R.

On Fri, Mar 31, 2023 at 2:39 PM Seyyed Soroosh Hosseinalipour <
[e-mail]> wrote:

> ITNOA
>
>
>
> Why mandate e2e encrypted? I think it can be optional from standard view,
> and if implementor use non e2e mode, it can gain many options and
> flexibility, that resolve many problems, by design.
>
>
>
> Thanks
>
>
>
> *From:* Mimi <[e-mail]> *On Behalf Of * Jonathan Rosenberg
> *Sent:* Friday, March 31, 2023 10:35 PM
> *To:* Martin J. Dürst <[e-mail]>
> *Cc:* Matthew Wild <[e-mail]>; [e-mail]
> *Subject:* Re: [Mimi] draft-mahy-mimi-content comment - message
> immutability
>
>
>
> With MIMI, messages are e2e encrypted. Thus, the typical "columns" -
> information buried within the mimi content, is not known to the provider
> and cannot be deleted individually.
>
>
>
> Thx,
>
> Jonathan R.
>
>
>
> On Fri, Mar 31, 2023 at 5:38 AM Martin J. Dürst <[e-mail]>
> wrote:
>
> We definitely should think and work hard to make sure GDPR needs are
> covered. On the other hand, if we want to address business needs too,
> there are also requirements for retention, in particular in
> banking/securities. So what XMPP does seems to make sense.
>
> Regards,   Martin.
>
> On 2023-03-28 17:27, Matthew Wild wrote:
> > On Mon, 27 Mar 2023 at 04:59, Jonathan Rosenberg <[e-mail]>
> wrote:
> >>
> >> Another high level comment I think warrants discussion on its own -
> whether or not MIMI messages are immutable.
> >>
> >> For handling things like message deletion, a messaging system has two
> choices on how to implement it. First is - to allow a previously sent
> message to be modified. So, if you think about the persistent group chat as
> a database for messages, we're quite literally updating the row which
> contained this message. The other choice is, that you can never modify a
> previous message itself. Rather, you send a new message, which has the
> semantic of being an edit (or deletion) of a prior message. In this model,
> the deletion or edit is the insertion of a new row, with a foreign key
> referencing the message being deleted or edited.
> >
> > For the record, in XMPP we do a combination of these. Edits/deletions
> > are, as you say, follow-up "replacement" messages (with their own ID
> > and a reference to the ID of the replaced message). For various
> > reasons, including not messing up sync, we always (sticking with your
> > DB analogy) keep that "row" in the database, however in certain cases
> > servers do clear most of the columns. That allows us to scrub
> > problematic content (e.g. because the service does not want to host
> > it, or because a GDPR subject requested removal of the content).
> >
> > Clients later synchronizing that chat can see that a message occurred,
> > but not the original contents.
> >
> > Regards,
> > Matthew
>
>