Ok, it would add an extra layer of indirection to bit torrents, but you could add extra things like proxying and authentication to torrents.

You’re looking at it like an extension to HTTP, and thinking that it has some problems. Yes but it doesn’t mean that every HTML page has to be a BT page. It could mean the opposite: every BT packet could have a HTTP header. That would add a lot of already well thought-out functionality.

Jacques Chester from Clubtroppo started an interesting discussion the other day with his proposal to use Bittorrent as a remedy against the Digg effect. However, the Pirate Bay’s Fredrik Neij aka Tiamo thinks the numbers don’t add up. …

First issue: the server is stalled and can’t supply the page so you will never see the X-torrent header.

So you solve that like Amazon do by layering bittorrent over the top – ie. instead of serving the actual page to all requesters you serve up a bittorrent file and then the client browser uses that to download the page. With light traffic this ends up a little slower as there is a level of indirection, and when things get heavy there’s a bittorrent cloud to serve up your page. Cool idea, and it’s what Amazon are doing.

But you are going to have to change all your links – ie. get your site to reference a bunch of bittorrent files rather than html files.

Next you’re going to have to get clients (all of em if you are to have any hope of transparency) to recognize what you are doing.

ie. you are going to have to turn the web (or at least your part of it) into a *.bt cloud rather than a *.html cloud.

In other words browsers have to become bittorrent clients. Not technically impossible but not piss easy either (Firefox has a torrent plugin but I’ve never got it to work). Further you have to distribute this new functionality and get everyone to use it.

At this point you’re trying to recreate the web from scratch using (let’s make up an acronym) BTTP instead of HTTP.

To make this workable I think you’d have to extend HTTP using something like the redirection condition (“this page temporarily moved” – I forget the code) so that the browser would attempt to reload the page the user is looking for but actually load the torrent file instead (which assumes your server is responsive enough to return that condition *and* that some server is available and responsive enough to subsequently serve up the torrent file).

Then – so long as the browser can recognize torrent files – bobs your uncle.

I just don’t see how you could make this happen quickly enough to get the benefits you seek. You need a certain population of enabled browsers to get enough of a cloud going to get the benefits.

The technical way of explaining what I’ve described above is:
1. You’re layering (or tunnelling) one protocol (BT) over another (HTTP)
2. That means you need protocol agents for that second protocol (BT) at each end (both in the browser and the server)

You’re not going to achieve (2) which a simple header marker.

a commenter on Reddit makes the fairly sensible suggestion that alternatively, web browsers could send a message to the web server that they will accept a torrent file instead of the original using the HTTP Accept-Encoding header.

This doesn’t seem sensible to me since it depends on the server that we’re assuming cannot send you the page in the first place. There’s also a problem with page updating – let’s say you updated this blog post, and client 1 had cached and started torrenting the old version. Client 2 comes along, and successfully receives the new updated page, and starts serving it through the X-Torrent tracker. Client 1 needs to realize it has an old copy, and re-request the page or get off the tracker. This presents a security hole – any client can join the X-Torrent tracker and claim they have a new version of the site, DDOS the original server, and distribute their own defaced version using X-Torrent. The only way to guarantee that the authors content is, excuse me for the pun, authoritative, is to have the author act as the sole seed, bringing updates to the tracker and refreshing everyone who is not identified as the author.

But, all skepticism aside, pretty cool idea.

http://www.anonweb.pro.tc

http://www.anonweb.pro.tc

(…) I’d also argue that the X-Torrent header model has a fundamental flaw in that it still depends on the very server that is in trouble in such a situation….