WinPooh32/peerstohttp

Feature request: Append configurable fixed string to added magnet URIs (e.g. trackers)

Opened this issue · 2 comments

pataquets commented

Since trackers come and go and some magnet URIs don't even have trackers built-in, adding some well-known (or even private) trackers would speed up stream bootstrap and discovery.

This could be accomplished at add time by just automatically appending some fixed string passed at service start, containing some bootstraping, well-known trackers encoded in a URI parameter string. As you can't anticipate which URIs will need it and which trackers each user would find best, it would be a nice addition to let the user configure their own string with some sort of -magnetAddString &tr=... switch.

Notice I'm requesting a fixed generic string, which can be of use for adding trackers (which somewhat overlaps #22), but it might be used for other purposes, as long as it is kept generic enough. It could also be used to bootstrap the torrent from a well-known peer by adding a x.pe URI parameter, for instance (see BEP 9).

WinPooh32 commented

Generic string can break all new added magnets if user sets invalid string.

Why not to do this with safe parameters? For example:
-magnetAddTR=...
-magnetAddX.PE=...
-magnetAddWS=...

pataquets commented

Albeit I see the point in being more specific (thought about asking it some way along these lines), I leaned to a more generic approach because:

  • It would mean an easier to code feature.
  • Would be less complex to maintain.
  • Would accommodate other URI parameters and relieve the application on having to think every query option in advance, or adding ones as the URI standard evolves and...
  • ...which also means less cluttering in the command line switches (think of help screen).
  • As it is quite an "advanced user" feature, we could simply bail out with an error if some poisonous string is provided, and let the user figure it out. Just making sure the URI is fully printed for diagnosing would be enough, IMO. I was OK with this when asking, sine I found this behaviour completely acceptable.

I lean towards a generic string due to being more flexible and less effort (and also easier to ask for 😄).