1. 51
  1.  

  2. 4

    It means that fundamentally a v2 torrent will be identified by a different hash than a v1 torrent, which would always create a separate swarm, even when sharing the same files

    The “different swarms for the same data” problem has always plagued BitTorrent and this certainly doesn’t improve matters.

    Just upgrade to IPFS, already.

    1. 6

      Just upgrade to IPFS, already.

      Huh? IPFS is totally broken, why would anyone do this?

      1. 9

        Could you explain for an outstander how/why is it broken ?

        1. 2

          I wouldn’t go as far as to say “broken”, I’d stop at non-functional.

          I can get an Ubuntu image via BT from their website: https://ubuntu.com/download/alternative-downloads

          The only hit I get for an Ubuntu image on IPFS is via a 2-year old Reddit post: https://www.reddit.com/r/Ubuntu/comments/8f8v1n/download_ubuntu_1804_lts_via_ipfs/

          (I’m using Linux images as a proxy for the stuff people usually want to access via BT)

          1. 2

            What? That… has nothing to do with functional or not. That just means no one is hosting Ubuntu images on IPFS. Things people are hosting work just fine.

            1. 6

              Say I want to find something on IPFS. How do I do that?

              The first hit on Google is https://ipfs-search.com/#/search which currently returns “Could not fetch results from the backend. Please try again later.” for every query.

              I remember BitTorrent taking off - it was instantly popular, with clients and trackers proliferating overnight. There’s a thriving mini-industry providing seedboxes. I don’t see any of that energy around IPFS.

              1. 2

                Give this a try: https://www.ipse.io/search?wd=ubuntu-20.04.1-live-server-amd64.iso

                There’s no “google of ipfs” (or thepiratebay for that matter). Just a few randos running some indexers and servers. ipfs-search is open source if you’d like to help track down the bug why the server errors out on “ubuntu”: https://github.com/ipfs-search/ipfs-search

                But yea, the popularity rush of p2p sharing apps since the early 2000’s does not compare to the relatively luke warm burn of IPFS. It is really cool tech, though.

                1. 2

                  I expect that’s because Bittorrent was revolutionary, where IPFS is incremental. A lot of people consider bittorrent “good enough” and for some use cases it probably is.

                  Lack of adoption doesn’t hurt IPFS for any particular use case though. I can push out my content on IPFS and get al the benefits already today. Coexisting with Bittorrent is just fine.

                  1. 2

                    I mean, you literally can’t, right? IPFS is so sparsely used that it’s effectively not possible to retrieve content unless you ensure the hosting infrastructure yourself. At which point…

                    1. 1

                      That’s not less true with BitTorrent. The swarm helps share the load during spikes, but unless/until your content has already been downloaded a lot or you have a lot of volunteers you still need to seed the content also. I am the only consistent seeder for 100% of my torrents

                2. 1

                  That’s the broken part.

          2. 5

            I’m not too familiar with IPFS and one thing I didn’t get from this is if two peers on BitTorrent V2 downloading the same file from different torrents would automatically share pieces. (I’m guessing yes?)

            If everyone upgrades to BitTorrent V2 and that removes the split swarm issue, does IPFS have other advantages for BitTorrent’s most common use case of occasional high bandwidth downloads?

            1. 1

              If they will share pieces it’s certainly closer to IPFS, though the article only implied to me that might have an easier time finding dupe swarms, not that autosharing will happen.

              Other advantages of IPFS for this use case would include replacing the complex “http mirror” system used by, eg, linux ditros with mirrors just running IPFS nodes with big caches. Thus your cdn/mirror network gets new data automatically and shares in the swarm as well as powering http downloads

          3. 1

            I wonder if v2 will make it any easier for folks to torrent over NAT and/or VPN connections.

            1. 2

              No, the spec makes it pretty clear that nothing about the network topology will change.

              However, if you haven’t checked with bittorrent in awhile, you should try again. μTP significantly improved the ability to bypass NAT and firewall. Nowadays, CGNAT is really the only big problem for anyone trying to get incoming connections.

              Technically, μTP and bittorrent v2 are completely orthogonal. However, I expect that the only bittorrent client that implements BitTorrent v2 without also implementing μTP will be WebTorrent.

            2. -1

              When this will be rewritten in Rust?