3 ms·
To be clear, I am not involved in the IPFS project and in fact don't like key aspects of the project and think it is doomed to long-term failure when it gets re
by saurik 6y ago
To be clear, I am not involved in the IPFS project and in fact don't like key aspects of the project and think it is doomed to long-term failure when it gets replaced by something better.
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?
As such, I don't quite disagree with what you'd like to see done, but that work should go in IPFS... like, trying to extend the way BitTorrent works "up" to something that works for this use case is going to involve a much more fundamental set of low-level changes than even the WebTorrent shift (which is where I'd argue "if only BitTorrent understood the value of working with existing browser-based systems and opening up powerful use cases they would understand that not doing this is like throwing away the round part of a wheel... etc." ;P WebTorrent is the future of BitTorrent as far as I'm concerned, and anything failing to embrace that is already kind of doomed?...) than the other direction, which is really just "go into IPFS and add a little adapter that lets it work with torrent files (at the fundamental loss of efficiency and awkward lack of resource sharing that such usage implies).
- Avamander 6y agoThe 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.