Requiring to use a smartphone is only one of my griefs against signal. "Security" (far right's favorite theme) is not *all* that matters. The internet I want is made of community-owned projects made with love and weirdness, self-hosters running services for family and friends, not giant corps running planet-scale inhuman centralised stuff. #Signal does not fit in this picture.
Hippo 🍉
in reply to Nicoco • • •Nicoco
in reply to Hippo 🍉 • • •Bhavani Shankar 💭
in reply to Nicoco • • •there's not a lot of difference between #signal and #whatsapp . The app store builds of Signal are not reproducible. Nobody has hosted their own version of the signal server and we can't know if the code running on their servers is the same as what's on GitHub. So both their server and client are effectively closed source.
Other than requiring smartphones, both are centralized in the US. Signal is hosted on #aws. Signal doesn't have #meta AI and other forms of enshittification.
Nicoco
in reply to Bhavani Shankar 💭 • • •I think marketing and advertising are something that we as a species urgently need to get rid of, for the sake of our brains, for the planet, and to stop wasting everybody's time on useless stuff that makes nobody happier. At least with signal you're not contributing to making those weapons more effective, and that's a huge win over using any Meta product in my book.
cherti
in reply to Bhavani Shankar 💭 • • •@bshankar
The server code is practically closed source for every platform. Even when you run the server, your own server might be open to you, but you cannot know what other people run, so theirs is practically closed source (in your terms) even if it's the same software you run (which again you cannot even know). You can only know for your endpoint.
The only solution for this is a trustless architecture. Signal is the only relevant messenger consequentially being designed by it.
…
cherti
in reply to cherti • • •@bshankar
…
So talking about an open source server is actually more of a nicety to take the code and do your own thing. You have no possibility to reliably connect that code to whatever is running on the internet except by pinkie promise from whoever runs it. That goes in particular for every federated or non-centralized solution. So the difference here is pretty non-existent.
Signal are in fact the only ones trying to mitigate this issue by experimenting with things like SGX/ZKP.
…
cherti
in reply to cherti • • •@bshankar
… In the end, you need to trust people running infrastructure. Centralized services have the advantage that you can at least know who's running the thing, which is more difficult in a federated scenario, but ultimately the only real mitigation for this issue is trustless architectures where the client distrusts the server component as much as possible.
Signal has done and is doing most if not all of the heavy lifting in that area nowadays, both in deployment and development.
Nicoco
in reply to cherti • • •It looks like you didn't read my initial toot about "security" not being all I care about. My point was precisely that I value other things, like self-hostability, hackability (sometimes just for fun!) and decentralisation. Trustlessness is sadly needed, I'm not denying it. But a world where noone trust anyone and it all somehow works out thanks to maths and computers (2 things I love though) is not the world I'm interested in building.
Nicoco
in reply to Nicoco • • •cherti
in reply to Nicoco • • •Nicoco
in reply to cherti • • •On a side note, thanks for replying and not just blocking or insulting me right away because I criticize signal. This sadly seems to be rare and is truly appreciated. ❤
Felix 🏳️⚧️♂️🖌️🎨🔞🐓
in reply to Nicoco • • •Nicoco
in reply to Felix 🏳️⚧️♂️🖌️🎨🔞🐓 • • •