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.

https://github.com/EmissarySocial/emissary

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.

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. What made you ask (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-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

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 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.

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 😩

this will pair nicely with my shit fetish videos

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.

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:

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 math magic

activitypub 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

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, see my other reply for some insights on key management

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