| ||
|
Outside the System
Categories
As Seen On ...(4)
Emerging Systems(9) Film & Video(18) Independence(13) Internet Publishing(2) IP Law(7) Memetics(3) Meta-OTS(5) Stats & Data(4)
Monthly Archives
Recent Entries
"Faux Docs as Natural Virals"
"The Challenges of Multiple Blogs" "Gates Using A Mac" "21% of Music Downloaders Have Downloaded A Film" "Leonardo Chiariglione Interview" "Biblogeral Mind" "I, For One, Welcome Our New Blog Overlords!" ""Net Heads" in Variety" "ADC Multi-Channel Award" "The Size of the Blogsphere" |
Gated Torrents UpdateOther development and writing tasks have kept me away from blogging about some of my experiments, but I'm getting ready this weekend to move my experiment on "gated torrents" (see previous thoughts). My current experiments have been focused on simple gating with .htaccess (ie, you get a piece of the equation or you don't) but I'm ready this weekend to instead move my test to a BitPass gateway as the last tests before a real distribution. I've learned some interesting things already that I thought I might share. The basic concept is still that gating one element or another (big media object, torrent file or tracker access) provides an opportunity to "gatekeep" access to the video file -- whether that gatekeeping is for "members only" or an actual microtransaction. In my notes here, I'll refer alot to "defeating the gateway" which is really a polite way of saying "a piracy risk in the eyes of a more conservative media publisher" (at least if the gateway is a commercial one.) The most promise seems to be in gatekeeping both the BMO and the torrent file. The most interesting aspect is how partially defeating the gateway (say, by distribution of the torrent file to a location outside the gateway) creates a less-than-adequate experience for the download. If I've got the torrent file and access to the tracker, but not access to the BMO, other test torrent clients on my test network are extremely loathe to hand up any data (unless the sharing permissions are quite high and the client has completed it's own download.) Different clients work in different ways, but the most standard configurations that other people are using leave a fairly "gift economy" thinking once they are have completed their own download (one test client happily served up 5x the download amount to clients with nothing to share in return.) Enter the biggest bugaboo -- Azureus, a Java-based BitTorrent client. It has an interesting addition that few other clients have: an embedded tracker. Specifically: "Azureus has a built in tracker to allow users to share torrents directly, rather than uploading them to an 'external' tracker. This is called 'hosting' and can be performed by selecting this option from the context menu on the 'My Torrents' view Bummer for a gated system: once a user has downloaded the torrent and the BMO, two quick menu options and I can republish the BMO with a brand new torrent file pointing to my new tracker (rather than the original one I downloaded from.) Azureus even publishes a webpage of all the torrents I'm hosting on that tracker (it's just a matter of time before RSS turns those into broadcatchable.) Conversely, the "Publish" option re-publishes just the torrent file (ie, still pointing to the gated BMO and original tracker) just as easily, but without quite as horrible consequences. So Azureus isn't defeating the gateway, but it makes republishing exceptionally simple for others outside that gateway. And highlights the familiar lesson of the "danger" of any open format: that future innovations of torrent-using clients with this kind of integrated sharing could layer P2P sharing in the form of republishing. I think we're probably less than two weeks away from really trying this out, in a real situation. I'm designing an experiment in my head to look at how this optimizes and scales outside of my smaller test client network. A technical document will be forthcoming, but I'm thinking about a test that is limited in time (say 2 days) and charges a nominal rate for a feature download (say, $1.50 where we have been charging $5) but also "encourages" exploration of the system -- not hacking, but "getting around the gateway" -- with people reporting in their successes. Then whip that data together and make it public so that others experimenting with this can get a good glimpse at the risks and benefits of gated torrents. posted to Emerging Systems on April 08, 2004
|
|
|
Copyright © 2004, Brian Clark. | ||