The primary difference I see here is that IPFS is rather centralized in terms of development, it is much much easier for them to write a BT compat layer of some

The primary difference I see here is that IPFS is rather centralized in terms of development, it is much much easier for them to write a BT compat layer of some sort than it is for the BT community. A core set of BT is really rather ossified thanks to the amount of implementations out there. Just as an example there are quite a few BEPs out there that implement some features that IPFS has, unfortunately those features haven't gotten any mainstream adoption so far. > That said, the core and pretty fundamental limitation with BitTorrent, however, is that the swarms exist "per torrent", which kind of makes a non-starter for a general purpose filesystem? Well, ipfs nodes also tend to pin only certain content. I've seen IPFS links stop working mentioned here on HN even. I see no functional difference in that sense. Content is kept available by those willing to spend resources storing and uploading the specific content. To address the claimed performance/efficiency problems, IPFS peers could share the same files using IPFS itself, but still also seed them for BT clients. I totally get though that it wouldn't be super easy to implement, but IMHO the increase in IPFS usefulness, size and resiliency thanks to the integration seems to outweigh the downsides I can see. Though a while ago I did try sharing the same set of files on two systems by running the two in parallel. It kind-of worked but manually updating the file locations in the torrent client and having an overview became too annoying, it should be built-in. E.g. IPFS sees `x.torrent` and `x`, then assumes `x` is downloadable from BT using that torrent file. > WebTorrent is the future of BitTorrent as far as I'm concerned, and anything failing to embrace that is already kind of doomed? In some use-cases, absolutely.