Session Date/Time: 19 Jun 2024 16:00

MIMI

Summary

This MIMI interim meeting primarily focused on updates to the Content Format draft and a substantial discussion on metadata privacy approaches. Rowan presented the 04 version of the Content Format draft, highlighting the adoption of a concrete CBOR syntax and schema. A poll indicated significant interest in implementing the draft. The bulk of the meeting was dedicated to exploring four different options for metadata privacy in handshake messages, ranging from no protection to fully encrypted messages that hide information from the Hub. The discussion centered on the trade-offs between privacy, functional capabilities like policy enforcement and abuse mitigation, and deployment feasibility, particularly in enterprise and consumer contexts. Consensus was not reached on a single metadata privacy approach, with further documentation and discussion planned.

Key Discussion Points

MIMI Content Format Draft 04 Updates:
- Rowan presented the 04 version, which now features concrete CBOR syntax with a CDDL schema. All examples are CBOR instance documents and validate against the schema, including complex multi-part body types.
- A hash of the external content array was added.
- A show of hands indicated significant interest in implementing the draft, with at least four and potentially more individuals or groups planning implementations.
- It was suggested to seek an Apps Area review for CBOR, but Rowan preferred to wait for further comments from the CBOR mailing list for two weeks before deciding.
- Open Issues:
  - Implied values (message ID, timestamp): These values are derived from MLS messages rather than being conveyed directly in the content format. The extensive use of message ID by the content format means these are more relevant to the API layer.
  - Subject field: Proposed to be closed as it can be handled via the extensions map, with the original opener agreeing in principle.
  - Matrix extensible events: This issue no longer appears particularly relevant, and its opener agreed to close it for now, with the option to re-open or pursue via the mailing list if needed.
- Message ID derivation and history sharing: A concern was raised regarding the current implicit message ID derivation (from ciphertext hash) in the MIMI protocol, specifically for scenarios involving history sharing where the ciphertext might not be available, or for abuse prevention when verifying message IDs. It was noted that this could impact message franking. While no change was proposed, it was flagged as a potential future issue.
Metadata Privacy Discussion (Handshake Messages):
- Conrad's summary of metadata privacy approaches was presented, outlining four main options:
  1. No protection: Hub and followers see real user identities.
  2. Pseudonym-based protection: Hub and followers see pseudonyms; Hub can enforce policy based on these pseudonyms. (This is the approach currently in the draft).
  3. Encrypted handshake messages (Hub-visible copy): Handshake messages are encrypted for members, with a separate copy encrypted to the Hub. Hub sees provider client counts but followers do not. Hub can still enforce policy using pseudonyms.
  4. Members send private messages only: Hub receives no information from commits/handshakes and has no ability to enforce policy directly. (Brendan's proposed approach).
- Discussion highlighted the trade-offs:
  - Options 2, 3, and 4 (using pseudonyms or EHC) make traditional reputation-based abuse mitigation more difficult compared to option 1, as the Hub cannot directly link a real user to a pseudonym across groups. However, alternative abuse mitigation strategies involving SLAs with follower servers and privacy-preserving mechanisms (e.g., Privacy Pass) were suggested as possible solutions.
  - Rowan expressed strong concerns about option 4 ("members send private messages only"), arguing it would necessitate a complete rework of many MIMI mechanisms and would be unlikely to be deployed in enterprise or consumer networks due to "know your customer" (KYC) and abuse mitigation legal requirements. He suggested options 2 or 3 are more pragmatic for real-world deployment.
  - The ability to ban a user or pseudonym from a group, and how that interacts with a follower server's responsibility to manage all pseudonyms associated with a real user, was a key point of discussion. This relies on trust and potentially SLAs between Hub and follower servers.
- There was an agreement that a clear articulation of how common administrative actions (e.g., ban, kick, block, report) would function under metadata-protected scenarios is crucial for evaluating and comparing the different privacy approaches.

Decisions and Action Items

Decisions:
- The "Subject field" issue for the Content Format draft will be closed after the meeting.
- The "Matrix extensible events" issue for the Content Format draft will be closed for now.
Action Items:
- Conrad: Document how policy enforcement actions (e.g., ban, kick, block, report) can be implemented under pseudonym-based metadata protection approaches, considering various assumptions (e.g., follower provider knowledge of group membership or pseudonym mappings, "break glass" scenarios). This should also tease out differences between enterprise and consumer enforcement models.
- Brendan: Provide a more detailed Internet-Draft (ID) describing the "encrypted handshake messages" approach (option 4) to allow for a comprehensive evaluation of its implications for the MIMI architecture and functionality.

Next Steps

Continue the discussion on metadata privacy, particularly after Brendan's detailed ID for the encrypted handshake messages approach becomes available.
The next interim meeting is scheduled for July 3rd, but attendance may be light, and its agenda will depend on the availability of new drafts (e.g., Brendan's ID).
Another interim is scheduled for July 17th, the week before IETF. Participants are encouraged to voice strong feelings about the scheduling of these upcoming interims.