Proposal: Reference file path in magnet link about bittorrent.org HOT 10 CLOSED

Creating a new scheme for hosting websites in torrents would be a reasonable thing to do. The scheme should support both directly naming an infohash and naming a public key which is resolved to an infohash via BEP46.

from bittorrent.org.

I'm not sure #92 supercedes this one, as it's still desirable to be able to link to files within torrents using the magnet URI scheme. #92 proposes an entirely new scheme.

from bittorrent.org.

As you note the URI specification only handles paths (and optionally authorities) immediately following the scheme:. Since the URN embedded in the query component of the magnet is not part of the path it does not benefit from any of the relative path resolution semantics of URIs, e.g. you can't actually have an <img uri="foo.jpg"> in such a document, which means you always need to use absolute URIs.
And if you're already using absolute URIs you can then use BEP53 and add the file name as one of the decorative magnet URI or URN components

from bittorrent.org.

as the author of the website, and (presumably) the generator of the .torrent file, you will now the index of all files. couldn't you just refer to the files as numbers, and just rely on BEP53?

Essentially I'm suggesting that it may be easier to write a transformation pass over your HTML, as part of building the site, that resolves paths into file indices.

from bittorrent.org.

@the8472 Would it maybe make sense to create a new protocol for this? Since magnet links aren't necessarily BitTorrent specific in the first place, maybe there should be an intermediate protocol type that's used when you actually load the website, and then have a way to convert that to magnet links for sharability.

@arvidn As I mentioned in this comment, I don't think that people necessarily will know the index of files in their torrent ahead of time.

The ideal use case would be that somebody builds up a static website which can be served from the local filesystem, upload it to BitTorrent without any additional processing, and share the magnet link with someone to have them download it.

Having an additional processing step would be possible, but it'd confuse newcomers and lead to a bad user experience compared to mentally modeling their site as some files in a folder. A use case I could see, taking from the Beaker Browser, would be somebody publishing some p2p web content, and another person "forking" their own copy of it which they can modify for their own purposes. If you have additional build steps before content gets published, you'd now need some way of converting the files back for better UX. Plus, you'd be limited by having to process all your content which would make it hard to use with dynamic things like CSS and JavaScript.

What if the browser intercepted magnet links, then converted them to something like bittorrent:identifier/optional/path.html where the hash is either the bith+infohash, or as per BEP 46 it could be btpk+public key hash for mutable torrents. This is similar to a proposal made in 2010 for a new bittorrent: protocol.

from bittorrent.org.

Alternately, maybe instead of a straight up magnet link, I should just use the URN portion from magnet links.

Have bith:infohash/optional/path and btpk:public key/optional/path. Then the browser can extract file paths from magnet links, and these URIs could easily be converted back to magnet links.

from bittorrent.org.

So, how crazy is the idea of creating new protocol types? I think it's more elegant for interfacing with browsers and preserves the "url path in a folder" semantics that are used in other protocols like HTTP.

from bittorrent.org.

Should I write up something more detailed and put it in a PR for a new BEP?

from bittorrent.org.

Yes, I think this would be a good subject for a BEP.

from bittorrent.org.

Closing in favor of #92

from bittorrent.org.