Unlike a broadcast medium the price of popularity on the web does notscale very well. Popularity and the cost of bandwidth go hand in hand. A popular podcast by a small or independent content creator can have serious financial repercussions as word spreads and downloads increase. I'm sure anyone who has encountered the Slashdot effect will concur that being popular has hits drawbacks.

Bulging bandwidth costs is what BitTorrent was originally designed to alleviate. By distributing content across multiple dynamic servers bandwidth costs are shared by those who are consuming the content and a temporary community sprouts up for each new piece of content made public using the BitTorrent format.

At the moment, BitTorrent is on the slightly more advanced side of web browsing. In many cases the user must understand that they have to download a BitTorrent client in order to receive the content or in many cases help the producer with their bandwidth concerns. At the technical level, a BitTorrent file is essentially treated as a separate MIME type (application/x-bittorrent). This helps the web browser associate BitTorrent files with the BitTorrent client.

I would argue that BitTorrent, while technically an application, can also be viewed as a transport mechanism on top of HTTP. The HTTP 1.1 specification, section 14.3 provides for various types of encodings when delivering content. By providing an encoding type of "bittorrent" an HTTP client could indicate that it supports the BitTorrent natively and provide bandwidth savings seamlessly for the user much like the current gzip encoding provided in most web browsers.

Now, we can argue semantics and say that technically BitTorrent is not an encoding scheme. This may be technically true however without modifying the HTTP specification it's a nice way to embed BitTorrent such that the transfer is virtually seamless. The server transfers the necessary torrent information and the client procures the transfer as a standard BitTorrent download. But why not just have the client detect the application/x-bittorrent MIME type? Unfortunately there's no way for the server to know if the client can handle the BitTorrent MIME type. The Accept-Encoding header lets the client tell the server what it can support and the file is served up appropriately.

There was some support behind the idea of baked in BitTorent on the server side with mod_torrent but the project has been suspended due to lack of time. This echos my current situation in that I don't have the time at the moment to implement such a technique but I'm interested in what's possible.

I know that the podcasting community is grappling with bandwidth issues and that BitTorrent has been mentioned a few times. I'm curious what other's thoughts are.