I've written tons about why this approach was taken, but it might be inaccessible to someone with limited knowledge of modern cryptography protocol design. (Authenticated encryption, forward secrecy, context commitment, etc.)
This was my earliest blog post on the topic, if you want a place to start.
Your instance admin subtitutes the public key in your profile with one they control.
How do you stop this?
Like, half the point of E2EE for DMs is to prevent instance admins from seeing what your messages say. The other half is to prevent instance admins from being able to surrender anything useful to government subpoenas.
If you know the alternatives suck, you can organize to make an alternative that doesn't suck. Some of the existing ones might be a good starting point, but if you care more about usability than privacy or federation, it will inevitably become another Discord when the law man comes.
That said, the userbase of Discord is sufficiently large that some among you have the technical chops to replace it.
I agree with all of this except that his standard seems to be perfection, when a lot of us are not looking for a Signal alternative, but a Discord alternative, which it is. It’s still better than Discord.
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.
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.
Read the thing I linked
I am not envisioning an IM system.
I'm envisioning a correctly implemented encryption layer for how DMs currently work (with the caveat that I believe cryptography should never EVER be done in the browser (unless an extension or whatever)).
How much do you know about cryptography?
I've written tons about why this approach was taken, but it might be inaccessible to someone with limited knowledge of modern cryptography protocol design. (Authenticated encryption, forward secrecy, context commitment, etc.)
This was my earliest blog post on the topic, if you want a place to start.
Your instance admin subtitutes the public key in your profile with one they control.
How do you stop this?
Like, half the point of E2EE for DMs is to prevent instance admins from seeing what your messages say. The other half is to prevent instance admins from being able to surrender anything useful to government subpoenas.
Why would I want to use the client? :S
I'm just here to criticize cryptographic open source software. I don't actually want to use these programs.
Either way, it's just... weird.
https://github.com/simplex-chat/crypton/blob/90e1a0f46a2adb30feb3222b417ddef41b1feee1/Crypto/PubKey/Curve448.hs
I haven't reviewed SimpleX, but it does some weird things (Curve448? Really??) that make me wonder about the author's capacity for threat modeling.
It does a lot of good, actually.
If you know the alternatives suck, you can organize to make an alternative that doesn't suck. Some of the existing ones might be a good starting point, but if you care more about usability than privacy or federation, it will inevitably become another Discord when the law man comes.
That said, the userbase of Discord is sufficiently large that some among you have the technical chops to replace it.
Did you perchance see my previous blog post? https://soatok.blog/2026/02/11/on-discord-alternatives/
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/
You're thinking of the wrong admin lol
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,
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.