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?
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.
I thought we already had Matrix
Matrix is decentralized but its not federating in a way like activity pub is doing
Finally I can discuss my scat fetish with my fellow scat enthusiasts away from the prying eyes of the NSA!
Nyeh-heh heh heeh!
What do you mean?
And what benefit justifies yet another standard?
Why?
What benefit does this have over Signal/Matrix?
The article just says “improvements”.
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.
How so? It’s certainly very similar.
The matrix protocol enables federation between different instances running different homeservers between users using different clients.
We do.
This is for activitypub DMs.
That’s what I mean.
The headline is a lie.
We should always have more alternatives to chose from - good to see so many players.
Major League Soccer messaging? Let’s goooo
If I say tacos coming soon, it doesn’t mean I invented tacos, just that there will be new tacos I guess
why? because it would be cool if only intended recipients are able to view sent messages.
I’ll take one
That’s not really going to be the case if you’re using a website instead of an audited app like signal/matrix.
good news everybody!
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?”
that argument doesn’t hold. you’re letting perfect be the enemy of good-and if you truly believe that, then you wouldn’t be recommending Matrix which has web clients, see https://app.element.io/
Do you just ask if we need more tacos? The answer is always yes… Where is your insatiable hunger?
But, what about Session? It’s decentralized, E2EE, uses Lokinet, seems pretty solid, no?
No phone, email, or other info needed to sign up
In this day and age we need as many open source e2e encrypted alternatives as possible.
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
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.
Waiting for 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.
Tacos become pizza toppings. Full size tacos, on top of your pizza.
@benpate@mastodon.technology that’s amazingly quick work after just under four weeks. I’m looking forward to the result.
No that’s decentralization, federating is when you can share the info natively outside the platform.
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!!!
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?).
But all those clients are matrix, not say some discord, some fluxer, some stoat, etc.
That’s a distinction that only matters to nerds.
Luckily most of us on here are nerds so it’s all good.
Matrix does not connect natively to discord as an example, every user of a matrix protocol is still within matrix
You cannot, two totally different protocols
And XMPP before it, even if for e2ee messaging. At least this is a slightly different use case.
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.
There you go. So I think adding DMs to ActivityPub would add an extra level of convenience
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.
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.
Now that’s the insatiable appetite I know. No tacos, no sandwich, no cheese infested bread substances like pizza left behind. I will hate my stomach as it fattens, but so long will it reign. A Pad Thai cheeseburger might kill a man,but it only has one bad quality. Availability
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.
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).
Activitypub doesn’t connect natively to my toaster.
Any we client including Matrix we webclient is incredibly vulnerable to the server just injecting JS and reading your messages.
Like there is no point of E2E encryption in Twitter, Musk can read your messages if you open them on any device he can execute arbitrary code on.
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?
ActivityPub is only one of a number of federated protocols.
One notably unsuited to instant messaging.
The Fediverse isn’t federated.
All those clients are ActivityPub, not say some Synapse, some Continuwuity, some Rocket Chat, etc.
How is that different?
Yes?
“Matrix” is the protocol.
The equivalent is ActivityPub, not discord, fluxer or stoat.
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/
Any we client including Matrix webclient is incredibly vulnerable to the server just injecting JS
That doesn’t preclude fediverse clients from enabling E2EE. A web-client isn’t a requirement.
Like there is no point of E2E encryption in Twitter, Musk can read your messages if you open them on any device he can execute arbitrary code on.
Agreed, nobody should trust twitter, but I would trust most mastodon clients to send encrypted messages, if/when implemented correctly. Does it guarantee that messages will never be read? No, but it does an extra layer that wasn’t there before.
I have a bit of an issue with the title, considering federated end to end encrypted messaging has existed since, at the latest, 1991.
It seems so, as the project (Emissary) is using the GNU Affero GPL.
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.
Sounds like you need to upgrade your toaster, noob.
i’m suddenly hungry for tacos
Then I charge you with naming you favorite genre at least. Barbacoa?
Scat fetish means you like scat singing, right? scatman
Does Trump always chicken out though?
What’s the messaging protocol?
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.
🤯 That gave me pause. Would non-FOSS even be an option for anything ActivityPub?
Also XMPP with omemo?
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.
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.
So? Does anything connect to discord, legally and natively?
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.
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?
Can we fix nomadic actors ie one account all instances first please. Ffs its the 1 big issue with Activpub
Fake journalists not even bothering to google that XMPP exists #10496839485.
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.
This is about implementing E2EE directly into ActivityPub, so that has nothing to do with this.
I want beans and rice, no meat!
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.
Especially with the Movim client :)
i came 😩
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.
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.
yeah the content makes that clear but the headline does not
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.
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?
Can you (or someone) explain like I’m 5?
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.
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 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
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! * 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 a fake pubkey for alice, so read the 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)
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
Unable to decrypt this message
Teeny tiny luks layers in the palm of your hand
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?
What would be the main difference compared to Matrix, which also claims to be “an open network for secure, decentralised communication”?
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”.
nothing per se, depends on implementation
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, but it’s convenient and reasonably secure.
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???????
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.
