3 ms·

I'm worried about the resiliency of code distribution as we continue the trend of centralizing distribution in a few large companies. GitHub has had service out

I'm worried about the resiliency of code distribution as we continue the trend of centralizing distribution in a few large companies. GitHub has had service outages in the past, so what happens when not just our repositories but also now packages are not accessible the next time that happens? It would be great if they'd implement it using an open/decentralized protocol such as IPFS, so that even if GitHub went down the content would still be accessible.

deleted 7y ago
[deleted]
ilaksh 7y ago
There have been a few decentralized GitHub projects, but they've been largely ignored by developers. For example gittorrent or axic/mango or gitchain. When I have tried to promote them I've been downvoted. It seems pretty strange to me.
acdha 7y ago
The problem is that hosting and bandwidth aren’t free and abuse is a big problem. Managing a distributed petabyte-scale archive which gets updated so frequently is a significant engineering problem even for a single party — now consider how you’d handle redundancy and routing when you can’t rely on any of the parties involved, and you have enough different objects being accessed to turn away most participants unless you can guarantee that participating won’t blow your ISPs data caps, interfere with other use, etc. Abuse is the other huge problem: think about what happens when you’re hosting some BLOBs and the FBI shows up at your door because someone uploaded some kind of contraband and some of it was available from your IP address. How many people are going to setup completely independent hosting accounts to avoid fallout from something like that which happens so regularly? The closest thing which comes to mind is the Debian mirror network and that is something of a historical fluke, predating centralized hosting being possible, and scoped to a much smaller set of more trusted participants. That also hits the big problem that even with a fair amount of infrastructure backing it, it’s hard to match the user experience of something like Github or NPM so the most likely case is spending a lot of time in hard problems but not overcoming the basic economics, as seems to be happening to IPFS.
- PureParadigm 7y ago
  Thanks for your insight. I think those are definitely real challenges to a fully decentralized system, but allowing some sort of federation can't hurt. The worst case scenario would be if GitHub is the only one pinning all the packages, which is what we would have now. It'd be nice to at least have the option to mirror in a way that interops with an open protocol so it would still work if GitHub went down. I doubt many mirrors would pin the entirety like GitHub, but I know I would certainly be happy to mirror my own and any open source software I've used.
- momack2 7y ago
  I hear those concerns, but I think there are clear ways to use decentralization to provide real benefit without running afoul of the issues you describe. For example, you can simply cache the packages you/your team are interested in locally, or on a shared local server for your entire office to use - which gives you fast p2p transfers, offline resiliency, and avoids serving any evil BLOBs or running into giant perf issues by trying to mirror and serve the entire registry. That's the way npm-on-ipfs (https://github.com/ipfs-shipyard/npm-on-ipfs https://github.com/ipfs-shipyard/npm-on-ipfs) works - more details in this WIP blog entry https://github.com/ipfs/blog/pull/215/files?short_path=90aba38#diff-90aba38720a2fd346011d141e660c59f https://github.com/ipfs/blog/pull/215/files?short_path=90aba... ;)
  - acdha 7y ago
    A local cache helps with performance issues but you still need to get it from somewhere, which means you’re still hoping someone else has dealt with those issues, not to mention the cost of maintaining a high-quality robust local server. I’ve seen this cycle with Linux distributions, Java, and Python packages (arguably even Git), and several digital preservation systems (I work at a library so this is a popular topic) and each time there either ended up being strong user demand to switch to the performance/stability/consistency of a centralized service, that happening de-facto with one or two big players doing most of the work, or falling apart because the contributed resources were insufficient. Getting the incentives aligned for something like this is really tricky.
nkkollaw 7y ago
It would be nice to use more companies but I suspect if people ran their own Git instances there would be a lot more outages.

deleted 7y ago

[deleted]

ilaksh 7y ago

There have been a few decentralized GitHub projects, but they've been largely ignored by developers. For example gittorrent or axic/mango or gitchain. When I have tried to promote them I've been downvoted. It seems pretty strange to me.

acdha 7y ago

The problem is that hosting and bandwidth aren’t free and abuse is a big problem. Managing a distributed petabyte-scale archive which gets updated so frequently is a significant engineering problem even for a single party — now consider how you’d handle redundancy and routing when you can’t rely on any of the parties involved, and you have enough different objects being accessed to turn away most participants unless you can guarantee that participating won’t blow your ISPs data caps, interfere with other use, etc. Abuse is the other huge problem: think about what happens when you’re hosting some BLOBs and the FBI shows up at your door because someone uploaded some kind of contraband and some of it was available from your IP address. How many people are going to setup completely independent hosting accounts to avoid fallout from something like that which happens so regularly? The closest thing which comes to mind is the Debian mirror network and that is something of a historical fluke, predating centralized hosting being possible, and scoped to a much smaller set of more trusted participants. That also hits the big problem that even with a fair amount of infrastructure backing it, it’s hard to match the user experience of something like Github or NPM so the most likely case is spending a lot of time in hard problems but not overcoming the basic economics, as seems to be happening to IPFS.

PureParadigm 7y ago
Thanks for your insight. I think those are definitely real challenges to a fully decentralized system, but allowing some sort of federation can't hurt. The worst case scenario would be if GitHub is the only one pinning all the packages, which is what we would have now. It'd be nice to at least have the option to mirror in a way that interops with an open protocol so it would still work if GitHub went down. I doubt many mirrors would pin the entirety like GitHub, but I know I would certainly be happy to mirror my own and any open source software I've used.
momack2 7y ago
I hear those concerns, but I think there are clear ways to use decentralization to provide real benefit without running afoul of the issues you describe. For example, you can simply cache the packages you/your team are interested in locally, or on a shared local server for your entire office to use - which gives you fast p2p transfers, offline resiliency, and avoids serving any evil BLOBs or running into giant perf issues by trying to mirror and serve the entire registry. That's the way npm-on-ipfs (https://github.com/ipfs-shipyard/npm-on-ipfs https://github.com/ipfs-shipyard/npm-on-ipfs) works - more details in this WIP blog entry https://github.com/ipfs/blog/pull/215/files?short_path=90aba38#diff-90aba38720a2fd346011d141e660c59f https://github.com/ipfs/blog/pull/215/files?short_path=90aba... ;)
- acdha 7y ago
  A local cache helps with performance issues but you still need to get it from somewhere, which means you’re still hoping someone else has dealt with those issues, not to mention the cost of maintaining a high-quality robust local server. I’ve seen this cycle with Linux distributions, Java, and Python packages (arguably even Git), and several digital preservation systems (I work at a library so this is a popular topic) and each time there either ended up being strong user demand to switch to the performance/stability/consistency of a centralized service, that happening de-facto with one or two big players doing most of the work, or falling apart because the contributed resources were insufficient. Getting the incentives aligned for something like this is really tricky.

nkkollaw 7y ago

It would be nice to use more companies but I suspect if people ran their own Git instances there would be a lot more outages.