Thanks for starting this thread, and adding the E2EE Task Force! <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f49c.png?v=b232808582d" title="" />

UPSI is fairly new technology, just a few years old. I haven't used it myself, but it could be part of the solution for the blocking problem you refer to.

This was all true as of around 2022, when I was looking into this issue of blocking and private posts, while trying to keep blocklists private.

If I understand it correctly, I like your MLSGroup solution.

I guess I should have posted this to the GitHub thread....

2/2

I think a good mitigation for metadata exposure is to more-or-less follow option C from: https://github.com/swicg/activitypub-e2ee/issues/83, with the addition that all MLS protocol messages + user messages should be encrypted blobs wrapped in an activity, possibly a Note or the Create wrapping a PrivateMessage/Note. I'm in favor of using a core, and/or a widely implemented vocabulary type to minimize code changes needed server-side.

The encrypted blob would go in the activity's content field (like in Option B), and the activity would be signed using one of the Group actor's keys so it could be posted to the Outbox. This protects leaking membership information, since the server would just see a signed activity using one of the Group actor's keys. To further obfuscate member identity, the MLS epoch key could be used for this purpose, and added to the list of the Group actor's keys. Details about trade-offs of using the epoch key probably need to be discussed, as it would leak key rotation information, so a separate long-term key shared by all participants may be better.

For message delivery, all participants would used authorized fetch (using the long-term key) to retrieve all Outbox messages. Each client will attempt to decrypt every message, and only be able to successfully decrypt messages intended for them. This would obfuscate the identity of receiver participant(s).

Network-level metadata is still a concern, but would be better handled by the respective layer in the OSI stack.

At the application level, using the above scheme would sufficiently obscure metadata from the host server, and outside observers. It essentially is a combination of Options B and C, except that the hosting server has no information about the participant list (that is all contained in MLS ciphertext messages). It has the side-benefit of requiring essentially no server-side changes at all, since all messages would just appear as normal activities.

To avoid total centralization of the server, "fallback" servers could be listed in the bto field like in Option B. Though, this could also be optional, as it leaks at least some participant information, e.g. at least one participant has an account in that server list. Fallback servers could also be coordinated in-band using MLS messages, and a new Group actor created in case of a down server, malicious host, etc. However, fallback servers are tangential to the metadata discussion.

One challenge is if Alice posts and Bob replies, and Bob is blocking Charlie, then how does Alice (or Alice's server, e.g. an MLSGroup) know not to forward Bob's reply to Charlie, unless Alice knows that Bob is blocking Charlie? Blocklists are private information. One possible solution is to use Private Set Intersection (PSI) to determine the intersection of Alice's recipients and Bob's blocklist. PSI is slow and typically requires recalculating every time one of the sets changes, but Updateable Private Set Intersection (UPSI) can handle set changes quickly.

1/