You're moving the goal post from "self-sovereignty" to supports federation with an infinite number of servers. Nothing is stopping you from compiling your own Signal server and modifying a Signal client to use your server.
Given that Signal is free as a service, supporting federation only increases their expenses.
Because centralisation provides ecosystem agility, which they absolutely value as an upside. Find a way of doing post-quantum secure key exchange? Just roll it out to the server and all the clients essentially overnight.
Security is extremely important, but it is not the only concern one should have when considering the design of a global communications infrastructure.
I worry a lot more about not having one single actor responsible in dealing for the communication of millions of people than about "quantum-resistant encryption".
> I worry a lot more about not having one single actor responsible in dealing for the communication of millions of people than about "quantum-resistant encryption
I'm glad you worry about this. Me and other people have other priorities.
You're putting an awful lot of effort into projecting your values onto other people, which is a bit weird.
Genuine question: Does Tor fall under the definition of federation? Either way, a Tor-like model would have security benefits over a centralized system like Signal, right?
Tor is distributed, not federated. And it has drawbacks, like high latency and a lack of a centralized system for human-friendly names (because that would mean a system like DNS, which is centralized). As far as security goes, there's probably little benefit. E2EE doesn't get more secure because there's more encryption.
The most comparable system to Tor that has practical properties I can think of is maybe ipfs, but nobody will store your encrypted chat blobs for you out of the goodness of their hearts. Ipfs also tends to have high latency. A slow system of uncooperative nodes isn't what you want your messaging app built on.
A federated messaging system looks a lot more like Matrix. The obvious problems are that splitting users up over multiple nodes mean encrypted data doesn't live on your instance, it lives everywhere the people are you chat with. Another problem is what you see with bsky, where identifiers come with a domain name (like an email).
IRC is also federated (sort of), and there's a long list of tired, age-old problems. The most common one is simple: different servers have different features, so you can't reliably "just use it" like you can with Signal.
You're moving the goal post from "self-sovereignty" to supports federation with an infinite number of servers. Nothing is stopping you from compiling your own Signal server and modifying a Signal client to use your server.
Given that Signal is free as a service, supporting federation only increases their expenses.
Without federation, Signal is still working with the advantage of network effects. So an open source server is not enough of a way out.
Element can do it for their Matrix servers. Process.one can do it for ejabberd. Prosody as well. Why can't Signal?
Back to your original point: please don't support an organization that doesn't share important values of yours! That is absolutely your choice!
You've named several products that share your values. Perhaps those would be a better fit if you were to donate.
Because centralisation provides ecosystem agility, which they absolutely value as an upside. Find a way of doing post-quantum secure key exchange? Just roll it out to the server and all the clients essentially overnight.
They've talked about this, a lot.
3 replies →
Federation can only make security worse and I do not want it. You can have something else.
Security is extremely important, but it is not the only concern one should have when considering the design of a global communications infrastructure.
I worry a lot more about not having one single actor responsible in dealing for the communication of millions of people than about "quantum-resistant encryption".
> I worry a lot more about not having one single actor responsible in dealing for the communication of millions of people than about "quantum-resistant encryption
I'm glad you worry about this. Me and other people have other priorities.
You're putting an awful lot of effort into projecting your values onto other people, which is a bit weird.
2 replies →
Genuine question: Does Tor fall under the definition of federation? Either way, a Tor-like model would have security benefits over a centralized system like Signal, right?
Tor is distributed, not federated. And it has drawbacks, like high latency and a lack of a centralized system for human-friendly names (because that would mean a system like DNS, which is centralized). As far as security goes, there's probably little benefit. E2EE doesn't get more secure because there's more encryption.
The most comparable system to Tor that has practical properties I can think of is maybe ipfs, but nobody will store your encrypted chat blobs for you out of the goodness of their hearts. Ipfs also tends to have high latency. A slow system of uncooperative nodes isn't what you want your messaging app built on.
A federated messaging system looks a lot more like Matrix. The obvious problems are that splitting users up over multiple nodes mean encrypted data doesn't live on your instance, it lives everywhere the people are you chat with. Another problem is what you see with bsky, where identifiers come with a domain name (like an email).
IRC is also federated (sort of), and there's a long list of tired, age-old problems. The most common one is simple: different servers have different features, so you can't reliably "just use it" like you can with Signal.
3 replies →