@delta I don’t think that spreading poorly substantiated accusations of technical infidelity against signal helps your mission, or anyone else.
I think it’s cool that you’re writing your own messenger software, but please spread the word about it by advertising how it is good, not by trying to push others down who fight for the same causes as you.
@jaseg what exactly is "poorly substantiated accusations" in our post? We have often applauded signal for their cryptography achievements but their infrastructure choices are a different thing. Infrastructure matters. And we were laying out what we are doing in the same post.
@delta they’re poorly substantiated in that they boil down to “large cloud provider bad” without considering why signal chose a large cloud provider, and what they have done to mitigate the centralization. The latter is the interesting bit, since they structured their protocol considering the cloud provider untrusted. This means the provider learns very little about their users, and their main role is providing uptime.
@delta By over-reducing your point to “cloud provider bad” you’re circumnavigating a whole informed discussion and effectively spreading fear, uncertainty and doubt to people who don’t understand how signal works at a technical level.
@jaseg well, even signal's president started off by viewing hyperscalers as problematic. We then layed out how we want to address the reliability and uptime challenges (through using cheap relays redundantly). It's tough technical challenges to realize the plans. But discussing infrastructure and different ways than giving 20+ millions to hyperscalers yearly is not FUD.
@delta I'm not saying you don't have a point. I'm not a fan of these providers either, and I think @Mer__edith is uniquely qualified to understand the risks and benefits they have. My issue is with the reductionist view you were broadcasting in the first toot in this series, which didn't go into any of that nuance and read like FUD to me.
