Re: End-to-end Encrypted Messaging in ActivityPub

soatak also started writing about this 6 months ago, and I thought it was a great contribution. There is also a repo to contribute to:
https://soatok.blog/2022/11/22/towards-end-to-end-encryption-for-direct-messages-in-the-fediverse/
f
> 
> On May 19, 2023, at 19:21, a <a@trwnh.com> wrote:
> 
> 
> > We need simple PGP-style key exchange for DMs
> 
> we could honestly jump straight to OMEMO-like schemes and have servers generate pre-keys for their actors. i don't think PGP-style is worth going for unless you want to be able to persistently verify authored activities after-the-fact, and don't mind (or perhaps want?) anyone with the key being able to decrypt your messages.
> 
> aside from that: i'm personally not convinced that we "need" such complexity. maybe it would be "nice to have" a way to do stuff like this over activitypub, but i think before encrypted messaging there needs to be a way to do plaintext messaging. until then, people will continue to go out-of-band to a dedicated messaging app.
> 
> my current thoughts/notes on "messaging over activitypub" are as follows:
> 
> - `Create Note` alone can be confused for a "status" or any of the other myriad things a `Note` gets used for. pleroma / litepub at one point in 2019 developed the ChatMessage as a new type and they sent out `Create ChatMessage`; i think this is not exactly the right approach since it makes more sense to have `Message` as an IntransitiveActivity which represents a "message" instead of a "resource". this also eliminates the need for wrapping in a `Create`. such `Message` activities could be transient if desired, or they could be persistent if given an `id`. (alternatively, if `context` was understood, you could have an explicit "messaging context" representing the room or conversation.)
> 
> - the other thing we'd want to heavily look into and think about is metadata encryption. if we just encrypt, sign, attest, verify, etc. the content, then that's surely simpler, but it is also surely far less useful in many cases. otherwise, we could have had `content_sig` or something similar years ago to cryptographically work with the `content` and no other properties. i am reminded somewhat of diaspora*'s approach to this, which was to have a "magic envelope" https://diaspora.github.io/diaspora_federation/federation/magicsig.html that would encode the entirety of the "message" and then sign that encoded string. we could do something similar by having some dedicated Envelope activity type serve as this "envelope" which might contain `summary` and `content` as proposed above by Evan's blog post. i haven't fully considered the exact details, but i think at minimum you would have to leak the `actor` if nothing else. (this is because of the requirement to use activities to avoid the wrap-in-Create behavior. addressing could be hidden by use of bto/bcc instead of to/cc.)