Re: End-to-end Encrypted Messaging in ActivityPub

> 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.)