Bittorrent in Firefox (again)

So it seems like Bittorrent support for Firefox is one of those projects, like a graphical XUL editor, which seems to have some sort of jinx. There have been at least three attempts made, the last one backed by a $4000 Google Summer of Code bounty, and still there’s not even an extension I can install to do Bittorrent downloads natively. (Although the Ubuntu helper app I discovered recently does a creditably simple job.) At this rate, we’ll run out of names for Bittorrent/Mozilla projects before we get one which produces something. :-(

Meanwhile, Opera are stepping up to the plate. Kudos to them, but we really should have been first.

Then again, I guess if AllPeers are doing it (although we haven’t seen any source from them, they have promised that their code will be released under a licence “broadly similar to the Mozilla Public License”) do we need any independent implementations?

Well, it’s my view that Bittorrent support needs to be part of core Firefox. And for that to happen, we need an implementation under a licensing scheme compatible with the tri-licence. AllPeers may be that, although “similar” rather implies “not the same”; but if it’s not, a Firefox Bittorrent is still needed.

Anyone want to have a fourth go?

34 thoughts on “Bittorrent in Firefox (again)

  1. I must beg to differ. While I’m an avid Azureus user, I have been disappointed by Bittorrent clients in general. I use Windows only, but I think that’s not a problem. There are probably a dozen widely-used clients for the platform, but after trying each one, I am left disappointed. I’m not satisfied with Azureus because it’s got a slow, Java interface cluttered with more tabs than your overflowed Firefox window. Therefore, I’d go on a testing binge periodically. Sadly, only utorrent(.com) has a nicer interface, but the problem with that client is that it cannot control transfer rates very well, leading to very poor performance.

    Therein lies the big problem. I suspect that due to the popularity of Azureus, its algorithm is used by most BT users, so it will perform better than most other clients. Already, download speeds via BT are vastly variable depending on the swarm. This means corporations will be very reluctant to use it for fear of offending novice users, who’d have no idea why their Firefox download is soooo slow. Add to that poor client performance and you’ll be left a very upset customer.

    Many people have tried to make a BT client, not just a Firefox addon, and failed. Only one group is on the right track so far — Azureus — IMO, so unless Mozilla Corp. wants to hire some engineers for the project, I think it’ll be ok to wait for the next ambitious group.

  2. I’m a Firefox user. I’d never be a user of the suite, because I’d rather have discrete components and the flexibility that allows, and because the bigger apps *seem* bloated and unreliable. With that mindset, why would I want Firefox to be a bittorrent client? Quite frankly, I don’t want to upgrade Firefox when there’s a security vulnerability in some newly-hatched BT client that I’m not using. I don’t want by downloads interrupted if Firefox crashes.

    At the moment, I click a torrent, and my BitTorrent client-du-jour appears and downloads it. It’s a fairly streamlined experience once the client is installed. On the other hand, if you’ve used any of the capable BT clients, you’ll see they’re obliged to support a plethora of options for network settings, a pile of code to work with Universal Plug and Play routers, Windows Firewall support, etc., just for the minimum functionality (in practice they have many, many more for bandwidth scheduling, disk caching and so forth). Do you really advocate complicating the browser with all that? If Firefox becomes complicated to install, people won’t use it.

    I *do* understand the motivation: there’s all this great content that’s “hard” to get at with Firefox. My argument is simply that downloading a BitTorrent client is the easiest part of the process towards accessing that content.

    There’s a lesson in the failures: BT support sounds cool, but it’s hard. Maintaining it is a full-time job. Consider just the most recent “innovations”: HTTP seeds and encrypted transports. Before that was peer exchange and DHT (for which there are two approaches). There’s a UDP tracker protocol.

    Having said all that, I suppose I agree with you on one point: it’s pretty weak that nobody’s managed to wrap libtorrent with a Firefox extension yet.

  3. Don’t bloat Firefox with something that will not be used by the majority of users. I don’t want no BT in my Firefox. That’s what 3rd party BT software is for, leave Firefox alone, as a pure browser.

    I don’t want anything that even smells like filesharing on my system.

  4. I agree 100% with James. Implementing BitTorrent is hard. There are a massive amount of options. E.g. I have my BT client set to seed up to 150%, and after that limit the seeding speed to 5 kb/s, because otherwise I will run into bandwidth problems with my ISP (I can use 100 GB/week, and that�s gone FAST on a 100mbps connection), but it will not *entirely* disable the seeding (to avoid torrents from running dry).

    I think it�s hard to create a good BT client, and reasonable defaults, too. If you don�t do it right (e.g. something as simple as having no �key� support), it will cause the client to be banned on a lot of trackers.

    No, I like it fine the way it is. I click a BT link, press OK, and it�s added to my BT client (�Torrent). This is simple, and works just fine. I think better than Firefox ever can, because it�s a dedicated client.


  5. With that mindset, why would I want Firefox to be a bittorrent client?

    Why would you want it to be an FTP client? Same reasons.

    I don’t want anything that even smells like filesharing on my system.

    Afraid of the RIAA? :-)

    Bittorrent clients only “upload” the files you download.

    All of you who say “I’m happy with my existing BT client”, that’s all very well, but 99.9% of users (e.g. on Windows) don’t have a BT client and won’t. If BT is ever to take off as a legitimate and widely-used download mechanism (and, incidentally, pull itself out of the reach of those who would foolishly ban the entire protocol) it needs to be built into browsers.

  6. I’m an Azureus user (thought I wouldn’t say avid), and I think it’s a good idea to include very basic bittorrent functionality. Files should download in the normal downloads window. Their progress bar could even look exactly the same showing percent done (we don’t need anything fancy showing which parts of the file are needed, etc…). Just as with other downloads, we should have Cancel, Pause, and Remove (when done) links. The cancel button should stay around when seeding, and the item shouldn’t be auto removed until we’ve reached the max upload.

    As far as settings go… I don’t think we need a download by download settings, just global. We should be able to set the upload speed, port, and max percent to seed (defaulting to 150% sounds good). Oh, and of course if you want to disable the built in bittorrent, that should be easy.

    Ideally this would be released as an extension first. I don’t know much about the protocol, but I don’t understand why it hasn’t been implemented yet. Just keep it simple, and allow power users to use something else instead.

  7. Why should we have been first? BitTorrent is a great distribution mechanism, but it’s so incredibly far off the beaten-mainstream path there’s no reason to support it out of the box right now.

    New features like this are fantastic for extensions, and once they become a common user task, they become targets for entry into the product. It’s risky to think that Firefox should become the default handler for all your TCP/IP based information transactions because for each type of transaction we add, we also add the UI complexity required to configure and control those transactions. Not to mention the code size, QA complexity, security entry points …

    (Note: I say this as someone who uses BitTorrent an awful lot for grabbing files that are distributed that way)

  8. We should be able to set the upload speed, port, and max percent to seed (defaulting to 150% sounds good).

    Only having used bittorrent a few times it sounds like the only option of those 3 that might be needed in the GUI is port – and only then if it can’t be determined from some simple algorithm like “use port $(standard port) if we can otherwise try port 80”.

    The point about a browser-based bittorrent solution is that it should be as simple and transparent as possible – getting a file from bittorrent shouldn’t be harder than getting one from FTP.

  9. “Why should we have been first? BitTorrent is a great distribution mechanism, but it’s so incredibly far off the beaten-mainstream path there’s no reason to support it out of the box right now.”

    So is CSS3. So is SVG (relatively speaking). On the contrary, the reasons for Mozilla’s native support of technologies is to encourage adoption.

    Cutting out the third-party client for those that will never understand/install it would be a positive move for BitTorrent usage on the web. There are few UI additions that would be required.

    Native support with few (if any) visible prefs and the ability for extensions to expose further preferences is somewhat akin to the Gecko Network tweaking scenario.

  10. How about a plugin?

    I see no reason for bundling this feature in when utorrent and the mainline client are so fast. If Ludde at utorrent or Bram wants to make an embeddable version for firefox, why not that?

  11. CSS3 and SVG are things that, while not widely used now, we want to encourage use off. It’s not clear to me that bittorrent falls in that category. Maybe it does. If so, we should try to support it. But I’d like to see an argument for why bittorrent is good for the Web in general, then.

  12. I don’t see any reason why Mozilla/Firefox should support bittorrent: the notion that a browser is the right place to put a file upload daemon seems absurd on its face to me (something I’ve mentioned to the allpeers devs several times). If you want a bittorrent daemon, run it as a separate app (using XULRunner even!) and don’t bloat the browser with it.

  13. I think that Firefox should have native support for bittorrent files.

    I’ve used it now in Opera9 PR2, and it works like a charm. I didn’t need to know anything about it, I just clicked on the torrent link and it worked.

    To me, it’s just like downloading a file (at least in Opera9 it is), so why shouldn’t Firefox support it?

  14. uTorrent (140k) & Opera 9 beta (4 MB) show us torrent support can be added without bloat.

    It would be really nice to have, but so would multi-threaded/segmented download support. The problem is, if the browser crashes you want the DLM not to, or at least be able to easily recover.

    Imagine the Firefox automatic update swarms with millions of users P2P sharing instead of downloading the updates over ftp/http. I don’t know how much you guys spend on bandwidth, but that and other downloads might be worth it. I agree, BT needs to be promoted & made usable for as many as possible.

  15. I agree with jgraham at February 17, 2006 04:53 PM

    Options should be minimized to make it easy to use.
    If people want granularity, they should download a standalone client.

    We should be able to set the upload speed, port, and max percent to seed (defaulting to 150% sounds good).

    I think we should autodetect port, and only upload so long as the client is downloading. Forget this “100% share” stuff. For legal means, there will be a dedicated bittorrent server seeding somewhere.

  16. “Forget this “100% share” stuff. For legal means, there will be a dedicated bittorrent server seeding somewhere.”

    Heh. Sort of defeats the whole object of bittorents then, if you ask me. You could do the sharing in some nice, silent and non-intrusive way.

  17. I’m with Gerv here. Firefox has to have bittorrent support, if not now, than tomorrow.
    All questions in “what for” style can be addressed to FTP support. Why would any browser support FTP overall? And how popular FTP would be without browser support?

    We’re not only “users” of the market, we’re co-creating it. So if web browser will not include torrent support, than probably it’ll stay away from main stream for a long time being “just another p2p network”, but if browsers WILL start supporting it, it’ll just replace ftp. People ARE downloading files using their browsers. And Bit Torrent IS the best way to distribute those files, way better than FTP and HTTP.

    Benjamin: what do you mean by “bloating”? Look at Opera’s implementation. Open Opera 8.5 and 9.0 Tp2. Do you feel that they “bloated” anything? New feature don’t have to rise the bloat, this kind of feature can be UI-less, it still will use Download Manager, possibly with one or two widgets inside file properties to control speed.

  18. > Why would you want it to be an FTP client? Same reasons.
    In the past all major Browser vendors sadly made the decision to include FTP support which made FTP support a requirement for any browser to follow. Downloading over FTP is worse and often slower than over HTTP. FTP is only useful for uploading with older clients and host (newer ones should use SFTP or WebDAV).

    Please don’t repeat the same mistake.

  19. David:

    Forget this “100% share” stuff. For legal means, there will be a dedicated bittorrent server seeding somewhere.

    Heh. Sort of defeats the whole object of bittorents then, if you ask me. You could do the sharing in some nice, silent and non-intrusive way.

    For bandwidth load balancing while serving large popular files with a stable seed, the seed+swarm gain from any participation in the swarm, not only when some arbitrary upload quota is reached afterwards; the currently inevitable http alternative is where the relative leeching is at in that scenario. The individual participant gains by getting a fast and reliable download even at a peak hour, where a http only service with the same resources and number of downloaders would be dead.

    That individual end-user’s gain to the download task is the valid motivator for having bt protocol as a standard feature in the browser user-agent in some nice, silent, and non-intrusive way, if practical. That motivator is no longer valid when the download is complete; we can’t automagically divine whether the user’s disposition toward the torrent provider is even friendly at all without a bunch of intrusive ui, and mustn’t default to consuming the unsuspecting end-user’s bandwidth resources beyond the point where the user’s only known goal related to the torrent is reached.

    As I see it, that’s indeed the difference between implementing bt as a download protocol and not the dreaded upload daemon ;)

    Other applications of torrents, like serving without a stable seed for one reason or the other, may have different requirements to stay useful, of course; but that’s hardly “the whole object of bittorents”.

  20. My answers to the “why” questions:

    First of all, adding support, as Ben Basson and Gandalf said, will help BitTorrent to become mainstream. This will encourage more mainstream sites to provide their files via torrents which will add to adoption, etc…

    Ok, so adding support for BitTorrent encourages adoption. Why is that good?
    I think it’s good because it lets more little guys like you and me distribute large files without incurring huge bandwidth fees. It helps “Democratize the Internet” by giving individuals more power.

    As for the legal concerns of seeding:
    You shouldn’t download files if you think the original posting of the torrent was done without permission (or illegally). It doesn’t matter if you upload 150% or just 3% — if the file is illegal, then you shouldn’t touch it. If you don’t upload at least as much as you download, then you’re acting as a drain on the community. If you don’t want to play fair, then don’t play.

    And now for some friendly FUD:
    Would you rather have BitTorrent or some patented and DRM encumbered protocol like Microsoft’s Avalanche become mainstream? All Microsoft would have to do is add Avalanche to IE 7 and as an update to IE 6, and they’ll have a larger install base than all of the BitTorrent clients combined. Adding BitTorrent to Firefox wont change this fact until Firefox becomes the most popular browser in the world.

    So, what’s the point if Microsoft can get a huge market share at the drop of a hat? Well, client side installs is only half of the equation. If we can help make BitTorrent mainstream on the server side, then it’ll be a lot harder for some other protocol to take over. (Of course, the downside is that it’s harder for a better protocol to take over too, but if a better protocol does come around, then we can throw our support behind it.) The key is to make BitTorrent mainstream first. Opera has shown the way. We just need to step up and make it happen.

  21. Wanna know a dirty little secret? Bittorrent is an ugly hack. There I said it.

    I don’t want a bittorrent client distributed with my web browser. I want my web browser to browse the web and stay at that level of the model. If I wanted my web browser to browse through any other distribution system I would point it at a proxy… and I do. If you want to involve bittorrent in the process of web browsing build it into a proxy of some sort. At the very least keep it in an optional extension.

    Keep it separate. Bittorrent is as out of place in a webbrowser as, I don’t know, an image editor.

  22. If I wanted BitTorrent in a web browser, I’d use SeaMonkey�you know, the browser that also includes a Kitchen Sink among its collection of obscure “geeky” features and unfocused UI (or, well, Opera, which has a similar problem and marketshare).

    BitTorrent is all fine and wonderful and a democratizer of bandwidth, rah rah, but not only is it a new type of transfer protocol, it’s a fundamentally different type of protocol, as these comments and the past discussions of UI and feature requirements have made clear. Promoting a new type of transport protocol is completely different from promoting new forms of standards-based web content like SVG and canvas. It’s not within the mission of Mozilla to legitimize and promote new transport protocols; on the other hand, ensuring support for (and proper display of) new forms of web content most certainly is part of that mission.

    In the old days, non-web content available on the internet was by-and-larged served over ftp, so web browsers really did need to support ftp to make that content available to users; today, these same types of files (application software, fonts, etc.) are almost always served over http only, or in a few cases have both http and ftp streams available. ftp is all but dead for downloads and I wouldn’t shed a tear if it were removed altogether from web browsers. Similarly, relatively little non-web content is available via BitTorrent, so the old ftp analogy doesn’t apply, and until there’s a tipping point where the vast majority of non-web content on the internet is available via BitTorrent only, there’s no need for it to become a core transport mechanism of a web browser.

    BitTorrent is, at best, extension fodder at this time.

    (Cheap shot: And if you think memory leaks in Firefox 1.5 are bad, wait until you add a BitTorrent client! Ouch!)

  23. I agree with some of the others about smelling like a file sharing system. I work for the U.S. government and on their network if someone uses Bittorrent, the big boys know about it and we find the machine and take it off of the network. Bittorrent is a bad word and I would be very apprehensive about deploying anything that nativly supported the Bittorrent protocol.

    If it could be added as a native extension such as Talkback or the DOM tool then that would be how I would perfer it. If we get a client customization kid it could be easily disabled on install.

    Personally, I would love it for my home use, but this would stop people like me from deploying it to our users at work.

  24. Segmented (plain HTTP & FTP) would be a better start. Think of all the FOSS projects that use tons of mirrors. No P2P or bandwidth issues. It isn’t free bandwidth, but at least its better by distributing it between mirrors.

  25. If I can turn it off, that would work out pretty great! Thank you. Still hoping for the people in Washington to mandate that we use it instead of IE one of these days because there are patches to IE/Windows every month that we have to make sure is on every one of our machines. I have yet to see a Firefox 1.5 installation that has not been automatically brought up to

  26. Hey Gerv… long time no encounter!

    Anyway, my two cents – There are plenty of very functional clients (u-torrent among them) which accomplish huge functionality with a tiny footprint, so this surely shouldn’t be beyond the capabilites of developers.

    That said, though: Bittorrent certainly does *not* need to be part of core Firefox functionality, although having it as an extension seems sensible enough. Why bolt on unneccessary bytes and processes to a product formidable because of its simplicity and adaptability, not despite it.

    Take care,

    Matt Lodder

  27. Say no to Bittorrent as core Firefox code. The use of BT is banned within a sizble number of organisations and there would be a risk that firefox itself could be the subject of suh a ban if BT worked out of the box.

  28. To ban BitTorrent is an arrogant thing to do. I would imagine the real reason is that the higher ups got wind that illegal content is only available through BitTorrent and that is like Kazaa or other P2P software. So the IT department banned BitTorrent like they ban Kazaa and other P2P software because they don’t want to waste the companies bandwidth while saving the bandwidth of the company they are leeching from. All FTP and HTTP protocols are leechers, BitTorrent serves to create a community of Leechers and seeders who give back to the community instead of taking.

    So FTP and HTTP is like child taking from their parents and BitTorrent is like the working adult.

  29. Say no to Bittorrent as core Firefox code. The use of BT is banned within a sizble number of organisations and there would be a risk that firefox itself could be the subject of suh a ban if BT worked out of the box.

    Have to second that. I work for a large corporation with almost Draconian policies towards filesharing and anything that’s not on our standard load. Our company formally announced a company-wide switch to Firefox as it’s standard, and we even have our own customized version–but if filesharing was built in or easy to implement, they’d nip that in the bud right away: foom! no more Firefox.

    While I was looking for a BT client for FireFox, once I read this point, I realized that, for the sake of all business users, we need to keep them separate. If there be any awkward gap between FF and, say, Azureus (though I know of no such gap), then write a plugin that bridges that gap, but do not try to build Azureus into Firefox.

    Just my five cents or more.

  30. BitTorrent is a legitimate method of file exchange; the latest Opera includes it as standard. We can certainly have a pref to disable it, which could be set as a company policy in companies which objected to Bittorrent in some manner. But those companies objections are not a reason, on their own, to keep Bittorrent out of Firefox.

  31. An answer to the problem of Firefox crashes halting or killing downloads. As mentioned before the torrent app should be farly simple, so why not make it a small app that integrates with Firefox, and receives the downloads automatically? This way it would not crash if the browser dies. Also to make a basic torrent app, without UI for all the advanced options, it would not require a large file. And to add onto the support for anti-BT’ers, provide 2 separate install options, or 2 separate download packages.