No, that’s like 20% of the blog post. This was a “2025 Retrospective” blog post. I always try to give a fun title to my end-of-year blogs. 2024’s was https://soatok.blog/2024/12/18/the-better-daemons-of-our-profession/

Until the mods randomly decide to censor you, like they did with my post about tech companies disrespecting user consent.

Oh, fair. I just remember getting a LOT of notifications from both apps. I didn’t check the exact ratio,

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?”.

Certainly. Thanks <3

The client side is its own beast. See https://github.com/soatok/mastodon-e2ee-specification?tab=readme-ov-file#components from my initial project (the “key transparency” thing from today slots neatly into the “Federated PKI” hole).

No, if you read the post it will make more sense.

Or the specification if you’re more technical.

If you want E2EE for Mastodon, you need key management to be solved first.

This solves a lot of the key management pain. It’s not v1.0 stable yet, but it’s finally implemented. I’ve been working on the spec for nearly 2 years.

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.