Gregory Todd Williams

I’ve been bandying about the idea of using BitTorrent in a BBS context (Hotline, KDX, etc.) for some time now, and I constantly run into problems convincing people that this is a really good idea. The problem, I believe, is the common misconception that BitTorrent means to take up the position of both resource discovery and content dispersal.

Almost everyone I have put this idea to has complained that bolting BitTorrent support onto a Hotline/KDX-like application would cause the network to become centralized, and thus easily shut down. There are a couple of issues with this:

1. Hotline and KDX are already centralized services, and therefore are just as suceptible to being shut down as a hybrid with BitTorrent would be.
2. BitTorrent itself is a partially centralized service. The downloading happens in a distributed manner, but the tracker responsible for keeping track of the availability and progress of peers is a required component of the network; If the tracker is taken down, no new downloads may be started and the efficiency of the network will decrease until it stops completely.

BitTorrent only fills the role of content dispersal. It takes the place of FTP, HTTP, or the file transfer protocols of KDX and Hotline.

I’m more interested in the ways the BitTorrent protocol can be combined with resource discovery. Hotline and KDX give you access to the local files on the server as well as the ability to use trackers to discover new servers. To get some of this functionality with BitTorrent, I’ve been thinking about what it would take to add resource discovery to the BitTorrent tracker. I think it would be nice to have the tracker know about (some of) the files it is serving the torrent information for, and have that information accessible through the tracker’s API.

To do this, here’s what would be needed (as far as I know):

1. A new POST query to the tracker that would accept uploading of the torrent file.
2. A new GET query to the tracker that would return a list of available torrent files.
3. A new GET query to the tracker that would return a torrent file.

Further additions might group torrents into a hierarchical structure to emulate the files and folders approach taken by the BBS apps, but for a modestly sized list of large files, information overload could be much reduced by a good client-side interface (ala iApps/Finder live searching).

Now from a privacy/security standpoint there’s certainly something to be said for a tracker that has no knowledge of the torrents it is tracking. I believe that adding a tracker option to provide access to data about the tracker and its tracked torrents would be a real benefit in some situations. I like the idea of being able to use only a BitTorrent client to list/search and download all available trailers from Apple Quicktime, or RedHat, or Sourceforge (perhaps limited to a certain number of the most popular downloads).

Another idea I’d like to see implemented on the client side is the ability to open torrent files, examine its contents, and selectively download portions of the archive. As far as I know, this could be implemented with no changes to other clients or the tracker. (Or maybe this already exists in one of the third party clients? I tried to use Azureus to look for new features, but it hung on OS X.)

I’ll hopefully post more about this stuff later (or, god forbid, write some code), but for now it’s just some preliminary ideas about where I’d like to see this sort of thing go in the future.