Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pataquets opened this issue Sep 10, 2022 · 2 comments

Comments

@pataquets
Copy link
Contributor

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
Copy link
Owner

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants