3 ms·

There already is Bittorrent. The distros are getting distributed over Bittorrent and since more people have it and know how to use it than IPFS, there is no po

There already is Bittorrent. The distros are getting distributed over Bittorrent and since more people have it and know how to use it than IPFS, there is no point in distributing it over IPFS.

Jtsummers 9y ago
As a host, though, there's little reason not to offer both. It offers the same benefits as bittorrent but a slightly different network, and also canonical domain names using IPNS which would be a nice addition for hosting their content.
fiatjaf 9y ago
Not the same use-case. Today you have mirrors, tomorrow you could have multiple IPFS gateways, which would just take a hash and return a file. Besides that, IPFS could be used to fill the BitTorrent niche -- so it would replace both mirrors and BitTorrent. It's easier to use than BitTorrent and less frightening too.
- iforgotpassword 9y ago
  If its easier to use than bittorrent then piracy people will switch over too and soon the name sounds just as frightening. The problem with bittorrent wrt popularizing legal use was that browsers should have shipped with BT support, the experience would have been just like clicking a traditional download link.
  - edraferi 9y ago
    Yeah, browser integration is critical. That’s why IPFS has focused on the JS implementation. One nuance - these p2p protocols are not as simple as HTTP, FTP, etc. They require persistent connections to many peers and significant local storage. This eats up more local resources, to the point where making in default-on might cause significant performance hit.
  - cocktailpeanuts 9y ago
    There already is webtorrent https://github.com/webtorrent/webtorrent https://github.com/webtorrent/webtorrent which is just a JS library that runs in all browsers. If you're talking about browsers acting as seed themselves, I don't think that model would get much traction, and the first thing people will do after downloading a browser is to disable that feature. Nobody wants to keep seeding. This is the #1 problem for BitTorrent, and most people only keep Torrent on while they're downloading, so they never want it running all the time. I think same goes with IPFS, which is why they came up with FileCoin, but if the mental cost of maintaining a node (because of all the copyright issues mentioned elsewhere on this thread) is higher than the actual profit each node makes, it will never take off. So in the end I think filecoin nodes will centralize just like Bitcoin nodes became centralized--that is, if they ever do end up launching what they promised--and when that happens it's AWS all over again, although the content addressable nature is indeed cool and I can imagine some cool applications coming out of it. It's just that I don't think it will replace HTTP altogether.
    - iforgotpassword 9y ago
      The JS approach is still more cumbersome than a normal download, which just asks for a destination right when you click the link (if at all, I think most browsers default to just starting to download to a default destination nowadays). As for seeding, that would just happen while the download is going as you suggest, maybe have that configurable somewhere for the tech savy people. That would already scale quite well compared to no uploading at all with the traditional approach. The more demand there is, the slower the download gets, the longer you'll be seeding.. That being said, that's what would have helped 15 years ago, nowadays I'd agree that we're doing pretty fine with the centralized approach in most use cases.
detaro 9y ago
IPFS has some benefits if I understand it correctly, e.g. I think it can share duplicate data between multiple trees, while Bittorrent can't share blocks between multiple torrents. Still understandable that distros with working infrastructure won't jump on every new thing.
- zaarn 9y ago
  I doubt there is much efficiency gain when most distro's compress the packages and ISO's anyway, the few bits you could spare would most likely fall towards the installer ISOs, which are always mostly the same. But since nobody cares about the old ones, there isn't much win other than getting a tiny bit more bandwidth from people who don't offer the newest version yet. There would also have to be a very high uptime guarantee, which means either every user of the distro operates a IPFS node by default, which nobody wants because IPFS is extremely chatty and there is such a thing as "servers in private subnets with limited internet access" that people don't want to send out arbitrary data to the internet. The next option would be opt-in, which means nobody will do it because everyone is lazy. Last option; simply maintain status quo.

There already is Bittorrent. The distros are getting distributed over Bittorrent and since more people have it and know how to use it than IPFS, there is no point in distributing it over IPFS.

Jtsummers 9y ago

As a host, though, there's little reason not to offer both. It offers the same benefits as bittorrent but a slightly different network, and also canonical domain names using IPNS which would be a nice addition for hosting their content.

fiatjaf 9y ago

Not the same use-case. Today you have mirrors, tomorrow you could have multiple IPFS gateways, which would just take a hash and return a file. Besides that, IPFS could be used to fill the BitTorrent niche -- so it would replace both mirrors and BitTorrent. It's easier to use than BitTorrent and less frightening too.

iforgotpassword 9y ago
If its easier to use than bittorrent then piracy people will switch over too and soon the name sounds just as frightening. The problem with bittorrent wrt popularizing legal use was that browsers should have shipped with BT support, the experience would have been just like clicking a traditional download link.
- edraferi 9y ago
  Yeah, browser integration is critical. That’s why IPFS has focused on the JS implementation. One nuance - these p2p protocols are not as simple as HTTP, FTP, etc. They require persistent connections to many peers and significant local storage. This eats up more local resources, to the point where making in default-on might cause significant performance hit.
- cocktailpeanuts 9y ago
  There already is webtorrent https://github.com/webtorrent/webtorrent https://github.com/webtorrent/webtorrent which is just a JS library that runs in all browsers. If you're talking about browsers acting as seed themselves, I don't think that model would get much traction, and the first thing people will do after downloading a browser is to disable that feature. Nobody wants to keep seeding. This is the #1 problem for BitTorrent, and most people only keep Torrent on while they're downloading, so they never want it running all the time. I think same goes with IPFS, which is why they came up with FileCoin, but if the mental cost of maintaining a node (because of all the copyright issues mentioned elsewhere on this thread) is higher than the actual profit each node makes, it will never take off. So in the end I think filecoin nodes will centralize just like Bitcoin nodes became centralized--that is, if they ever do end up launching what they promised--and when that happens it's AWS all over again, although the content addressable nature is indeed cool and I can imagine some cool applications coming out of it. It's just that I don't think it will replace HTTP altogether.
  - iforgotpassword 9y ago
    The JS approach is still more cumbersome than a normal download, which just asks for a destination right when you click the link (if at all, I think most browsers default to just starting to download to a default destination nowadays). As for seeding, that would just happen while the download is going as you suggest, maybe have that configurable somewhere for the tech savy people. That would already scale quite well compared to no uploading at all with the traditional approach. The more demand there is, the slower the download gets, the longer you'll be seeding.. That being said, that's what would have helped 15 years ago, nowadays I'd agree that we're doing pretty fine with the centralized approach in most use cases.

detaro 9y ago

IPFS has some benefits if I understand it correctly, e.g. I think it can share duplicate data between multiple trees, while Bittorrent can't share blocks between multiple torrents. Still understandable that distros with working infrastructure won't jump on every new thing.

zaarn 9y ago
I doubt there is much efficiency gain when most distro's compress the packages and ISO's anyway, the few bits you could spare would most likely fall towards the installer ISOs, which are always mostly the same. But since nobody cares about the old ones, there isn't much win other than getting a tiny bit more bandwidth from people who don't offer the newest version yet. There would also have to be a very high uptime guarantee, which means either every user of the distro operates a IPFS node by default, which nobody wants because IPFS is extremely chatty and there is such a thing as "servers in private subnets with limited internet access" that people don't want to send out arbitrary data to the internet. The next option would be opt-in, which means nobody will do it because everyone is lazy. Last option; simply maintain status quo.