It's already on BitTorrent. IPFS doesn't do much BitTorrent doesn't already, most of it is a new coat of paint and making the same mistakes BitTorrent figured out years ago.
It does one thing BitTorrent doesn't — you can compose a new CAR file by combining a few new chunks with a bunch of existing chunks. So you don't get the problem where releasing a new version of an archive means nobody's seeding it; and anyone moving over to seeding the new version stops seeding the old version. Instead, the new file is already pre-seeded by all the old version's seeders on all but the new chunks (because they're seeding the chunks, not the file); and the old file stays seeded as the seeders find the new version and seed its blocks too.
Really, BitTorrent could do this by making all torrent files a small fixed size and then having "torrent files of a directory of torrent files" where the torrent client knows to queue the sub-torrents as they're discovered+downloaded in the parent torrent. But that's not how any part of the ecosystem works. IPFS is a "do over" that allowed them to fix this.
One major benefit of IPFS is that people seeding individual works and people seeding the large archive groups can share data. It seems that these torrents are blocks of data that aren't of direct use.
That being said while the IPFS protocol is decent the implementations kind of suck. Bittorrent is well established with many high quality implementations.
treyd|1 year ago
derefr|1 year ago
Really, BitTorrent could do this by making all torrent files a small fixed size and then having "torrent files of a directory of torrent files" where the torrent client knows to queue the sub-torrents as they're discovered+downloaded in the parent torrent. But that's not how any part of the ecosystem works. IPFS is a "do over" that allowed them to fix this.
kevincox|1 year ago
That being said while the IPFS protocol is decent the implementations kind of suck. Bittorrent is well established with many high quality implementations.