The Social Web Foundation Adds End-to-End-Encryption to Mastodon and Why This Is Probably Not a Great Idea
As gregarious as people are, they also love their privacy. Eavesdropping, reading over the shoulder, going through personal affects? Everyone can agree, it is egregious behavior when your privacy is violated, even when justified. Thusly, it is in one's nature – innocent or otherwise – to engage in the right of privacy. What people do not have the right to, is to demand provision of this privacy from external sources. Historically, you learn to wear your own mask, to bury your own secrets.
Simultaneously, we continue to see that people are contrarian. As much as the people love their anonymity, they equally love their identity, expressing themselves in both private and public spaces such as bars, clubs, boardwalks, or even Social Networking Services (SNS) like Mastodon. Within these spaces people hold a reasonable expectation to both privacy and respect, i.e. not to be harassed, mocked, doxxed, stalked, have their personal space, or likeness violated, etc. Unfortunately, this cannot always be guaranteed in public or even in private spaces, leading us to the necessity of moderation, which we will touch on later.
Considering these facts, you are likely to enjoy the idea of secure and private conversations with your associates. If this is the case, you are probably looking for a service that offers End-to-End-Encryption (E2EE). There are many services to choose from, some more secure than others. Whatsapp for example offers convenient but highly insecure E2EE, while Signal Messenger offers a less convenient, but more secure implementation.
E2EE explained simply is when everyone has two keys and a signature. You generate these keys, one public, one private, then start trading public keys and signatures with known associates. When you send a message to anyone, it will be encrypted using their public key & decrypted only by their private key. Your message stays secure in transit. Seal that letter with your signature we mentioned and you've proven yourself as the origin, avoiding impersonation.
Note: E2EE doesn’t stop the network from seeing who talks to who, when, or how often – “privacy” is leaky even if message content is encrypted.
Many individuals – including myself – have recommended using PGP's key generation, signing & message encryption/ decryption capabilities to send encrypted messages “anywhere”... this is less than ideal in 2026. The author of The PGP Problem – lvh – stated that if you want to talk,
Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based secure messenger.
Modern secure messengers are purpose-built around messaging. They use privacy-preserving authentication handshakes, repudiable messages, cryptographic ratchets that rekey on every message exchange, and, of course, modern encryption primitives. Messengers are trivially easy to use and there’s no fussing over keys and subkeys. If you use Signal, you get even more than that: you get a system so paranoid about keeping private metadata off servers that it tunnels Giphy searches to avoid traffic analysis attacks, and until relatively recently didn’t even support user profiles.
As for email?
Don't.
Now that we have explained what E2EE is, 'The PGP Problem', and the use of dedicated tools, let us take a look at this – From the Social Web Foundation, Implementing Encrypted Messaging over ActivityPub:
“Encrypted messaging has become a common feature on many social networks since ActivityPub was created, and its lack has inhibited Social Web adoption and public trust in the network.”
Do you genuinely believe the lack of E2EE is keeping the masses at bay? The grandmas and grandpas who just want to message their grandchildren? The mothers who just want to know when the next soccer meet is? I assure you, not a single “normie” is worried about E2EE unless they have swallowed marketing material. Perceived low conversion rates are because these people are literally addicted to their dopamine apps. The “Social Web” is fundamentally not Facebook, that is what you're observing.
Everyone has some expectation of privacy, particularly in regards to federated SNS. Many users are tired of service providers like Facebook “harvesting their data points for actionable business insights” leading them to options that provide a semblance of self agency and sovereignty. On one hand, these services do not traditionally track users, on the other hand, ActivityProtocol (AP) is running behind the scenes as the language of many of your favorite services, i.e. Mastodon. This type of protocol and the way it behaves is referred to as a broadcast protocol. Everyone, everywhere can see you and what you do, who you talk to, and when.
This is especially true when the other server is not fully respecting the protocol, when disrespected, “private” accounts and posts requiring follower approval may not be entirely private. This can lead to confusion and anger between users and operators for being followed by people who shouldn't have access, bots, or tracking services, each of which are disrespecting wishes, consent, or the protocol.
Because of these quirks, there are some nuanced avenues for harassment I will not outline here. Actively processing, investigating, and remediating the deluge of reports in the attempt to promptly moderate against rule breakers, abuse, harassment, exploitation, scams, etc. is already a Herculean and Sisyphean task. Due to abuse by both network users and operators, there are now regulations around the world regarding data retention or lack thereof, along with legal obligations and potential demand.
Everything so far leads the question with E2EE & SNS to quickly become: How do we deploy this at scale, without breaking moderation, without confusing users, & without inviting legal or security failure?
If an operator offers E2EE on an SNS like Mastodon – due to the nature of the protocol being comparable to a public space – suddenly we see the landscape become exponentially difficult, if not impossible to moderate. Operators will place themselves into the unfortunate position where they cannot properly serve and protect their users, or their legal obligations. Additionally, if you offer a secure service and it is not secure or your implementation is bad, what will you do if a litigious troll attempts to sue?
To introduce E2EE into public‑facing SNS while simultaneously trying to “solve” abuse, moderation, & legal exposure, the path of least resistance is likely to be “just verify everyone”, pushing identity‑linked, KYC‑style identity checks as a way to “anchor” trust & accountability. The loudest users and largest operators may start demanding identity verification to ease this friction.
This appears in the long run to be potentially bad for privacy, and it’s exactly why I strongly believe E2EE should be kept out of the core social layer & kept within dedicated tools instead. If people want to hide themselves, they have many options – third party clients, applications, and tools – as they have always had the ability and right to do/ use. It is not the operators responsibility to provide their users the ability to hide. Don't know how to encrypt your own messages? Talk on Signal. Mastodon is a public space, take your private conversation elsewhere. Don't forget, people were writing encrypted messages by hand before computers.
The cost outweighs the benefit. Please, make the sane decision, don't over complicate the backend and keep the public social layer unencrypted. Mastodon is a public space, use purpose built tools like Signal for your private conversations.
P.S. You do not need E2EE everywhere. If you indiscriminately E2EE with everyone across your personal, business, and social life, then a single impersonation can spread everywhere. At that point, the question becomes: how do you prove an imposter is not you?
Yes, at the moment these are optional features, but we ultimately teach our users unsafe and unsanitary practices by telling them it is alright to shit where they eat. Once it is the social norm, even if optional, it will be hard to offer a service that doesn't let users shit where they eat. In the long run this idea appears horrible. As the user, why are you putting the burden of your secrecy on the operator? As the operator, what will you do when users start placing the burden of their secrecy on you?
Source: https://socialwebfoundation.org/2025/12/19/implementing-encrypted-messaging-over-activitypub/
Update: Was informed of and removed mention of GPG as it is insecure, that same friend just provided this article as well, it is a wonderful read, and I will be updating this piece accordingly:
https://www.lvh.io/posts/the-pgp-problem/
Second Update: Removed this following section and updated due to old/ misinformation -
If you want to send encrypted messages anywhere, regardless of service, you could do-it-yourself by using PGP's key generation & message encryption/ decryption capabilities, alongside something like openBSD's Signify for signing and verification. There is also terminology like key rotation and key recovery but these over-complicate things for a simple chat between known associates.
Trade public keys, treat private-key leaks as full identity compromise, and keep circles small to foster high-trust networks.