Markdown Version | Session Recording

Session Date/Time: 29 Jan 2025 17:00

MIMI

Summary

The MIMI working group held a virtual interim to discuss the new draft-may-mimi-app-components document, which proposes a detailed framework for room metadata, participant lists, pre-authorized users, and role-based capabilities. A significant portion of the meeting was dedicated to a mailing list discussion contrasting Rowan May's flexible single-role-per-participant approach with Timo's proposal for multiple roles per user structured with a fixed hierarchy and custom "add-on" roles. Key concerns included the complexity of role management for both implementers and administrators, interoperability challenges, and how different approaches handle specific authorization scenarios like multi-organizational rooms and banning.

Key Discussion Points

• draft-may-mimi-app-components Presentation: Rowan May presented the draft, outlining four main components:
  • Room Metadata: Basic information like name, description, and subject.
  • Participant List: A list of users, each associated with a single role.
  • Pre-authorized Users: Rules based on identity claims (e.g., company, department) to automatically grant roles upon joining, crucial for enterprise environments.
  • Role Definitions: A list of capabilities assigned to each role, along with constraints on minimum/maximum participants.
• Detailed Capabilities: The draft defines granular capabilities across several categories:
  • Membership Management: Capabilities for adding/removing participants and clients, with an "Authorized Role Changes" matrix to control which roles can assign or modify other roles.
  • Policy Enforcers: External senders can be assigned specific roles with fine-grained permissions (e.g., delete clients but not add them), leveraging max_active_participants constraints to prevent them from becoming MLS group members.
  • MIMI Content: Permissions related to sending/receiving messages, reactions, edits, and deletions.
  • Media: Capabilities for handling file attachments, images, and real-time audio/video.
  • Disruptive Actions: High-privilege capabilities such as changing room policy, reinitializing the MLS group, or destroying the room.
• Role System Design: Flexible vs. Hierarchical:
  • Rowan's Approach (Draft): Emphasizes a single role per participant list entry, with a matrix defining valid role transitions. This aims to provide the flexibility needed to map diverse existing fixed-role systems from different providers and support complex scenarios like multi-enterprise rooms.
  • Timo's Alternative (Mailing List): Proposes multiple roles per user, where a user's total capabilities are the union of all assigned roles. This system includes a strict linear hierarchy of predefined roles (e.g., admin > moderator) and allows "add-on" custom roles for specific features (e.g., "programmer" role). The goal is to simplify UI design and make role power more intuitive.
• Discussion on Role System Nuances:
  • Multi-organizational Rooms: A key challenge for Timo's linear hierarchy, which struggles to model branched administrative permissions (e.g., an admin from Company B can only manage Company B's members, but a global admin can manage all).
  • Banning: Proposed by Timo as a separate mechanism outside the role system (a separate ban list), allowing for timed bans and logging ban reasons. Rowan's approach could model banning as a specific role.
  • "Kick" Definition: Discussion highlighted ambiguity in what "kick" means – removing clients only (user remains in participant list with original role) versus completely removing the participant from the room.
  • Extensibility: Eric Berger (via Tim) raised concerns about handling future permissions. Rowan suggested defining "capability packages" (using MLS extensions) with some being essential for all clients and others optional, requiring clients to declare support or bubble up errors if a required package is unrecognized.
• Client Management and Virtual Clients: The role of individual clients per user was discussed, with enterprise use cases for limiting guest access to a single client. Raphael mentioned ongoing MLS discussions around "virtual clients" which abstract real clients behind a single logical client per user, potentially simplifying group management.
• Implementation Concerns: Raphael and Rick highlighted the need for implementation experience to validate the practicality and interoperability of any chosen role management system, cautioning against over-engineering features that may not see widespread use.

Decisions and Action Items

• ACTION: Define consequences for violations of minimum/maximum participant constraints (e.g., room destruction policy) in the room-policy document.
• ACTION: Rowan May to create an issue on the room-policy document to define the precise behavior of "kick" (Issue #3: "two versions of kick" was subsequently created by Rowan).
• ACTION: Tim to relay Eric Berger's question on extensibility and Rowan's proposed solution (capability packages) in the mailing list.
• ACTION: Rowan May and Timo to develop concrete scenarios for authorization requirements (e.g., multi-enterprise management, specific custom role interactions) and describe how their respective proposed solutions would handle these, including an analysis of potential attack vectors.

Next Steps

• The chairs will issue an adoption call for the discovery requirements document on the mailing list shortly.
• The next MIMI virtual interim meeting is scheduled for two weeks from today.