3 ms·
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 ex
by 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 agoA 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.