Re: End-to-end Encrypted Messaging in ActivityPub

On Sat, May 20, 2023 at 11:18 AM Bob Wyman <bob@wyman.us> 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! https://adr.github.io/



On Fri, May 19, 2023 at 11:31 PM Benjamin Goering <ben@bengo.co> 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:
>>
>> 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.)
>>
>>

-- 
https://snarfed.org/