Egregoros

@dougwade @arcanechat @rysiek I don't want to break your heart but E2EE messaging will never happen on fedi no matter what anyone says, even Soatok himself. (furself?)

1. Fedi is accessed by users from multiple clients. So now you have a key synchronization problem that Matrix hasn't been able to get working correctly over the course of... 10 plus years?

2. every fedi app that exists which people use will have to updated to support it, and it will NOT be trivial. People are not going to give up their preferred apps just for E2EE messaging.

3. every web interface will have to be updated to support it properly. so now we're doing all this crypto in the browser. Your private key will have to live in browser local storage. Not great.

4. This of course implies that every fedi server will have to be updated to support it: Mastodon, Pleroma, Akkoma, all the Misskey forks, Lemmy, Pixelfed, Gotosocial.... and this is going to go smoothly without giant security issues happening due to poor implementations right? RIGHT?????

It's not going to happen.

What could happen is that this could become a Mastodon specific feature that only works with Mastodon and the official Mastodon app. Or perhaps there will be a specific e2ee messaging mobile app created that only works with Mastodon. But I doubt it.

The biggest problem with this idea is that the entire ecosystem will be so broken/fractured that people will instead choose something else that doesn't have this problem. Whichever is easiest to onboard and doesn't leave you guessing "will they be able to receive my messages?" will win. It will be a dedicated E2EE messaging service such as DeltaChat.

The people who keep talking about E2EE coming to fedi are only doing so for clout. They're either dishonest or just stupid and have no idea what it takes to build such an app that will be accessible to the masses.

And even if such a thing did exist, it is too easily blocked anyway. Not like it would have helped people in Iran or anything.

@feld @dougwade @arcanechat @rysiek 2. and 4. is just ‘we can’t improve just the part of fedi we’re on’. if it was any true, Pleroma would be merely a worse Mastodon clone. there are apps creating new kinds of experiences using ActivityPub and they’re planning to implement the MLS over AP spec. just telling users you can’t use E2EE messaging with some of your friends is much less confusing than the experience mainstream IM users are used to, like whatever recently happened to Facebook Messenger when they switched to E2EE by default

@mkljczk @arcanechat @feld @dougwade @rysiek At least with Pleroma, the chat part has been partly solved. Using classic AP DMs (to: ["https://example.com/users/recipient"]) for E2EE isn't doable without lots of added complexity, because you can add new mentions at least according to how most implementations do it.

E2EE over AP is suffering from the Linux case of reinventing the same wheel all over again. Instead of Ciscoware and XML, we have AP/JSON(-LD) and endless extensions, neither work great. Instead of reinventing a protocol never meant for private communications (although never explicitly said) as a simple transport layer, people should have tried to fix XMPP.

Here's Pleroma Chats as they should have been from the start, and I'm not joking that much: https://docs.ejabberd.im/developer/extending-ejabberd/elixir/#embed-ejabberd-in-an-elixir-app

@feld @arcanechat @dougwade @rysiek @mkljczk It does, but it also is the closest to an open and extensible ideal messaging platform that currently exists. And it mostly works on the server side. What is not working at all is the client side where 3 different OMEMO versions co-exist, neither of which are compatible with each other and clients seemingly choose which one to implement at random.

In some tangential way, it suffers from the same issue as AP always did. Way too extensible to its detriment.

I have not looked at the Delta Chat internals yet, but so far after trying to package the relay (probably should continue on that endeavor when I find some inspiration/time), I'm not a fan. If the core is a pile of unportable madness that vendors openssl of all (thanks Rust), it has little hope of surviving long-term. Unless a different implementation(s) (the Golang one's) get more traction than the current reference one.