Limiting Group Membership Metadata Exposure

Expanding on the end of our discussion today: 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.