consider relative merits of "ActivityPub over MLS" versus "MLS over ActivityPub"

[trwnh]

In looking at related issues:

• Multiple clients #5
• Encrypted metadata #25
• Define what a direct message is #30
• Most similar to, and perhaps a broader approach to Consider using MIMI content instead of stripped-down AS2 #36
• Standard way to Filter E2EE messages in Inbox #44

It strikes me that it's in some ways quite backwards to want to do "MLS over ActivityPub" when it might actually make more sense to do "ActivityPub over MLS". In particular, the interplay between #25 #30 and #44 got me on this train of thought:

• ActivityPub is (or should be) more about publishing activities (using the content model and processing model of ActivityStreams) than serving as a delivery service (in the MLS way, but also in the way that the as:outbox delivery algorithm ostensibly triggers Linked Data Notifications to be sent to the ldp:inbox of each addressee). At least, in the sense that one publishes to an activity stream, it makes more sense to have that activity stream be bound to the context of an MLS group than to have an MLS group's messages represented in an inefficient and leaky way. The more detailed your ActivityStreams document, the more private (meta)data you are leaking from within the encrypted payload.
• Given that MLS is message layer security, it should be securing the messages instead of being wrapped in insecure messages.

I was also reminded of some other prior art that seems relevant here:

• MIMI using HTTPS and MLS: https://datatracker.ietf.org/doc/draft-ietf-mimi-protocol/
• Germ Network extending that with their use of "Addresses", which are basically a form of rendezvous service: https://www.germnetwork.com/blog/autonomous-communicator-ac-protocol (the only metadata visible to the service is the endpoint you POSTed to, which is basically a hash of the epoch -- so anyone in the MLS group can find the address, but the rendezvous service doesn't know anything about the MLS group from the address except perhaps which IP addresses are hitting which addresses)

I imagine the motivation for the current architecture is out of a desire to make this more approachable or palatable to ActivityPub outbox and inbox implementers a la #28, but I think the layering here makes it harder than it otherwise would be.

[mallory]

I believe that wherever we state "MLS over ActivityPub" that it was a typo and it should be "MLS in ActivityPub". You rightly point out that "over" is not the correct preposition here, that there is much more interplay. In the GSMA, the specification of "MLS in RCS" is a good analogy.

[trwnh]

It's less that the preposition is incorrect, and more that the layering itself should be considered:

• "MLS over/in ActivityPub", understood to be using ActivityPub as a transport for MLS messages
• "ActivityPub over/in MLS", understood to be using MLS as a transport for ActivityPub activities

From my understanding, the current state of the work is to pursue the former, while I am wondering if it makes more sense to do the latter.

It is possible to do "ActivityPub over/in MLS over/in ActivityPub", which seems to be the assumption being made right now, although #36 proposes a sort of "MIMI over/in MLS over/in ActivityPub" if I understand correctly.

The concern is about that last bit, the "...over/in ActivityPub", which leaks too much metadata (#25) and feels like a poor use of ActivityPub (#30). ActivityPub is ostensibly for publishing activities, and it's hard to say that I would want my MLS messages "published" at all, even if encrypted. It's certainly possible to do so, at least in the sense of minting/assigning a URI for the MLS message (even if the payload is not made public), but I am unsure if there is value in doing so (as a message might typically have a mid: or mimi: URI instead of an https: one).

[mayel]

I'd say the current approach (as written in the spec) is actually doing ActivityStreams in MLS over ActivityPub, since we're encrypting ActivityStreams JSON objects in the MLS messages (instead of just a bare string for example) and using ActivityPub merely for addressing and distribution...

[mallory]

I think that it's more layered than that. AP is sending a MLS-ciphertext of AS. It's like a turduckin, so MLS "in" AP(/AS) seems to best represent that strange metaphor.

[trwnh]

@mayel wrote:

we're encrypting ActivityStreams JSON objects in the MLS messages (instead of just a bare string for example) and using ActivityPub merely for addressing and distribution...

"using ActivityPub merely for addressing and distribution" is the concern here. encrypting AS2 within an MLS message is fine. passing MLS binary cipher in an HTTP POST request can be fine -- this is what the mimi-protocol draft assumes with /.well-known/mimi-protocol-directory, if i understand it correctly. (you'd still want to consider that IP addresses or HTTP headers may give away too much information, and maybe consider something like a rendezvous service.) but encoding MLS into a string and publishing it as an activity gives me pause:

• does the MLS payload need an HTTP URI, and if so, why?
• does the MLS payload persist in the outbox? can authorized requesters see MLS payloads in my outbox? doesn't the authorization on the request leak information?
• how does the MLS payload get delivered without leaking participants in the MLS group? you really shouldn't be directly addressing the participants...
• does the MLS payload persist in the inbox? can authorized requesters see MLS payloads in the group's inbox or your own inbox? doesn't the authorization on the request leak information?

this is what i mean when i say ActivityPub is a poor fit for being an MLS delivery service. there's less of a problem with having an actor document being the MLS authentication service (or a WebID, or a CID, or whatever) (although there are still some concerns there), but for the MLS delivery service you really don't want to leak this kind of metadata, because it defeats the whole purpose of MLS if you can infer the group's members.

[evanp]

I think we're working on end-to-end encrypted messaging in ActivityPub. Given that core user story #1 and #2 , I think we're pursuing the right path.

[trwnh]

"As an ActivityPub user" doesn't necessarily mean "using the ActivityPub outbox and inbox", though, does it? I think there are better ways to implement MLS AS and DS that don't leak metadata and result in payloads being "published" as activities. If you're already okay with extending the actor document to add things like key packages, then is there a reason to not also use more privacy-preserving mechanisms for delivery?

[mayel]

What do you mean by "published"? As the activities certainly don't have to be public, but only addressed to recipients.

[trwnh]

@mayel "published" as in "assigned an identifier and persisted in the outbox and inbox, where they can be read by anyone with access to the storage backend". which is what ActivityPub nominally does -- it publishes activities. i'm not talking about as:Public addressing, which makes those activities visible without authentication.