Bandwidth Donation Protocol
Bandwidth is both expensive and cheap. It's cheap at a lot of hosts and for a lot of consumers, because providers expect we're not going to use what we're allocated, and yet expensive when purchased in bulk, where the assumption must be that it will all be used.
Every time I hear about how expensive it is to run a successful podcast (like the NPR podcasts, some of which are begging for money to pay for $150k annual bandwidth bills), I think to myself, "I have spare bandwidth; I'd like to donate some". But there's no mechanism for me to do that.
And why not? I don't think it would be that hard to do. Let's take a rough cut at it.
The goal is for a provider to be able to share a particular piece of content, say a podcast, with as many people as possible, and accept donated bandwidth for distributing it.
One possibility is BitTorrent, which does a fairly good job of this, but would require a custom client. The biggest podcast client in the world is iTunes, and it doesn't support BitTorrent, so any podcast that doesn't want to lose most of its audience will stick with HTTP as the distribution protocol. We need a way of distributing URLs that will load balance to the donated bandwidth.
As a donator, here's what I want to be able to do: Go to, say, the NPR website, and click on the "donate bandwidth" link. At this link I'd enter the URL for my Bandwidth Donation Protocol (BDP) service, the amount of bandwidth I want to donate (in megabytes or gigabytes) and a key or password. NPR's service would then add me to it's bandwidth donator pool.
Now when they have a podcast they want to post, they generate a URL for that podcast. Say it's:
Before using my donated bandwidth, they need to upload the content to me. Their server contacts my server and says "here's hypotheticalpodcast.mp3, and I'd like you to allocate 1 gigabyte worth of bandwidth to it". In return, my server would generate, say, 200 unique URLs and return them to NPR. Now for the next 200 requests for this content, they can 301 redirect to my URLs and distribute the content at no cost to them.
Why generate the 200 URLs? Why not just use the same URL and stop answering after 200 requests? Because a single user downloading content might request the URL more than once (for example, picking up ranges of content), so the URL can cut off after a reasonable amount of time, but not be vulnerable to abuse by giving out the URL 500 times when only authorized to do so 200 times.
I've wanted to implement something like this for years but never had the time, so I'm throwing it out there: What do you think? Would it work? Would it help the podcasters being crushed by their own success?