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.
>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
BitTorrent v2 would in theory be able to seed individual files even if they come from a different torrent. But clients have no reasonable way to look for other versions of a torrent that contain a file they already have.
The main Bittorrent clients already support creating and seeding v2 torrent. But there's just no infrastructure for seeding at the individual file level.
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.
