Jump on the GitHub issues. We’d love to talk.

GitHub - swicg/activitypub-e2ee: Coordination of work on end-to-end encryption with ActivityPub

Coordination of work on end-to-end encryption with ActivityPub - swicg/activitypub-e2ee

GitHub (github.com)

And, I’m happy to walk you through how I’m trying to approach it. We have a tight timeline, but more eyes is still better at this point.

@erebion @bonfire @swf @sovtechfund

Keys will be encrypted on the browser, locked with a separate password that’s not shared with the server.

There are some other synchronization issues we’re going to work out, but not before our first sets of code are due.

There’s more here than I can cover in 500char toots. But I’d be happy to chat some time to hear your thoughts

@erebion @bonfire @swf @sovtechfund

@bonfire @swf @sovtechfund @benpate
Cool!
Now now do #YourLock. You know, the encrypted social media suggested by #KSR in Ministry for the Future???

@benpate @bonfire @swf @sovtechfund Another thought before I'll catch up on sleep:

If the code that handles the key material comes from the webserver, that does not stop a government that's hostile from ordering the website owner to run malicious code that'll also encrypt messages for their people... That's what I worry mainly about in terms of security.

I am woefully ignorant here. Spare a link for this poor lad?

@LeftistLawyer @bonfire @swf @sovtechfund

Yes. There has to be trust somewhere along the path.

You could host your own server, but you’d still have to trust the developers to not install a back door. Or a supply chain hack. Or…

@erebion @bonfire @swf @sovtechfund

One goal is to make this an interoperable standard, so that you could make your own client app, then use your ActivityPub server as only a dumb pipe.

I think that would instill trust.

More in the AM.

@erebion @bonfire @swf @sovtechfund

@erebion @bonfire @swf @sovtechfund @benpate @evanprodromou

There is room for more instant messagers:

Blog • IMs come, IMs go.

#im #timeline #sms #irc #icq #aim #msn #jabber #xmpp and so on

(mov.im)

@benpate @bonfire @swf @sovtechfund The weak point will be wherever you host the webserver. If a court or corrupt official orders them to install something bad, perhaps a backdoor, that is an issue.

Yes, agreed. I know I said this before, but can't find it:

One important goal is to make a solid, consistent client-side API - something like what C2S was intended to be. That would enable interchangeable clients for mobile/desktop/etc that work with any server.. and greatly increase the trust factor.

I'm only good at making web apps, so that's what Emissary's first client will be. But there will be space for others to build on top of this work.

@erebion @bonfire @swf @sovtechfund

I feel like this is the right time to mention https://xkcd.com/927/

You're very right here. There are tons of IM services. "Why introduce another one?" is a reasonable question

But I don't see it in those terms because we're not creating a new network. This is adding features to network we already have

I'll still use Signal. And Apple Messages

And I'd also like to talk privately with people here, as well. There is room for both.

@debacle @erebion @bonfire @swf @sovtechfund @evanprodromou

@bonfire
How will this work for clients of servers with no JavaScript, like #snac2 and #honk? Well the server be doing the decryption as surely that breaks the point of it being "end-to-end"?
@swf @sovtechfund @benpate

Our initial clients will be built in JavaScript, so you’d need to enable JS on your browser to use it (for now)

And, it will require special features on your server, so this won’t work on Mastodon (for now)

Download the road, things will change. We’re defining a standard API that anyone can build in. So hopefully someone can built installable clients (iOS, Android, desktop) that work separate from your browser.

@ddlyh @bonfire @swf @sovtechfund