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

“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

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.