Menu

#283 Better magnet link support

Future
open
nobody
None
5
2020-11-03
2020-11-02
David
No

New features i would like to have:
1- Support multiple files in the magnet link. A magnet link can contain several files. Example from the spec:
magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7

However gtkg doesn't seem to do anything with this :-(

2- Better support of the "dn" parameter of the magnet link.
I do a normal search, then i right click on a result and copy the magnet. Then from the magnet link i remove all the parameters except the "xt" and the "dn". I change the "dn" parameter value. After that i add it on gtkg.
There will be an entry in the download tab, but without any sources (0/0/0). It won't move from this state.

My suggestion would be to create a search with the dn as the label, but it would search for the sha1, instead of going directly to the downloads tab

Discussion

  • Raphael Manfredi

    GTKG's magnet parser does not recognize the xt.n syntax. I'm still wondering as to what it would do with various xt.n parameters knowing that it currently only supports the urn:sha1: ones.

    Also, what would it mean to have two urn:sha1: listed, especially if they are different... ?

    Conceivably, it would make sense to have xt.n recognized and it would make sense for a magnet to hold different hashes for different protocols, all in one magnet. But this is not what you are talking about here in your request.

    The part on dn+xt creating an entry in the search with the dn but really looking for the SHA1 is a good idea, although of course it would do both of these things at the same time. SHA1 are searched through the DHT (Distributed Hash Table) and file names through Gnutella queries. I confess I would have to look at the code to know exactly what happens today in that case and whether it works already as suggested here.

     
  • David

    David - 2020-11-03

    GTKG's magnet parser does not recognize the xt.n syntax. I'm still
    wondering as to what it would do with various xt.n parameters knowing
    that it currently only supports the urn:sha1: ones.

    Why not search for each urn:sha1 ?

    Conceivably, it would make sense to have xt.n recognized and it would
    make sense for a magnet to hold different hashes for different
    protocols, all in one magnet. But this is not what you are talking
    about here in your request.

    Correct, that's not what i'm referring to. Magnet links can support several files.

    xt also allows for a group setting. Multiple files can be included by
    adding a count number preceded by a dot (".") to each link parameter.

    magnet:?xt.1=[ URN of the first file]&xt.2=[ URN of the second file]

    From wikipedia: https://en.wikipedia.org/wiki/Magnet_URI_scheme

    I'm just realizing that this can open a can of worms....

    The part on dn+xt creating an entry in the search with the dn but really
    looking for the SHA1 is a good idea, although of course it would do
    both of these things at the same time. SHA1 are searched through the
    DHT (Distributed Hash Table) and file names through Gnutella queries.

    I like that :-)

    EDIT: removed the bitprint part

     

    Last edit: David 2020-11-04

Log in to post a comment.