Re: End-to-end Encrypted Messaging in ActivityPub

On Sat, May 20, 2023 at 11:18 AM Bob Wyman <> wrote:

> Given that this problem is so hard, I'd like to suggest that an effort be
> made not only to define useful, secure methods, but also to ensure that
> there is a good and easily accessible explanation for why the methods were
> chosen over alternatives...In essence, one should explain "why" before
> documenting the specifics of "what" or "how."

Sounds like architectural decision records!

On Fri, May 19, 2023 at 11:31 PM Benjamin Goering <> wrote:
>> 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:
>> f
>> On May 19, 2023, at 19:21, a <> 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"
>> 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.)


Received on Saturday, 20 May 2023 19:29:01 UTC