I guess you don't like this idea :) Metalink sounds like a useful protocol though, and upon further reading it seems it handles the other p2p protocols I asked for. I suppose the only downside to it is that you need certain browser plugins or programs to download with, but as an option it would be useful.

It looks cool, but it's pretty specific, unlikely to be covered in a client project or a development priority.

Reclassifying specifically for downloads addon. If wanted for stuff within Comcode, you could link to a download entry easily enough. It wouldn't make sense to upload torrents within the attachment/media systems, that is designed to be simpler than that, and not for large files anyway.

Ok, so I think what we're saying is we add a couple of extra HTTP headers...

Link: <http://example.com/example.ext.torrent>; rel=describedby; type="application/x-bittorrent"
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlODYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==

We'd need to add a .torrent upload field to the download add/edit form. If the torrent was provided, these headers would be provided by dload.php.

I don't think the linking to web mirrors or PGP stuff or the other stuff within the metalink file is interesting. Correct me if I'm wrong. It seems to me that the real/only use case here is to promote downloading via torrent, rather than via-site.

All this said, why not just upload a .torrent directly? Is there really much space in between the use cases of "small download, don't care about bandwidth" and "big download but I'll let people not bother installing bittorrent unless they choose to"?

I think most people who care about bandwidth would want to force .torrent use.

Not in a position to correct you, just upon reading the webpage it sounded useful and I noticed a lot of Open Source projects were utilising it. Go with your conclusion which is good enough for what I would require. Although torrent files are on the decrease and magnet links are on the up. Either way, your conclusion sounds good to me.

Okay, so I just looked over this again and am a bit confused about the use cases.

I know magnet URIs have some advantages:
1) Legal firewall for the site hosting them, as they are just hosting a URI, not a load of metadata that implies a higher legal burden
2) Avoids having to mess about downloading and then deleting a .torrent to get it into a Torrent application
3) Does not rely on a particular tracker to download a Torrent file (uses DHT, just needs to know any node on the DHT network to start)

I haven't tested, but I would think you could already put in a magnet URI when adding a download.

As for Metalink, I'm not sure what the feature is. Can't you already upload a .metalink file as a download? You'd then need some system software to then handle that. What's Composr's special role? Or are we saying we want Composr to inspect the metalink file, and somehow show all the download options from it? What's the advantage of this over having custom fields that specify the different download locations?

From Wikipedia (rather than my confusing interpretation):-

"Metalink is an extensible metadata file format that describes one or more computer files available for download. It specifies files appropriate for the user's language and operating system; facilitates file verification and recovery from data corruption; and lists alternate download sources (mirror URIs). The metadata is encoded in HTTP header fields and/or in an XML file with extension .meta4 or .metalink. The duplicate download locations provide reliability in case one method fails. Some clients also achieve faster download speeds by allowing different chunks/segments of each file to be downloaded from multiple resources at the same time (segmented downloading). Metalink supports listing multiple partial and full file hashes along with PGP signatures. Most clients only support verifying MD5, SHA-1, and SHA-256, however. Besides FTP and HTTP mirror locations and rsync, it also supports listing the P2P methods BitTorrent, ed2k, magnet link or any other that uses a URI."

I just thought this might be useful, perhaps by giving a list of download options (which perhaps could be created from a multi url list). It sounded interesting, especially for sites with large files to share, not sure if it's something Composr needs particularly especially if these protocols are already allowed in the download source field (in which case I don't know why I would be mentioning magnet URI's). I will try some experiments and report back.