Actually, I really like GetRight's idea. Although the existing spec is not clear on how multi-file torrents should be handled, it would be a simple matter to extend it to allow them. As I see it, there are two ways that it could be extended: 1) Multi-file torrents would have URLs for each file available in the "url-list", and these would be matched to the file downloading based off of the filename. When the Bittorrent client wishes to use an HTTP seed for file XXXXyyyy.zzz, it checks in the "url-list" for a file with that name. 2) The "url-list" in a multi-file torrent would contain the URL to the parent directory where files are contained. If a piece is wanted from an HTTP seed, the file's name is simply concatenated to the end of one of the directories in the url-list. The first is a lot more flexible for file location, since not all the files have to exist at the same path (or even on the same server!), though suffers from the fact that no two files may have the same name. The second is stricter in where files may exist (the directory structure of the downloaded torrent must be mirrored on the HTTP server), but files can have identical names because of this. Both suffer from the fact that filenames (and directories as well for the 2nd method) contained on the servers MUST match those being served via HTTP. The BitTornado spec is a lot less problematic in one sense, since it does not suffer from the filename problem, but more restrictive as HTTP servers require additional software to be of any use to the BitTorrent community. Personally, I'd love to see either implemented, though if given a choice I'd prefer an extension to the GetRight method since the filename problem isn't all that huge, and there are (and likely always will be) more HTTP servers without a BitTorrent frontend. JigPu