Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Journal Journal: We need a Slash-torrent Firefox Extension 21

I need to get this idea out of my head and down on paper (so-to-speak), as it has been driving me nuts all evening.

We need someone to develop a firefox extension that affects Slashdot's rendering a bit, integrates with RSS, and can execute actions in the background when the user is away. It goes something like this:

I wish to submit a story to slashdot. I include a few links, and most of them are on webservers that in no way could handle the load of a slashdotting. Before I submit the story, I run a spider on my story text (perhaps built into the extension?) that downloads the text of the page, and any IMG tags on the page. Should probably have an option to either ignore or allow any flash or other binary filetypes (.avi, .mov, .exe, etc). When indexing, it pulls down that content, and packs it all into a single binary file, perhaps a simple .tar.gz (.bz2?), and then from there creates a .torrent file for that binary package.

With the advent of trackerless torrents, that may be the last of the work, otherwise this will need to be made availabe on a tracker site. A multitude of these exist currently. Now we simply need to convince slashdot to allow a hidden tag included in the story submission, perhaps <torrent:http://trackersite/file.torrent>

For those using the extension regularly, the extension will ping slashdot's RSS feed once every 30 minutes. For each story containing the hidden torrent tag, it will automatically join the torrent for that story. The torrent will save locally, and unpack to a directory specified by the user, and associate itself with the sid from which the link was retrieved.

When the user goes to view the slashdot site, the rendering will be intentionally altered. Stories that have not yet completed the torrent download should have an altered background color (customizable by the user?) and perhaps some additional text notifying the user that the download is not yet complete. Ones that are completed could have a pretty icon added to let you know that the links are all available.

When the user clicks the links from the altered story, it will actually point to the files on the local hard drive, and using some simple regular expressions should take care of image loading and linking off to other sites from there.

The important thing is that the story submitter include ALL urls pertinent to the story. If you have a 5 page story, you must include all 5 url's in the spidering process.

This process will also download plain text banner ads. I'm not too concerned about this however. When rendering the page later, if someone has adblock enabled, they still won't appear, and the original content owner can't really complain that we're filtering ads from their site. Besides, we're taking a load off of their server. ;)

If done correctly, this would work for all slashcode sites. It requires minimal cooperation from slashdot themselves. Allowing a single new, hidden tag to be allowed in the story submission process. If they don't wish to cooperate, this could STILL be worked around. Basing things on the originating url ( as opposed to for example) and the sid of the story. Then we would need to have a centralized off-site tracker to organize things, or at least a few 'known good' locations to immediately go look for the torrent files.

You could also set up an automated spider to create our binary torrent file 'ex-post-facto' by pinging the RSS feed, if no torrent is available, define the scope (which urls to include), create the torrent and away we go.

I'm not saying the above is neccessary 'easy', but it is most certainly obtainable, and I have to think very worthwhile. If done correctly, everyone using the plugin becomes a seeder, and you don't have to worry about seeders becoming leeches, unless they close the browser out entirely often, and if they're doing that, they're robbing themselves of the benefit of the plugin to begin with.

Really, this is just extending the idea of podcasting, or the RSS+Bittorrent for broadcasting idea to slashdot to completely put to rest the slashdot effect, once and for all. Those using IE will be SOL. :P Actually, we may still put it to bed because now the number of people hitting the original site will be significantly reduced. The only real impact of course will be that the server logs of the one running the original site might now think that all of their users use IE, and that Firefox just dropped off of the map entirely or something. :\

Whatever the case, I think this is the right answer to finally solve the problem. I didn't know where to put this, so I'm putting it here, and I'll probably copy the URL to this posting into every slashdot post I make for a while. Perhaps I can draw enough interest and enough coders familiar with Firefox extensions that this can come to life. The only language I know is perl, and at least last time I checked, perl wasn't the right tool for the job for extension coding. :(

Slashdot Top Deals

"The following is not for the weak of heart or Fundamentalists." -- Dave Barry