Markdown Version | Recording 1 | Recording 2

Session Date/Time: 19 Mar 2024 07:30

# mimi

## Summary

This session focused on discovery mechanisms for MIMI, particularly concerning service-independent identifiers (SIIs) and message service providers (MSPs). The discussion covered consensus points from previous meetings, explored the nature of SIIs and SSIs, and debated the architecture of discovery providers (DPs), including the implications of a logical singleton versus a sharded system.  There was also discussion regarding what identifier formats are appropriate for MIMI to support.

## Key Discussion Points

*   **Discovery Problem Definition:** Agreed upon the need for authentication and distribution of SII-to-SSI mappings. Emphasis on *provider* discovery.
*   **SII vs. SSI:**  Debated whether discovery services should return reachability information for MSPs or globally routable SSIs (URLs).  The potential need for both was raised.  Terms SII and SSI are difficult to distinguish and should be re-evaluated.
*   **User Journey vs. Architecture:** Concern was raised that the requirements are being defined by an architecture. A user journey should be outlined before defining technical requirements.
*   **MIMI Protocol & Identifiers:**  The discussion focused on the MIMI protocol draft and that the output of a discovery service should be something `@ provider`.
*   **Key Discovery:** Discussed if key information for secure association should be part of the discovery process.  Arguments made for and against, with concerns raised about differing lifetimes of key material versus SII mappings. Focus on SII integrity at discovery. Signing keys could be part of the discovery process.
*   **Scope of Identifiers:**  Telephone numbers are the most pressing case. Discussed the importance and scope of email addresses as SIIs, along with related challenges and geopolitical considerations. Need for a system that isn't native to telephone numbers or email.
*   **DP Architecture (Logical Singleton vs. Sharded):**  Extensive discussion on whether DPs should be a logical singleton (aggregating all mappings) or a sharded system due to geopolitical or policy reasons. A singleton would need to expose all possible routes, an ideal but likely impossible situation. The relationship with existing message transport architectures like phone number portability was discussed.

## Decisions and Action Items

*   **Action Item:** Re-evaluate and rename SII and SSI to avoid confusion in the requirements document.
*   **Decision:** To focus on the "B" case rather than the "A" case on slide two for what can be returned by the service.
*   **Action Item:** Keep an eye on the mailing list to schedule the next interim at which we'll pursue a discovery discussion

## Next Steps

*   Schedule an interim session to continue the discovery discussion.
*   Further explore the relationship between MIMI identity and discovery.
*   Continue evaluating use cases, architectural constraints, and geopolitical considerations related to DP architecture.

Session Date/Time: 20 Mar 2024 23:30

mimi

Summary

The Mimi working group held its second session of the week, focusing on the content format draft and architecture/protocol documents. Key discussions revolved around message IDs, attachment security, binary encoding formats (CBOR vs TLS Presentation Language), the inclusion of a subject header, and the overall architecture of the Mimi protocol. The group reached rough consensus to adopt the architecture and protocol documents.

Key Discussion Points

Decisions and Action Items

Next Steps