If people are already on Signal, good for them. But the real issue is getting people off the Meta apps. So if there's a good Fedi Messenger, that can definitely help!

That is one of Mastodon’s big issues to address. It’s not a protocol thing, but a server software issue that I know they’re going to address.

Really well articulated, totally makes sense!

A) that excludes 99% of the population, who deserve the same level of privacy as you do.

B) since it’s E2EE, most of the work is on your client. The updates to the server are minimal (C2S API + publish public key packages). So EVERY Fediverse server could support this. You’d just need a client that can send/receive encrypted messages.

C) Don’t let “perfect” be the enemy of “good” - giving people easy, modern tools is a win, even if the NSA can hack it.

Not Signal, MLS, which is similar but run by a group of industry organizations.

Post-quantum is possible in MlS, depending on the crypto algorithms you choose.

There’s more info about the project in general on https://emissary.dev/e2ee — though Mastodons announcement is a big new development I haven’t covered yet.

Interesting times ahead. I wonder if they will go for the Signal Protocol Post-Quantum Ratchets or similar?

I'm going to do a more succinct write up of this to share.

To introduce E2EE into public‑facing SNS & simultaneously try 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 voices may start demanding identity verification.

Awful for privacy, & it’s exactly why I strongly believe E2EE should be kept out of the core social layer & kept within dedicated tools instead.

Signal and similar tools tightly control trust models (trusted by default with centralized keys and safety number/verification UX), while federated SNS would have to pick between a similar central authority or a more fragile, user‑managed web‑of‑trust‑style setup.

The question with E2EE & SNS quickly becomes: How do we deploy this at scale, without breaking moderation, without confusing users, & without inviting legal or security failure?

It's why many people say: keep the public social layer unencrypted & use purpose built tools like Signal for private conversations.

Also, metadata, note that E2EE doesn’t stop the network from seeing who talks to who, when, or how often, so privacy is leaky even if message content is encrypted.

Completely agree, "roll your own" overcomplicates things. I simplified to spur curiosity, & why I ended with use of alternative tools for private messaging, like signal.

It can be simple. Generate your public/ private keys, & start trading public keys with people. When you send a message to someone it'll be encrypted using their public key & only able to be decrypted by their private key so your message to them stays secure. Sign that message with your signature to prove origin.

Sorry if I'm missing a part of your context..

This whole project should be "backward compatible." It's pretty easy to tell if your recipients all accept encrypted messages or not, so if you're messaging someone who doesn't accept encrypted messages, it should just fall back naturally to regular DMs.

Interesting take / prediction, thx for sharing!

> Want E2EE? Use PGP/GPG and do it yourself.

This bit doesn't fly with me; E2EE is For The People.

My sense is that "just roll your own" ignores the accessibility gap; that the DIY approach may be too complex for others.

(Admittedly not speaking from experience; I'm a #Signal user which is quite user-friendly)

Re: https://mastodon.social/@rusty__shackleford/116403857501332629

I'll just have to graffiti Wikipedia myself.

We're (Mastodon, Bonfire, and Emissary) not doing this from scratch. It's building on MLS, which is an open standard for end-to-end encrypted messages that is used by many big players in tech.

Plus, all of this is open source (mine is here: https://github.com/EmissarySocial/conversations-mls) so hopefully any theoretical back doors would be found by interested parties.

If you're interesting in auditing some code, I'd *love* for you to participate!