Hacker News new | past | comments | ask | show | jobs | submit login

¿Por qué no los dos?

How is it "doubling down", they could exist side by side. Your comment kind-of shows the mentality I've seen with the IPFS project before. The IPFS project has doubled down on it's effort of being more "advanced", "innovative" and "efficient" than BitTorrent, losing what actually makes people like torrents and distributed systems.

Unfortunately right now the IPFS project is totally ignoring that it's effectively nothing and takes nothing to the next level. I think what I mentioned before, is the root cause. Zero ounce of compatibility with the existing BT swarm. It is simply a massive amount of wasted potential to ignore the thousands of terabytes of content the torrent system hosts, the work and services provided and spent for the ecosystem. So much could be done that would strengthen both systems at the same time. Just from the IPFS point of view we could right now have embedded resources from torrents, tens of different clients available that could just be CDNs, existing seedboxes strengthening both swarms and probably much more.

That would be the mix of torrents and web people want, not what IPFS is currently. IPFS is basically reinventing the wheel, but throwing out the round part.

Maybe the IPFS project should channel more work on building next to giants rather than doubling down and throwing away everything BT has to offer?




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).


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.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: