- cross-posted to:
- lobsters
- cross-posted to:
- lobsters
I read the post, its very exhaustive and future seems promising. I might have missed the section but why it this separate mechanism needed in the first place? Is it just because of the key lifecycle management? If so, naiive approach of publishing public key on your profile falls short because of this and without public key management everything falls apart sooner than later?
why it this separate mechanism needed in the first place?
Because ActivityPub was not designed for E2EE. That’s the simplest answer.
The longer, and more technical answer, is that doing the actual “Encryption” part of E2EE is relatively easy. Key management is much harder.
I initially set out to just do E2EE in 2022, but got roadblocked by the more difficult problem of “which public key does the client trust?”.
What would world do without furries? ☺️
Very cool!
I can’t wait for the entire Fediverse to be E2EE (soon™)
For those who did not read the article yet, please do. It’s very interesting
Is this e2ee or just public signing? Signing sounds most doable to make sure a message came from the server it claims is from.
It’s a building block to make E2EE possible at Fediverse scale.
I’ve written about this topic pretty extensively: https://soatok.blog/category/technology/open-source/fediverse-e2ee-project/
If you can build in Federated Key Transparency, it’s much easier to reason about “how do I know this public key actually belongs to my friend?” which in turn makes it much easier to get people onboarded with E2EE without major risks.
Biggest issue is that people do not understand encryption. Even Matrix has same issue and they try to add hidden encryption. Though ye e2e will make web more secure. BTW great blog post was nice to read.
People also don’t understand IP, TCP, DNS, TLS etc. and yet can use programs that use all of that. I find e2ee still pretty cumbersome in the long run.
Great post. Looking forward to a more secure fediverse. This more important now than ever.



