Skip to main content


Wondering out loud: given we don’t have E2E encryption with DMs, what are the steps needed to get there?

Another layer on top of things that uses user identities on instances to connect things up?

An extension to the ActivityPub protocol itself?

in reply to Dave ✨

The basics are pretty easy. Activity Streams 2.0 supports custom MIME types on content, so using a MIME type like `application/encrypted` (OpenPGP) or `application/pkcs7-mime` (S/MIME) would just pass through the ActivityPub system.

For users experienced with exchanging keys out of band, this is probably enough to get started.

in reply to Evan Prodromou

so, let's talk about the hard parts.

1. To be E2E, encryption has to be implemented in the client software. That software has to be able to access keys, use them, and keep them safe. This includes Web clients and mobile clients.
2. To be worth all this trouble, there should really only be one way to do it.
3. Most people are bad at managing keys. So, key management should be automatic.
4. Many people use multiple clients, so there must be a way to share keys between them.

in reply to Evan Prodromou

I think there's a lot of prior art on these last parts that is both secure and usable. Signal is a good example.
in reply to Evan Prodromou

there are some very smart people working on this. I look forward to seeing this develop over time.
in reply to Evan Prodromou

@evan thank you Evan. This confirms a few things for me!

So for my own ideas, I’ve been thinking specifically about enabling video/audio calls.

Looking at it, the ActivityPub spec allows enough metadata etc that the handshaking part for webrtc could be run through ActivityPub and DMs already. Clunky perhaps, but possible!

in reply to Evan Prodromou

@evan I'm not sure Signal is a good example. IME when you use signal from your computer, it has to bounce the messages through your phone, which has to be on and available. It's a terrible user experience.
Unknown parent

silverwizard
Ok, but, out of curiosity, what is stopping your admin from modifying the code to intercept your password?
Unknown parent

silverwizard
Which brings us back to the audacious goal
Unknown parent

silverwizard

Sure, yes, continuous audit of all jS would become necessary - it would be messy and horrible.

This is definitely not an impossible task - just a monumental beyond imagining one.