# MLS Interim 2024-12-19   {#mls-interim-2024-12-19}

## Cleaning up MLS / Application interface - Richard Barnes   {#cleaning-up-mls--application-interface---richard-barnes}

*   "MLS Extension" = "something that changes MLS behavior"
*   A lot of the extensions we've discussed are just application logic
*   App API Document: Expose safe APIs for application logic
*   Introduces application "components" -- idea that single application
    may have multiple different integration points
*   ApplicationData proposal type: opaque data gets included in MLS
    transcript, but doesn't affect MLS at all
*   ApplicationDataDictionary: Single new extension that can go into
    various extension points (GroupContext, GroupInfo, etc) containing
    application data
*   ApplicationDataUpdate: Proposal that supports sending patches of
    application data to GroupContext.application\_data; helps when
    GroupContext.application\_data is large
*   Should AppDataUpdate diff or replace?
    *   Rohan: In either case, you need an application callback to
        verify end-state application data. So there's not a lot of gain
        to not allowing diffs. Should be up to the application whether
        diff or whole replacement.

*   Do we even need GCEDiff? Is there any place where the data is large
    enough to justify diffs?
    *   Rohan: As an example: external senders, which could contain
        multiple credentials. I could see why someone would want that,
        but I don't see why it's necessary to have diff semantics.

Is this the right framework?

*   Raphael: Agree that things that don't change MLS behavior aren't
    really extensions. There's very little in mls-extensions that
    actually changes MLS behavior. Should we just rename the document?
    Someone can make a proposal
*   Raphael: I'm not sure we totally agree on what does/doesn't change
    MLS behavior. Also would like to discuss with Konrad before we throw
    a lot of the extensions document away.
*   Britta: Like general direction. In terms of reducing complexity,
    terminology still needs to be improved.
*   Rohan: Also in favor of this. My focus is on having something that
    replaces AppSync.
*   Britta: In terms of feedback on app data containers, it's not clear
    how metadata will be handled.
*   Richard: Next step would be for authors to flush out more
    comprehensive proposal and present in January maybe.