5 ms·

> a module should live on, for as long as people are seeding the module and using it. More popular modules will be seeded by more people, making it faster to do

> a module should live on, for as long as people are seeding the module and using it. More popular modules will be seeded by more people, making it faster to download. So if you happen to use an unpopular module, or if your project ages, it's quite possible to literally lose your dependency. Package management that is built like this is almost useless. There has to be a central node of some kind.

icebraining 11y ago
Or you can just seed it yourself. Or pay someone else do it. Say you and others believe a full archive is needed to prevent that kind of problems. You set it up any way you would a centralized node, except it isn't centralized, it's jut another node in the network. Decentralization has some disadvantages, but in terms of availability, I don't see how it can be anything else than strictly superior.
- nileshtrivedi 11y ago
  Yes. This is exactly what the current centralized package repo does: seeding of data. With decentralization, anyone can do it instead of one single entity.
- rmsaksida 11y ago
  I agree of course that a decentralized system is technically superior to a centralized one. It must be, because as you pointed out, strong consensus in the network about a particular node makes it indistinguishable from a 'central' node in a centralized system. However, when it comes to package management I think we should look at the community first, technology second. The first concern is to set up a central node that everyone can safely mirror and is pretty much guaranteed to be there. Otherwise, what's the point? If I can't trust a package repository to store a package for a decade or so, why even use one? What's lovely about CPAN and friends is that they are reliable. They're always there. Of course I can just host a node myself for the next 10 years, but that doesn't make everythingstays a good alternative to npm. If all we're doing is decentralizing packages with the assumption that people will host their own stuff, this could be implemented with BitTorrent plus a text file containing magnet links.
  - vinnymac 11y ago
    Others in this thread mention WebTorrents specifically, and it is true, we could use torrents to solve these problems. What benefits could that provide over IPFS or npm? Does the money that backs npm or a CDN legitimize their ability to last a decade?
  - fiatjaf 11y ago
    You are already hosting your own dependencies, man. "Community first, technology second"? Do you mean this project only exists to use a cool technology and doesn't care about community? This thing here exists to try to solve a NPM problem. It is community first.
diggan 11y ago
No, the whole point is to not have a central node. However, it is possible that NPM Inc decides in the future to seed all public packages, but not being able to remove ownership of the packages. Or another private company might come along and do that. If you use an unpopular module, and you want it to exist, you better seed it, somehow. The es-cli will help with this in the future, allowing you to spread your module across public and private nodes.

icebraining 11y ago

Or you can just seed it yourself. Or pay someone else do it. Say you and others believe a full archive is needed to prevent that kind of problems. You set it up any way you would a centralized node, except it isn't centralized, it's jut another node in the network. Decentralization has some disadvantages, but in terms of availability, I don't see how it can be anything else than strictly superior.

nileshtrivedi 11y ago
Yes. This is exactly what the current centralized package repo does: seeding of data. With decentralization, anyone can do it instead of one single entity.
rmsaksida 11y ago
I agree of course that a decentralized system is technically superior to a centralized one. It must be, because as you pointed out, strong consensus in the network about a particular node makes it indistinguishable from a 'central' node in a centralized system. However, when it comes to package management I think we should look at the community first, technology second. The first concern is to set up a central node that everyone can safely mirror and is pretty much guaranteed to be there. Otherwise, what's the point? If I can't trust a package repository to store a package for a decade or so, why even use one? What's lovely about CPAN and friends is that they are reliable. They're always there. Of course I can just host a node myself for the next 10 years, but that doesn't make everythingstays a good alternative to npm. If all we're doing is decentralizing packages with the assumption that people will host their own stuff, this could be implemented with BitTorrent plus a text file containing magnet links.
- vinnymac 11y ago
  Others in this thread mention WebTorrents specifically, and it is true, we could use torrents to solve these problems. What benefits could that provide over IPFS or npm? Does the money that backs npm or a CDN legitimize their ability to last a decade?
- fiatjaf 11y ago
  You are already hosting your own dependencies, man. "Community first, technology second"? Do you mean this project only exists to use a cool technology and doesn't care about community? This thing here exists to try to solve a NPM problem. It is community first.

diggan 11y ago

No, the whole point is to not have a central node. However, it is possible that NPM Inc decides in the future to seed all public packages, but not being able to remove ownership of the packages. Or another private company might come along and do that. If you use an unpopular module, and you want it to exist, you better seed it, somehow. The es-cli will help with this in the future, allowing you to spread your module across public and private nodes.