It solves some things that have an overlap with torrent 2. If you're interested only in single files, or collections of files which change but remain 99% the same, then ipfs is great and doesn't really have a widespread alternative right now.
Changing collections of files, not changing files. Let's say you have a collection of 1000 books. You get two more and publish a collection of 1002 books. With torrent, you'd have a completely separate download. With ipfs all previous users can now share the existing files as part of the new collection without doing anything special.
> With torrent, you'd have a completely separate download
That sounds more like a limitation of your bittorrent implementation. You think seeders have dozens of identical copies of each release hanging around on their drives just to be able to share it on separate trackers through separate torrents? :p
Or is there some new feature in IPFS that's an actual differentiator here? It's been a while since I was fully up to date on protocol development.
I don't think you understood the issue. Maybe read it again, or check the change in BitTorrent v2 which provides something similar as per-file trees https://blog.libtorrent.org/2020/09/bittorrent-v2/ (v2 support in clients in the wild is still very low though)
That was a bit tounge-in-cheek, cheers for complementing. Just to clarify, I think its fair to consider v2 if comparing with IPFS (which doesn't really have a large number of mature implementations either).
> BitTorrent v2 not only uses a hash tree, but it forms a hash tree for every file in the torrent. This has a few advantages:
> Identical files will always have the same hash and can more easily be moved from one torrent to another (when creating torrents) without having to re-hash anything. Files that are identical can also more easily be identified across different swarms, since their root hash only depends on the content of the file.
So I guess the question stands, how is IPFS supposedly the preferred protocol over Bittorrent (v2)?
Technically you can do the same thing for the transfer itself in v2. The preference may be for ergonomics where BT requires something like "download this file, from package with this hash, ask these hosts about it", while ipfs is more "yo all, who's got this hash".
You could make the experience similar though if you really wanted. So in theory, no difference. In practice, ipfs solved this years ago, has a nicer interface to it and put updateable naming on top for convenience.
It depends a little on how you arrange those files, but with UnixFS (the standard way to arrange them?) the files contents are arranged into a merkle DAG, so any shared files (and indeed chunks thereof) between the two versions would remain the same and thus still be ‘seedable’ by the parties that have it. It’s similar to BitTorrent in that regard.
The root of content would get a new content address, but all the identical data below it in the merkle DAG would have the same content address as before
