Mimi IETF124 session

MIMI Identifiers (Konrad Kohbrok, 10+5)

By Rafael Robert?
This is not a new document, but related to the identity draft.
There are identifiers for connection establishment.
And there are administrative identifiers
MLS needs credentials
There is no link between the 2 different identifiers
The last identifier is Display name
The proposal is to define the 3 identifiers

Jon Peterson : do we really want to decouple the display name and the
real identity (like banks)
Vittorio Bertola: There must be unique identifier to be able to move
between providers.
Alissa Cooper: What is there for the protocol to do with this?
Rafeal: How does it all work together?
Alissa: This seems a product decission

Rohan Mahy: which type of identifier is my discord handle?
Rafeal: it seems to fall under multiple identifiers
Jon Peterson: I'm interested in a world to trust that they talk to the
correct user.
Rafeal: That is fair. You want to make sure you talk to a bank. We do
not want to obfuscate.
Marvin Wissfeld: How can an end user use a display name and a UUID.
Jon Peterson: iMessage use UUID's but they are only internal.
Mark Trip: Most things are mutable in iMessage (?)

mimi-identity (Rohan Mahy, 10+5)

We have not yet talked about credentials. We need to come up with a set
of identities that can be used with MIMI (interoperbility).

Richard Barnes: it seems like a good list to start with
Raphael Robert: Do you want to categoricly ...
Rohan: we want to make sure you can savely prevent impersonation
Raphael: we should include the domain in the identifier
Jon Peterson: Didn't we talk about the identifiers before (in the
discovery document), so what are we going to do here?
Rohan: we have to reintroduce the WG to this level of thinking to go
forward
Tim Geogheagan: What do we want to do with these documents
Raphael: the identifiers should not go for adoption, but could be
included in the identity document.
Tim: more study and implementation/talk to implementors?
Rohan: ...?

mimi-content (Rohan Mahy, 15+5)

Rohan: can we adopt mimi-message-status, because it was in the
mimi-content document.
Tim: We'll put it on the list for a call for adoption (after a show of
hands who read it)

On the Message ID calculation #61
Raphael: it is a hash function, so it doesn't matter that it would
contain a null separator
I have not a strong opinion here.
Tim: prefix with length
Jim Reid: use a explicit length field, not a |, because the URI could
change to allow that.
Rohan: it will be explicit length (based on show of hands)

mimi-protocol (Rohan Mahy, 15+5)

We would love to test this with someone else.
On the open issues:
Raphael: why is there an empty issue in the list on github?
Rohan: it is about sharing the state, that issues is a placeholder to
share between members (not the hub).
Raphael: it is essential/important to be able to decrypt messages in a
group.
Rohan: it is important, not essential.

We are close with 2 implementation of mimi-content.
Raphael: what is the second implementation besides ours?
Rohan: mine, but not willing to share it yet.

mimi-room-policy (Rohan Mahy, 15+5)

Updates on the draft, see presentation

Deletion accounting (Eric Burger, 10)

Malicious Hubs by Srinidhi Amuri
draft-burger-mimi-audit-layer-00

We would like to have any insights on this proposal

Raphael: How exchange things between clients?
Srinidhi: each client will create a tree and exchange that.
Raphael: it would be helpful to have an overview of the protocol with
examples.
Alissa: We need more people to read the draft.
Tim: Do we want this to be part of mimi-protocol?
Rohan: What is the impact when the franking is done?
Srinidhi: Franking doesn't solve the problem.
Rohan: I'm hesitant to add new things to mimi protocol.
Srinidhi: are tombstone a good idea?
Tim: thumbs up from Rohan

Notes taken by Stefan Ubbink