Submitted 2 weeks ago by deadsuperhero@lemmy.world to fediverse@lemmy.world
https://wedistribute.org/2026/02/fediverse-e2ee-coming/
Important progress has been made regarding bringing MLS end-to-end encryption to the ActivityPub protocol, with developers already building implementations and providing feedback to a future version of the protocol spec.
Well now this sounds interesting. And I assume it’s open source?
It seems so, as the project (Emissary) is using the GNU Affero GPL.
🤯 That gave me pause. Would non-FOSS even be an option for anything ActivityPub?
this is misleading and sensationalistic. if emissary implements e2ee, it’s not “e2ee for the fediverse”, it’s " e2ee for emissary users". did mastodon talk about e2ee? did lemmy?
also the MLS draft (supposedly "better than signal “) proposes for trusted key exchange either " trust the server” (lmao), use a centralized key authority (wow) or have users manually verify their keys out of band (so basically use matrix to assure your chat is encrypted)
fedi devs need to stop clickbaiting, and fedi users should learn a bit more about their protocol to avoid getting misled this way
I felt like a 90 year old grandma reading this.
You and me both. But after pondering the orbs for a minute I they’re saying, that it’s just Emissary trying to get E2EE working and not Fediverse as a whole.
Fediverse and Linux have to be the most unholy tech union in existence.
Can you (or someone) explain like I’m 5?
hi! sorry for throwing this here without explaining much, explaining a bit seems definitely due diligence!
so, i need to make some things clear, skip if you know these already:
the fediverse is not a single software, rather a collection of softwares speaking a common language (sharing a protocol: activitypub). the classic example is mail: on gmail you can email folks on outlook. they just know how to send messages to other instances/servers/deployments, and how to receive. for example, email (SMTP) expects data formatted in a certain manner (lots of headers and a body, kinda) on port 25. Activitypub expects activities (json-ld documents) coming over inboxes (POST to http endpoints).
now, say emissary sends an encrypted message to a mastodon user. mastodon doesn’t know what to do with that document! it’s a garbled mess of encrypted data, what is mastodon supposed to do with it? there are no rules for this in the spec! the post claims “federated” (aka, across multiple servers) e2ee messaging, and that already exists with multiple solutions. what they mean to me is either
they link two specs: MLS (an IETF spec defining scalable e2ee messaging), and activitypub-e2ee. the first one is great: i think matrix wants to move their encryption to that? it’s good, but it’s a spec: you need to adapt it to your use. the second one is how MLS can be applied to Activitypub communication: the thing we care about! unfortunately the later spec is just a draft, so it needs more work and it’s unlikely that it will see adoption in this state.
so now i need to go a bit into asymmetric encryption, in this case RSA. there’s a lot of great examples if you put “asymmetric encryption” or “rsa” into google, but i’ll try my best here. imagine 2 folks trying to communicate, Alice and Bob, but they need to have a postperson deliver their messages. they don’t want such postperson reading them! how to do that? A and B both get two “keys”: one private and one public. these keys are related to each other: a pubkey “has” a privkey, and vice versa. these keys are also “magic” (math, good luck if u wanna dig in here, if you’re not into math just trust me the keys are magic). using a public key, you can encrypt a message so that only the related private key can decrypt it. and using a private key you can encrypt a message so that only its public key can decrypt it. the second case is for identity proofing, we care about the first one: if A and B make their public keys public (heh), they can both use such keys to create messages meant only for either A or B, assuming they still hold their private keys, and nobody else. because math magic
in activitypub every actor holds a private and public key. this is how the protocol does “authorized fetch”, meaning making sure an activity truly comes from the actor claiming to send it. so we can use these keys for doing e2ee!
Alice <—> A’s server <—> B’s server <—> Bob
Alice can ask her server to get Bob’s public key from Bob’s server, and then encrypt a message for Bob and send it via the servers without anyone snooping in. Great? NO!
some users compared the issue with “knowing each other irl” but it’s not the same. on signal, i trust you to be you, and our conversation to be private. if i search you by username, i can just message you. trusting your username is you is a meaningless discourse here: you are your username. i’m writing this to “Abundance114”, i don’t care who you are, i just want this to reach “Abundance114”. so on signal i plug your user and our keys automagically reach each other safely. this spec doesn’t explain how this happen: i would need to first identify and trust you, Abundance114, and then find a way to safely communicate with you so we can exchange keys.
i hope this wan in-depth enough! i’m not an encryption expert, if any is here i’m open to critics, but this seems reasonable to me with my protocol and encryption experience. basically i believe this post is hype bait: whatsapp is e2ee, but who has the keys? do you trust meta? sure, the message travels encrypted, but who can read it? only you? an e2ee system is not just its encryption tech, but the way keys are securely shared
I have a bit of an issue with the title, considering federated end to end encrypted messaging has existed since, at the latest, 1991.
What’s the messaging protocol?
Pgp is protocol agnostic, you can use it over email, xmpp, irc… Over pretty much anything that supports plugins.
It’s usually used for email tho.
Fake journalists not even bothering to google that XMPP exists #10496839485.
This is about implementing E2EE directly into ActivityPub, so that has nothing to do with this.
MLS will eventually be included in all messengers.
It was initially introduced by Wire as an RFC, but they fumbled the federation by making it an enterprise only feature. Because of that, other messengers will do the federating for them. iMessage, Google Messenger, Matrix, and Germ DM (Bluesky) do or partly have it implemented.
We should always have more alternatives to chose from - good to see so many players.
Unable to decrypt this message
Finally I can discuss my scat fetish with my fellow scat enthusiasts away from the prying eyes of the NSA!
Nyeh-heh heh heeh!
i came 😩
@benpate@mastodon.technology that’s amazingly quick work after just under four weeks. I’m looking forward to the result.
But, what about Session? It’s decentralized, E2EE, uses Lokinet, seems pretty solid, no?
No phone, email, or other info needed to sign up
Why?
What benefit does this have over Signal/Matrix?
The article just says “improvements”.
why? because it would be cool if only intended recipients are able to view sent messages.
That’s not really going to be the case if you’re using a website instead of an audited app like signal/matrix.
So, I used messaging here in the broad sense. One possible application for it is instant messaging, which there are ActivityPub implementations out there doing that. But it can also be used for statuses or pretty much anything else that gets federated.
That actually sounds cool, I wonder if they could support Hidden containers, so the same message can be decypted to different messages by different users.
One benefit is that Signal controls all the infrastructure and some people do not like that. Sure, you could also spin up a Matrix home server, but that isn’t an ideal solution for everyone either. Some people want to do messaging via their existing ActivityPub infrastructure and that’s OK.
from what i can tell, mls supports much larger group chats (50k users) whereas i assume signal would struggle.
my chat of 10 people i signal seems just as secure, if i am reading right.
Let’s gooooooo
Major League Soccer messaging? Let’s goooo
Also XMPP with omemo?
Especially with the Movim client :)
good news everybody!
Teeny tiny luks layers in the palm of your hand
Can we fix nomadic actors ie one account all instances first please. Ffs its the 1 big issue with Activpub
Steve@communick.news 2 weeks ago
I thought we already had Matrix
MentalEdge@sopuli.xyz 2 weeks ago
We do.
This is for activitypub DMs.
Steve@communick.news 2 weeks ago
That’s what I mean.
The headline is a lie.
confuser@lemmy.zip 2 weeks ago
Matrix is decentralized but its not federating in a way like activity pub is doing
Steve@communick.news 2 weeks ago
ActivityPub isn’t the only way to federate.
It’s federating the same way email does. Anyone can spin up their own server. And if they want anyone can spin up their own software.
MentalEdge@sopuli.xyz 2 weeks ago
How so? It’s certainly very similar.
The matrix protocol enables federation between different instances running different homeservers between users using different clients.
RIotingPacifist@lemmy.world 2 weeks ago
What do you mean?
And what benefit justifies yet another standard?
ViatorOmnium@piefed.social 2 weeks ago
And XMPP before it, even if for e2ee messaging. At least this is a slightly different use case.
HailHydra@infosec.pub 2 weeks ago
Matrix is a poor choice from a cryptographic perspective. With some serious issues historically (some of which are still unfixed to this day), and an extremely poor response to disclosures.
soatok.blog/…/cryptographic-issues-in-matrixs-rus…