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.
Unable to decrypt this message
Teeny tiny luks layers in the palm of your hand
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-in-activitypub draft 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). source: https://swicg.github.io/activitypub-e2ee/architectural-variations.html#validating-end-to-end-encryption
fedi devs need to stop clickbaiting, and fedi users should learn a bit more about their protocol to avoid getting misled this way
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:
fediverse
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).
compatibility
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 are making a new e2ee chat: great! emissary users will get a way to message other emissary users. but that’s it: you need to be on emissary, like with matrix you need to be on matrix
- they are making a fediverse e2ee chat: this isn’t easy! you can’t just make it for yourself, you need to clearly define how it works, and everyone must implement it too. otherwise mastodon or lemmy won’t know what to do with the message you sent
spec
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.
asymmetric encryption
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
mathmagicactivitypub keys
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!
A’s server can lie about bob’s key, give a random key, decrypt the message, then encrypt it with bob’s real pubkey and send it. this way bob knows nothing and A’s server can read the message. Same way, A’s server can give Bob’s server a fake pubkey for alice, so it can read the incoming message and then encrypt and re-send to alice with her real key. So trust is broken!
the spec offers 3 solutions to this:
- trusting your server, which is kind of the starting point and we don’t want that
- having a third party validate keys (either a centralized solution which Alice and Bob ask, or some yet-to-invent federated way to handle keys. we’re kinda back at point one)
- having alice and bob exchange keys themselves (maybe send them on matrix or signal, delegating the “identify and trust” issue to those services)
“knowing irl”
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
What would be the main difference compared to Matrix, which also claims to be “an open network for secure, decentralised communication”?
nothing per se, depends on implementation, see my other reply for some insights on key management
My primary concern was that last bit you wrote: e2ee doesn’t necessarily guarantee anything; corporate overlords like Meta has abused it and iirc the British government is starting to fuck with e2ee too.
Does e2ee even mean anything anymore?
TLDR: an e2ee channel means “everything passing over this channel is super secure and private, but it needs some keys for this to work”. e2ee means something: you can not care about most issues with delivery and protection and such, but you need to care about the keys. if you don’t do that, you are probably ruining the security of such e2ee channel
end-to-end-encryption solves one issue: transport over untrusted middleware, doesn’t mean much by itself. it’s being flung around a lot because without proper understanding sounds secure and private.
it’s like saying that i ship you something valuable with a super strong and impenetrable safe. but what do i do with the key? e2ee is the safe, solves the “how can i send you something confidential when i dont trust those who deliver it”, and it means much! it’s a great way to do it.
but it solves one problem giving a new one: what to do with the key? this usually can be combined with other technologies, such as asymmetric encryption (e.g. RSA), which allows having keys which can be publicly shared without compromising anything. so i send you an impenetrable code-protected safe with an encrypted code attached, and only your privkey can decrypt the code since i used your pubkey!
(note: RSA is used for small data since encryption/decryption is cpu intensive. usually what happens is that you share an AES key encrypted with RSA, and the payload is encrypted using that AES key. AES is symmetric: one key encrypts and decrypts, but AES keys are small. another piece of technology attached to make this system work!)
but now comes the user-friendliness issue: very few are big enough nerds to handle their keys. hell, most folks don’t even want to handle their passwords! so services like matrix offer to hold your keys on the server, encrypted with another passphrase, so that you don’t need to bother doing that, just remember 2 passwords or do the emoji compare stuff. it’s meh: compromising the server could allow getting your keys and kinda spoils e2ee, and once i stole you one password i can probably steal you both, but it’s convenient and reasonably secure for most. you can absolutely opt out, but every time you log from a new device, you can’t read anything sent before unless you export and import your keys manually.
what does whatsapp do? i don’t know! but it kind of magically works. if they do e2ee, where are the keys??? how does meta handle reports if messages are e2ee???
i’m not sure about signal but everyone praises it so i guess it’s good? also it seems you can’t restore messages via network, you need an export from a previous install, so it seems your keys live inside your app data, which is good and safe i guess.
also, e2ee works if you can trust the key you’re sending to! as mentioned in the ‘activitypub keys’ section before, if you ask a middleman the key for your recipient, can you trust that’s the real key? e2ee doesn’t cover that, it’s not in its scope
so what does e2ee mean? it means: super strong channel, ASSUMING keys are safe and trusted. e2ee as a technology doesn’t solve “all privacy” or guarantee that nobody snoops in per se. it offers a super safe channel protected by keys, and lets you handle those keys how you more see fit. which meaning deciding who you trust to send, how you let others know how to encrypt for you (aka share your pubkey) and how you will keep your privkey safe.
thanks for coming to my TED talk btw
I felt like a 90 year old grandma reading this.
You and me both.
But after pondering the orbs for a minute I think they’re saying, that it’s just Emissary trying to get E2EE working and not Fediverse as a whole.
And they follow with some objection with the proposed draft. I can only comment on the 3rd one, it basically mean you need other channel of communication to manually compare fingerprint (i.e via Matrix/Signal) to make sure your activities on Emissary is actually encrypted, maybe lol.
but wouldn’t you also need to verify the matrix/signal contact? both of them gives you the option to verify the other, but its very rarely used by people. so, you need either an already verified secure channel, or meeting on the street.
but then again we don’t actually know each other. so if we meet, how would you know it’s actually me, and not someone impersonating me?
how would you know it’s actually me, and not someone impersonating me?
Well, yeah the assumption here is that we both already knew and trust each other IRL and you personally give me this contact info and the check is there to make sure I was actually connected to you.
We as layman didn’t do this but I would assumed someone who is a high profile target actually do this kinds of checks.
Fediverse and Linux have to be the most unholy tech union in existence.
I thought we already had Matrix
We do.
This is for activitypub DMs.
That’s what I mean.
The headline is a lie.If I say tacos coming soon, it doesn’t mean I invented tacos, just that there will be new tacos I guess
I heard this is the line for tacos.
Lines long as 2, and they only come three ways. Steak, cilantro, lime, cheese with your choice of sauce… Chicken chipotle mixed Mexican blend cheese, and cilantro lime, rice-cauliflower.
Sides are open as a bar, self serve.
I want beans and rice, no meat!
I’ll take one
i’m suddenly hungry for tacos
Then I charge you with naming you favorite genre at least. Barbacoa?
last time i had lamb barbacoa/arab kind of tacos was more than a decade ago and i still cherish that memory for a variety of reasons. not very common here though.
i will usually make chilli tacos for the relative simplicity of making them, when i’m already baking beans anyway.
That sounds delicious. I need more pitas in my life. Thoughts of shawarma always make me hungry.
But we already have tacos.
If you say “Tacos are coming soon”. And we already have tacos. I’d say “What do you mean? Tacos are already here. Do we need more tacos?”Do you just ask if we need more tacos? The answer is always yes… Where is your insatiable hunger?
Does Trump always chicken out though?
Waiting for pizza
Tacos become pizza toppings. Full size tacos, on top of your pizza.
If anyone ever asks “Do we need more tacos?” it becomes your responsibility to slap this individual. Because obviously yes. The answer is ALWAYS yes. Always more tacos. Always.
Matrix is not really integrated into the ActivityPub protocol the same way DMs usually are. I would have to open a separate application to message you on Matrix, I can’t just click on your profile and shoot you a DM (or can I?).
You cannot, two totally different protocols
There you go. So I think adding DMs to ActivityPub would add an extra level of convenience
I mean, there’s nothing technically stopping one app supporting both protocols natively, especially since Lemmy already includes a field for people’s profiles to link their Matrix ID. Though to my knowledge none do it yet.
Sure, in the same way there is nothing stopping Lemmy from using ATProto. The problem is all competing standards and what the developer chooses to use.
Perhaps, but I’m describing something slightly different. Your description is basically “one platform supporting two protocols that basically do the same thing”. I’m talking more about “one app that has two separate-but-related bits of functionality, each using the more appropriate protocol for that job”.
ActivityPub is only one of a number of federated protocols.
One notably unsuited to instant messaging.
I, too, am often pissed at clickbaity, exaggerated, deliberately ambiguous headlines.
The subtitle makes it clear though: this is about ActivityPub, which has grown into the #1 federation protocol I guess.
No it’s not. Matrix isn’t part of the Fediverse. It doesn’t use ActivityPub and there is no interop with any other Fediverse service.
That doesn’t make Matrix bad, it just makes it it’s own thing.
ActivityPub isn’t the only way to be federated. Email is federated. Email isn’t ActivityPub. Matrix is no different.
It’s not, the demo video actually shows that being one such use case. There’s nothing stopping anyone from writing a chat service in ActivityPub. But this can also apply to statuses, media, all kinds of other stuff.
And XMPP before it, even for e2ee messaging.
At least this is a slightly different use case.Matrix is decentralized but its not federating in a way like activity pub is doing
ActivityPub isn’t the only way to federate.
Matrix is federating the same way email does. Anyone can spin up their own server. And if they want anyone can spin up their own software. That’s what federation is. Different servers agreeing on how to communicate with each other.What??? I thought being part of Federation meant being part of the WORLD WRESTLING FEDERATION!
OOOOH YEAH, SEE I’M ALWAYS THINKIN THINKIN THINKIN, YEAH. AND WHEN IT’S ALL SAID AND DONE, WE DO THING IN THE RING! DIG IT! THE TOWER OF POWER TOO SWEET TO BE SOUR, FUNKY LIKE A MONKEY! OOOOOOH YEEEAAAHHHH!!!
Pomp and circumstance plays over the house speakers
ELIZABETH!!!
No that’s decentralization, federating is when you can share the info natively outside the platform.
share the info natively outside the platform.
I’m not even sure that makes sense.
Federating is based on protocols not platforms. And what does it mean to share natively if not using the protocol?That’s a distinction that only matters to nerds.
Luckily most of us on here are nerds so it’s all good.
How so? It’s certainly very similar.
The matrix protocol enables federation between different instances running different homeservers between users using different clients.
But all those clients are matrix, not say some discord, some fluxer, some stoat, etc.
All activitypub platforms are activity pub. Also, matrix is a protocol, not a client. There’s tons of clients for matrix (element/element x being the main one).
Yes?
“Matrix” is the protocol.
The equivalent is ActivityPub, not discord, fluxer or stoat.
The Fediverse isn’t federated.
All those clients are ActivityPub, not say some Twitter, some Facebook, some Bluesky, etc.
How is that different?
What do you mean?
And what benefit justifies yet another standard?
In this day and age we need as many open source e2e encrypted alternatives as possible.
Matrix is a protocol, not an “App”. We would all benefit if everyone stopped doing their own thing, and started to push stuff for Matrix.
Huh? ActivityPub is also a protocol, now with this feature, why does that extra feature stop people from using Matrix?
Matrix has a list of specs, and ActivityPub has a different list, there may be some overlap but what’s the problem here?
Because this is being advertised as federated end to end encrypted chat. They already exists and it’s called matrix, and it works damn well.
Matrix does not connect natively to discord as an example, every user of a matrix protocol is still within matrix
Activitypub doesn’t connect natively to my toaster.
Sounds like you need to upgrade your toaster, noob.
So? Does anything connect to discord, legally and natively?
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.
https://soatok.blog/2026/02/17/cryptographic-issues-in-matrixs-rust-library-vodozemac/
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.
Well now this sounds interesting. And I assume it’s open source?
🤯 That gave me pause. What made you ask (would non-FOSS even be an option for anything ActivityPub)?
It seems so, as the project (Emissary) is using the GNU Affero GPL.
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.
deleted by creator
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.
@benpate@mastodon.technology that’s amazingly quick work after just under four weeks. I’m looking forward to the result.
Finally I can discuss my scat fetish with my fellow scat enthusiasts away from the prying eyes of the NSA!
Nyeh-heh heh heeh!
Scat fetish means you like scat singing, right? scatman
i came 😩
this will pair nicely with my shit fetish videos
Also XMPP with omemo?
Especially with the Movim client :)
Let’s gooooooo
Major League Soccer messaging? Let’s goooo
