/s
What does work is centralise powder and authority with democratically chosen rules and regulations. It's the easy option, and it works. Fundamentally that's the thing "crypto" misses, those democratically created rules are there to protect the masses from the few. Unwittingly (?) the creators of Bitcoin actually created the greatest tool ever for financial crime and defrauding the unwitting general public when they were actually trying to empower them.
Centralization is an optimization, fragility/trust/single point of failure being tradeofs.
The old joke being that if an economist designed humans we would share one kidney between 3 people instead of having a redundant one.
Yes it most likely has. It's just not absolute. There's a very strong argument that all of history is supporting data for all societies and governments being on a spectrum of centralized power, with the more decentralized ones being better for the common person.
I also believe there are lots of companies who run their own internal git services to not be dependent on GitHub.
I agree though, in theory, git would allow some fully p2p working mode, where each developer just adds the machines of the other developers as remotes and there is no "authoritative" remote at all. If that was ever seriously proposed as a real working mode, it definitely didn't catch on, due to it quickly becoming extremely confusing.
In practice, having one universally agreed upon "authoritative" location of the project repo gives you an enormous amount of advantages, more than a p2p setup would give you.
I think as long as you can freely choose where to host that authoritative version and can quickly change its location if need be, I'd still consider git to be decentralised in practice.
The same is true of Subversion or CVS or Perforce, which are all very centralized source control systems. Relying on Github.com itself is another level of centralization over and above the near-universal industry pattern of having a centralized repo.
> I agree though, in theory, git would allow some fully p2p working mode, where each developer just adds the machines of the other developers as remotes and there is no "authoritative" remote at all. If that was ever seriously proposed as a real working mode, it definitely didn't catch on, due to it quickly becoming extremely confusing.
That is more or less how Linux kernel development works, with Linus' own repo just being more respected than others, but with many entities maintaining their own central repos (e.g. many distros and larger organizations only manually take patches or merges from Linus' repo, they don't otherwise rely on it in their automation). Changes are often collaboratively worked on for months or even years outside in sine of these repos before being sent to one of the official maintainers for inclusion in Linus' repo.
Now, this practice makes no sense at all for a centralized entity like a company, which is why virtually all companies used centralized repos where all code and collaboration happens by mandate - whether using Hg, Git, or SVN.
This sounds more "federated" than p2p though. I imagine each organisation has again a centralized hub for coordinating their own development on the kernel. So the collaboration between those different orgs (and eventually with Linus) is sort of a layer on top of the normal git workflow.
I think you can see "federation" patterns (i.e. where orgs/servers/hubs/etc are p2p but each user belongs to a particular hub) pretty often in decentralised systems - and my subjective impression is that they are a lot more successful than "true" p2p systems (where users themselves are p2p).
Other examples of that pattern would be IRC, Mastodon, email and in a limited sense the web itself (users are bound to a platform but platforms can interface with other platforms via APIs)
Crypto (and git) would be sort of hybrids: It's technically possible to use the system without a hub, but the vast majority of users goes through a hub - for crypto, those would be cloud wallets and the exchanges we're talking about...
That many people choose to use it though centralized services such as Github doesn't diminish its power as a tool for decentralized software development compared with earlier tools such as cvs and svn.
Likewise, Bitcoin and Ethereum also enable decentralized coordination that wasn't previously practical, and the fact that accessing them via centralized middlemen is currently popular doesn't change that.
I won't claim that github/gitlab couldn't somehow do evil remotely and cause you to nuke the code history next time you build from a hacked pull request or something. But even then there's a decent chance at least one developer hasn't done the evil git pull. And if that's the case I just copy it from them and I'm back where I was.
If I understand correctly, nothing at all like that was possible in the FTX case.
Back in the very early, more promising, days of crypto the standard critique of crypto was the common mantra "you can't use technology to solve social problems". I think we've had that objectively demonstrated multiple times now (and will continue to do so).
Though I do expect "No True Scotsman" to be a pretty favorite cry from the remaining crypto enthusiasts for quite awhile.