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.

@phnt @arcanechat @dougwade @rysiek @mkljczk

> I have not looked at the Delta Chat internals yet, but so far after trying to package the relay

you absolutely can package the relay and I did it for FreeBSD but I don't see a point because half of it is based on very specific configuration of multiple services and that's not something that "packaging" alone can solve.

Now if you're annoyed about there being so many different services involved, you can look at other work being done in this area. There's a custom version of the Maddy mail server written in Go being worked on (and actively used in a certain country right now) so you can deploy servers with a single binary: https://github.com/themadorg/madmail

> If the core is a pile of unportable madness that vendors openssl of all (thanks Rust), it has little hope of surviving long-term.

The core as I package it on FreeBSD does not vendor openssl, and the reliance on any openssl at all can likely be removed in the not so distant future

@feld @arcanechat @dougwade @rysiek @mkljczk My annoyance with the packaging was more with the configuration being stuck in the debian-specific install tool (at least as of ~2 months ago). I've heard there were improvements on that front I think. The number of services involved was expected since it's email. If you want a normal Dovecot/Postfix setup, you need all of that anyway.

Packaging the core wasn't that bad, after packaging a bunch of python dependencies, because I decided to try my chances with packaging it on RHEL8. I think I have it successfully packaged, but I never tried testing it.