Opened 18 months ago

Last modified 16 months ago

#2110 new enhancement

Decentralize torrent delivery by implementing tracker and http server in I2PSnark

Reported by: Reportage Owned by: zzz
Priority: minor Milestone: undecided
Component: apps/i2psnark Version: 0.9.32
Keywords: i2psnark, integration, tracker, webserver Cc:
Parent Tickets:

Description

Currently, loss of standard tracker sites will result in a huge loss of available torrent content on I2P. In order to mitigate this, mechanisms that decentralize torrent delivery might be considered. https://www.klomp.org/snark/ notes that a built-in tracker and micro http server were originally present in their bittorrent implementation, and seem like possible candidates for adding to I2PSnark's functionality, at least in terms of the concepts if not the implementation. Other drop-in solutions might be considered.

  • Reinstate tracker option originally present in klomp's snark implementation to allow I2PSnark to optionally function as a tracker, and if enabled advertise this to other connected peers to create a meshed tracker network
  • Reinstate http server option originally present in klomp's snark to allow I2PSnark to optionally serve selected torrents available in I2PSnark's torrent listing from a b32 or i2p hostname, and if enabled advertise this to other connected peers

The ability to serve selected torrents within I2PSnark would simplify the distribution of torrents. Further down the line, the ability to tag and add info to torrents within I2PSnark could be the basis for automated syncing/uploading of torrents and meta info to standard i2p trackers, further enhancing the bullet-proof torrent scene on I2P.

Subtickets (add)

Change History (4)

comment:1 Changed 18 months ago by zzz

  • Status changed from new to infoneeded_new

What you don't mention, and it isn't clear if you've considered, is the combined effect of our magnet/DHT support, default and backup opentrackers, and the Vuze/BiglyBT bridging of clearnet torrents. Every client _is_ a tracker, in the DHT. We have seen trackers come and go over the years and it hasn't been a disaster. We remove and add services from the hardcoded list all the time, and we provide a configuration form for users to add and delete.

By "standard" trackers I presume you mean non-open trackers? Users rely much less on these than you might think, due to our robust DHT and magnet support, and people looking for torrents that aren't listed on those sites anyway.

It isn't clear if you are proposing some new protocol for "meshed tracker networks" and a method to "advertise http servers to other peers", or if there's some existing BT protocol extension to do this (provide links), or if you haven't gotten that far. Protocols already implemented by Vuze/BiglyBT are preferred. Please elaborate.

comment:2 Changed 18 months ago by Reportage

  • Status changed from infoneeded_new to new

Thinking about it more, this is a parallel proposal to #2083 which suggests exposing the DHT space to searches. If a search can return results from DHT, this would bypass the need for a per-client http server to host available torrents. And as you rightly point out, by virtue of DHT every client is effectively a tracker, so leveraging this for better effect by exposing shared content is really the nub of the proposal.

In regard to Bigly, there are a couple of promising features that seem to cover most of the bases here:

Overlaying search onto the DHT space and then parsing the resulting hashes in I2PSnark with a simple
point-click UI to download selected content would address most of the proposal, and the option to publish a list of publicly shared torrents to other clients for review in I2PSnark would probably cover the rest. These lists could then be accessed with a custom search query e.g. shared.xml which then presents them in the same format as per the DHT search.

comment:3 Changed 16 months ago by Reportage

For inspiration, https://www.tribler.org/ builds on the bittorrent protocol and implements a serverless search mechanism for torrent discovery, onion-routing for torrent propagation, and a cogent UI for managing the results.

There's also an android port:

Another tribler feature that would be useful in I2PSnark is the ability to view torrents by status:
All / Downloading / Completed / Seeding / Active / Inactive

comment:4 Changed 16 months ago by zzz

I looked at DHT search including Cubit and Tribler a few years back, see http://zzz.i2p/topics/831

It also comes up periodically in the Vuze discussion threads, where they support, or used to, various search plugins.

Outside of BT, we also implemented a search form in the console that would redirect to various in-net search engines, but we never enabled it.

Next time I talk to the BiglyBT guys I'll ask them for advice.

Note: See TracTickets for help on using tickets.