I don't have much time tonight so I will simply post this code I have been working on, it is quite self expanatory (but i will still explain it a bit). The idea here is that a webmaster can post one link and all of the filesharing networks can support it and get that file, which makes legitimate file transfer a reality on Gnutella and other networks.

Here you have the note that this is a file, next you have the filename (which can be one of the items searched for if there is no 'Search by Hash' implimented), next you have the size (which will help you confirm your searches by filename if that is what the network is using to find files), and after that you have the bitprint hash. The only real required hash is the Sha1, with the .tigertree optional (but still included in the spec). Next you have variables that contain the locations of files on these networks and on the internet, and there can be more than one variable for one network (so you can have "gnutella="ipaddressORURLA",gnutella="ipaddressORU RLB",gnutella="ipaddressORURLC",etc"). Note that if there is a HTTP or FTP URL that those should be the last places to attempt to download the file from (and should only be used as a last resort). Next you have basic information about the file, which can include bitrate and artist for MP3, and legenth and codec for movies.


Next we have the link that will let you connect to a server. The first IPaddress or URL is the one that gets connected to first, and the rest of them are there and should be done in order.

Next we have the code for Packages. This is a nice way to keep a distribution together and makes it easier to find sources for an entire distribution. A good example of this is if you released a 2 part movie, both parts could be distributed individually or in a package, and if you download the package there are more sources to find (this works especially well in a Mesh-network design with partial file sharing). This is basically like the single file sharing protocol, only there is more information to be told here (and in all actuiality most of the additonal information IS NOT required).


Impliment this and all of a sudden there will be more content and more organisation on the network (and possibly less searches returning a ton of results).

If you know anyone who works on EDonkey or WinMX, direct him/her over to this forum after a few comments are posted.

It's rough, so talk about it...

__________________
- Nick Catalano

This is a good idea -- and I've been working on something similar myself.

To really do it right, the various conventions outlined in internet RFCs about URLs and URIs ("Universal Resource Identifiers", of which URLs can be considered one type) should be followed, about structure and legal characters.

See for example RFCs 1738 ("URLs") and 2396 ("URI Generic Syntax").

This would guarantee such URIs could be handled by all code that follows these conventions, and avoid potential encoding (etc) problems that motivated the formal designs in the first place.

FYI, ed2k URIs do a number of things that aren't quite kosher by IETF/W3C standards.

In particular, the "//" at the start of a URI is only for schemes which have a natural (usually but not always DNS-related) hierarchy.) '|' is not a legal character to appear, unescaped, in URIs, although lots of software tolerates almost anything in a URI.

Please email me privately if you'd like to trade some ideas about this kind of facility...