Subject: [p2prg] what if: a bittorrent URI scheme?

From: Ivan Shmakov <[email-masked]>
Date: Fri, 14 May 2010 00:39:48 +0700

I wonder, does it make sense to define a ‘bittorrent:’ URI
	scheme?

	The scheme would allow to “name” specific “torrents” (and thus,
	when bound by trackers, swarms) and peers, thus providing a way
	to mention either in any context where an URI is allowed.

	The format may be, say:

	• bittorrent:INFOHASH — to identify a torrent (akin to a ‘uuid:’
	  URI);

	• bittorrent://HOST:PORT/ — to identify a peer;

	• bittorrent://HOST:PORT/INFOHASH — to identify a torrent as
	  served by a particular peer.

	Examples:

bittorrent:0a032f8ef18af821a9410c078a6cb2053b611306
bittorrent://[2001:DB8::12]:3456/
bittorrent://[2001:DB8::12]:3456/0a032f8ef18af821a9410c078a6cb2053b611306

	A few notes.

	• IIUC, it's typical for a torrent to be “identified” by naming
	  the corresponding ‘.torrent’ file.  However, for some
	  applications (such as: replication of large data sets) the
	  contents of the ‘.torrent’ file per se may not be immediately
	  relevant, and the infohash (SHA-1 computed over a specific
	  part of such a file) alone could identify the dataset in
	  question just as well.  Embedding such a value into an URI has
	  certain benefits.

	• Thanks to BEP 19, it's possible for a BitTorrent agent to
	  download from an HTTP server, too.  For an implementation
	  supporting such an extension, there may be a problem of
	  distinguishing HTTP servers from BitTorrent peers (which may
	  be solved, in particular, by adding an extra flag field to
	  each entry of such a list.)  Having both BitTorrent peers and
	  HTTP “seeders” identified in a uniform way may have some
	  benefits.  (E. g., should one consider extending such an agent
	  with support for even more protocols.)

	• I'm in doubt for whether it makes sense to identify “swarms”
	  by an URI, as those are, to my mind, (tracker, torrent) pairs,
	  where both tracker and torrent may be specified as an URI.

	• The scheme name is way too long.  (‘torrent:’, perhaps?)

[1] http://www.bittorrent.org/beps/bep_0019.html

-- 
FSF associate member #7257

---

From: Wes Felter <[email-masked]>
Date: Thu, 13 May 2010 14:39:52 -0500

> 	I wonder, does it make sense to define a ‘bittorrent:’ URI

I think it did, but it's a few years late to do it now.

> 	• bittorrent:INFOHASH — to identify a torrent (akin to a ‘uuid:’

OK, although magnet: already does something like this. 
http://en.wikipedia.org/wiki/Magnet_URI_scheme

> 	• bittorrent://HOST:PORT/ — to identify a peer;

I don't know why I'd want to identify a BitTorrent peer; the point of BT 
IMO is that individual peers don't matter.

> 	  served by a particular peer.

You're getting warmer, but this looks pretty fragile if that peer is down.

I think it would be more straightforward to do 
torrent:TORRENT-FILE-URI!FILENAME, e.g.

torrent:http://example.com/baz.torrent
torrent:http://tracker.example.org/foo.torrent!bar.ogg
torrent:ftp://example.net/whatever/something/else.torrent!baz.jpg
torrent:news:[email-masked]!quux.pdf

The interpretation should be obvious: fetch the inner URI, interpret it 
as a metainfo file, join the specified swarm, and download the specified 
file. The ! allows you to download a single file out of a multi-file 
torrent, as in the jar: URI scheme. You could do some cute tricks with 
this, like putting a whole image gallery in one torrent:

<img src="torrent:http://example.com/gallery.torrent!1.jpg">
<img src="torrent:http://example.com/gallery.torrent!2.jpg">
<img src="torrent:http://example.com/gallery.torrent!3.jpg">

Wes Felter

---

From: Ivan Shmakov <[email-masked]>
Date: Fri, 14 May 2010 10:45:21 +0700

>>>>> Wes Felter <[email-masked]> writes:
>>>>> Ivan Shmakov wrote:

[...]

 > http://en.wikipedia.org/wiki/Magnet_URI_scheme

	Thanks for the pointer!

	However, it seems that this URI scheme uses, in turn, a URN
	namespace (urn:btih:) for BitTorrent info hashes:

--cut: http://en.wikipedia.org/wiki/Magnet_URI_scheme --
   BTIH (BitTorrent Info Hash)

   Hash sum used on BitTorrent.
  xt=urn:btih:[ BitTorrent Info Hash (Hex) ]

   Some clients require Base32 of info_hash (Vuze for ex.).
--cut: http://en.wikipedia.org/wiki/Magnet_URI_scheme --

	Indeed, such a URN could be used for (some of) the purposes I've
	mentioned.  Do I understand it correctly that it isn't standard,
	though?  What'd be the way to have it standardized?

 > I don't know why I'd want to identify a BitTorrent peer; the point of
 > BT IMO is that individual peers don't matter.

	Implementations of the BitTorrent protocol are ought to track
	the individual peers.  To this end, a kind of a table is used.
	I guess that for most of the implementations it contains peer's
	“transport address” (IP:port), and any information the
	implementation is question deems valuable.

	However, this table is non-extensible when it comes to
	implementing support for other protocols, such as HTTP (see also
	BEP 19, [1]; FWIW, P2P filesharing could be implemented entirely
	over the HTTP/1.1 protocol.)

 >> • bittorrent://HOST:PORT/INFOHASH — to identify a torrent as served
 >> by a particular peer.

 > You're getting warmer, but this looks pretty fragile if that peer is

	There're some BitTorrent agents that allow for a peer to be
	added manually, which makes sense in NAT'ed environments.

	E. g., your friend, participating in a certain swarm, may pass
	you such a URI, which, when passed to a BitTorrent agent, may
	cause it to establish an immediate connection to that peer.

 > The interpretation should be obvious: fetch the inner URI, interpret
 > it as a metainfo file, join the specified swarm, and download the
 > specified file. The ! allows you to download a single file out of a
 > multi-file torrent, as in the jar: URI scheme. You could do some cute
 > tricks with this, like putting a whole image gallery in one torrent:

 > <img src="torrent:http://example.com/gallery.torrent!3.jpg">

	Nice, yes.

	However, it's my wish for the .torrent files to become
	irrelevant.

	Note that any site offering .torrent files for exchange could
	offer a search tool for such a torrent: (or urn:btih:, or
	whatever) scheme URI's, or even an API for the BitTorrent
	software to automagically download the .torrent file
	corresponding to the info hash referenced by such a URI.

	(I wonder if Bitzi [2] already does it, and does it for years.)

[2] http://bitzi.com/