I'm afraid that I don't understand what you mean in terms of auto-searching drains the network. Does Limewire currently only use the IP address specified by the xs attribute in the magnet link, and ignore xt altogether intentionally because using it would cause more traffic? Or do you mean that it intentionally processes the magnet link (and handles the xt info properly) and shows the file name in the download area, but doesn't actually start the download until the users clicks on "Find More Sources". That is, do you mean that enabling someone to click on a magnet link on a Web page to have Limewire search/download automatically based on the xt urn:sha1 part of the magnet is intentionally not fully implemented by Limewire and that human intervention (clicking on "Find More Sources") is intentionally required because that that extra step somehow puts less strain on the Gnutella network?

In any case, why would searching for files automatically via magnet links be any worse than the manual searching that we do now (i.e, typing in search terms)? Tons of traffic, both searching and downloads, are the result of people trying to find specific files that aren't easily identified on the network (and so trial/error to find them ensues).

A magnet link may require more hops to find the exact file since using the xt=urn:sha1 information forces a search for a precise file, but that shouldn't cause a great deal of traffic since large lists of "possible matches" don't need to be returned for vague search terms -- only when an exact match is found does a download start, otherwise return results should be ignored (or, ideally, not returned at all if an exact match isn't found for a specific sha1 hash). Perhaps Gnutella doesn't support searching for an exact file?

I would think that being more precise by specifying the exact file to download would be better for network traffic overall because users could then find exactly the files they want faster and with less searching than if using the usual keyword (manual) approach. The download traffic, in particular, should be much less: with precise magnet links I could get exactly the file specified by the magnet, whereas with a manual search I have to type in keywords and start the search, download potential matches from a large list of files that's displayed, and then preview a lot of files as they download to see if I got what I wanted. Most of the time I have to repeat this process over and over until I get what I want, meaning I generate a lot of traffic (both for search terms and downloaded files that are aborted after preview, or download entirely then deleted upon realizing they're not what I want). A good implementation of magnet links could eliminate a lot of wasted searching and downloads, which in turn would save a lot of bandwidth.

Is there some history on the auto-search problem that I can look at to get a better context for the reason Limewire doesn't support it?

Aaron