6 ms·
I'll add my thoughts here, since I think a number of people will be disappointed in this post. There are a number of competing goals when developing software t
by tprynn 10y ago
I'll add my thoughts here, since I think a number of people will be disappointed in this post.
There are a number of competing goals when developing software that "the whole world can/will use". And it seems obvious to me that getting the whole world to use a secure, encrypted messenger like Signal (now, Whatsapp) is a noble goal. The obvious competing goal is federation, and the fact that we've failed at improving federated services (e-mail being the best/most important example) is a problem.
Ultimately, Moxie's arguments here hold a lot of sway for me. I think it sucks that constantly-improving services are impossible to address in a federated way, and he's not really offering a solution to that. But instead he presents arguments I hadn't thought about much, which is that perhaps non-federated services can be dramatically better than federated services in the short-term. And in the long term, perhaps we'll move back to federated services; right now, the cost of changing services/ecosystems is very low. So we don't need to be as 'doom-and-gloom' about the fact that Signal does not achieve all the competing goals, because it achieves a number of extremely important goals right now, and we can work on the other goals in the future.
- marssaxman 10y agoIt's precisely the fact that Moxie is so credible on this topic that makes his post so frustrating. I believe that he's telling the truth as he sees it, and I believe that he's as well-situated as anyone could be to pull off a white-hat secure messaging system, so if he says it can't be done with federation, it's awfully hard for me to assert that he's wrong. The problem is that I don't see the point of doing any of this without federation. If we're just using the Internet as a substrate for a bunch of proprietary silo services, then we're just back to the way things were before - walled gardens and media conglomerates and extortionate Bell System-style lock-in shenanigans. So what? Why bother? What have we gained, with all this effort, if we're back in the same old shit again? The whole point was that we no longer needed to get anyone's permission to communicate, to publish, to build new services for interacting with each other; we could just do it. If federation is gone, then those days are gone, and the most important reason to care about the Internet is gone, too.
- moxie 10y agoI hesitate to get all Clay Shirkey here, but I think this is fundamentally different from media conglomerates and Bell Systems, given that now anyone has the ability to build their own overlay service with relatively minimal investment. Part of what I've been noticing is that we have these "walled gardens" today that people consider to be synonymous with "lock in," but it's actually easier for people to move from Viber to WhatsApp to Telegram to Signal today than it is for people to move from gmail to yahoo mail. In a sense there's less lock-in with centralized messaging services than there is with the federated ones, due in part to the move towards user-owned identifiers like phone numbers.
- deleted 10y ago[deleted]
- cortesoft 10y agoI get what you are saying about it being easier to move from one walled garden to another (based on the evidence that those moves happen more often than moves from between email providers)... but there is such a huge caveat that those moves are never a move chosen by an individual. I cannot, as an individual, choose to move from one walled garden messenger app to another - if I do, I cannot message those people that don't. I am stuck going along with the group. This is ok in a lot cases (when the group's priorities line up with mine), but sometimes the things that are important to the group are different than the things that are important to me. For example, I might prioritize security over ease of use, but since the group doesn't, I will never get my wish, and I am stuck on a service that sacrifices security for ease of use.
- schwarrrtz 10y agoWouldn't you still have that problem with a federated system? You could roll your own uber-secure decentralized messaging protocol right now, if you wanted, but if nobody else adopts it then you're basically SOL.
- 10y ago
- lettergram 10y agoI feel the same way, about achieving goals "right now" as you put it. The largest problem I see with security, is the ecosystem is in a constant cold war. Always trying to be perfect, many times at the cost of in convenience. "Do one thing and do it well," always rings true to me. As an aside I have made a stab at prototyping a solution to the federated services using the keybase API: https://github.com/lettergram/AnyCrypt https://github.com/lettergram/AnyCrypt
- cJ0th 10y ago> I think it sucks that constantly-improving services are impossible to address in a federated way, and he's not really offering a solution to that. The solution would be education. Federation would work okayish if the average user was more tech-literate and thus could see that federation in combination with the willingness to migrate to a new protocol every decade (or even sooner) would be superior to any centralized solution. Of course, changing protocols on a weekly basis would be too much but everything has its trade-offs.
- sytse 10y agoFor me the sentence that resonated most was "If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead.". If the centralized service is running mostly open source software than people can easily switch to another provider. GitLab.com runs GitLab EE which is similar to GitLab CE people can use to start another service (which has been done). I think having a centralized service allows us to move faster than with a federated service. That doesn't mean we wouldn't like to make it more federated, I would love that https://gitlab.com/gitlab-org/gitlab-ce/issues/4013#note_3064702 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013#note_306...