@thisismissem @mayel I tried to capture the different solutions we discussed on the #ActivityPubE2EE call today. Can you confirm that these are in the right ballpark?
https://github.com/swicg/activitypub-e2ee/issues/77#issuecomment-4382341437
Post
Replies:
6
@evan @mayel I stand by my positions that an E2EE protocol:
a) should not allow a server to know who is in a conversation, so therefore server-level blocks cannot be applied (unless applied client-side)
b) if a conversation is reported to server admins/moderators, doing that report via E2EE really doesn't gain you anything over just TLS. Server will end up with that information in cleartext at some point. But you do want verifiability of the messages & their ordering and the actor IDs involved, probably a new object type to represent a Conversation.
I tried to address your first point here: github.com/swicg/activitypub...
Not sure I understand why you say "server will end up with that information in cleartext at some point" though?
@thisismissem @mayel I think a Collection with the objects in it should work!
@thisismissem @mayel as far as knowing who is in the conversation: that is not a standard other e2ee systems maintain. In particular, for ActivityPub, we need to know where to deliver the PrivateMessage object. There are other metadata included in the packet, like timestamp. There is a section on the topic here:
https://swicg.github.io/activitypub-e2ee/mls.html#metadata-leakage
@thisismissem @mayel so, server-level blocks can be applied. However, they really mess up the cryptographic state of the group. If someone I blocked makes a change to the group that changes its ratchet tree, I won't receive that change, and later messages will be garbled for me.
