Firefox download manager doesn't handle torrents

[Ryan Prior]

Binary package hint: firefox-3.0

The Firefox download manager does not handle .torrent downloads.

Steps to reproduce:
* Navigate to a popular torrent site such as thepiratebay.org
* Search for "Big Buck Bunny" and click a relevant result
* Click the link to begin the download

Expected result:
* Firefox downloads Big Buck Bunny, as it would using HTTP or FTP

Actual result:
* Firefox downloads the .torrent file, offering to pass it on to Transmission.

Notes:
* This behavior is confusing to anyone who is not familiar with bittorrent, ie the "humans" for whom Ubuntu is designed.

[Gervase Markham (gerv-mozilla)]

Q and A:

* Why is it bad to pass this off to a helper app again?

All the current bittorrent clients have terrible UI, and require an extra
install. It would be great if a user could click a .torrent link and have the
file downloaded to disk using the Download Manager, just as any other file.

* Why is it a problem to do this task with a plugin?

Plugins are for rendering web content in the browser.

* What about a download manager plugin, then?

This is roughly what's being suggested. It might start as an external add-in
(assuming that's technically possible), but the big value comes from being
integrated by default.

* What about <img src="blah.jpg.torrent"> ?

The BitTorrent protocol isn't suited for that sort of thing. For a start, it's
slow to get moving, and has a co-ordination overhead.

* What about a torrent:// URL scheme?

There's no such protocol. And if there was, other browsers wouldn't understand
it. And it would require all the info in the .torrent file to be encoded in the
URL - that could make the URL longer than is permitted.

* How would you handle the UI?

Ideally, downloading a file over BitTorrent would be as simple as downloading it
over HTTP. Therefore, we would need to make quite a few choices for the user
that other BitTorrent clients expose.

My idea is as follows:

- Download appears in download manager just like any other, with progress bar
from 0 to 100%.
- The user has no idea which pieces have been got and which haven't.
- There is no way to prioritise one torrent over another.
- Use various tricks to guess at user's u/l and d/l bandwidth, and set
parameters related to that.
- Uploading continues until either:
  - The user exits the browser
  - The user has sent 150% (hidden pref) of the amount of data received.

There are error conditions specific to .torrents we would need to work out UI for:

- No source of a particular piece
  - This can be determined up front; how do we tell the user?
- User is behind a firewall and so their download will suck
  - It's a shame .torrent files don't contain an "alternate URL", with no
    quality of service guarantees attached to it.

* Is there code we can use?

http://libtorrent.sourceforge.net is under the MIT license. It may well be a
good start.

Gerv

[Bzbarsky (bzbarsky)]

> It might start as an external add-in (assuming that's technically possible),

It should be. If it's not, file api bugs as necessary until it is. In fact, I
think we could make it possible to do this with a helper app (with a DDE/xremote
api for the helper to talk to the download manager).

But frankly, that's work and this should be pretty "easily" (in terms of
integration into Mozilla code) doable using a stream converter that will convert
the bittorrent type to whatever the real type is (by actually doing the load).

> * What about <img src="blah.jpg.torrent"> ?
>
> The BitTorrent protocol isn't suited for that sort of thing. For a start, it's
> slow to get moving, and has a co-ordination overhead.

Nice way to evade the question. How about answering it? What exactly should
the tag above do?

A much more interesting question is whether there should be a difference between
just clicking on the torrent link and doing "save link as" on the torrent link.
 The stream converter scenario would not address the latter, of course.

[Ian-hixie (ian-hixie)]

*** Bug 203571 has been marked as a duplicate of this bug. ***

[Tom-zeebit (tom-zeebit)]

Implementing this nativly certainly would be an excellent feature, and a massive
advantage for users over IE / other competitors. My one question is how would
you deal with the situation of sharing post download? The network depends on
people "leaving the window open" afterwards; what would be the feasability / the
likelihood for this to happen with a browser?

[Tom-zeebit (tom-zeebit)]

(In reply to comment #2)

> > * What about <img src="blah.jpg.torrent"> ?
> >
> > The BitTorrent protocol isn't suited for that sort of thing. For a start, it's
> > slow to get moving, and has a co-ordination overhead.
>
> Nice way to evade the question. How about answering it? What exactly should
> the tag above do?
>
> A much more interesting question is whether there should be a difference between
> just clicking on the torrent link and doing "save link as" on the torrent link.

I'm not sure he was dodging the question; essentially he is asking whether one
could put an image say on a bittorrent net, and then link to it via <img src=""
/> tag. Clearly, doing this would save bandwidth. However, this is unfeasable
due to the time needed to contact a tracker, and then initialise individual
connections with peers. For a webpage to render in a reasonable time doing this
would be impossible.

[Gervase Markham (gerv-mozilla)]

> how would you deal with the situation of sharing post download?

I addressed that vaguely in my Q&A. My idea was that we'd measure bandwidth and
use, say, 75% of it. We'd keep uploading until we'd uploaded, say, 150% of the
file size, then stop. If the browser was closed, obviously we'd stop then too.

We might start uploading again if the browser restarted, the tracker was still
there and the file hadn't moved - but that sounds complex. Let's see how far the
above approach takes us.

> What exactly should the tag above do?

Whatever falls out of the design. ;-) In other words, it could do anything.

> A much more interesting question is whether there should be a difference
> between just clicking on the torrent link and doing "save link as" on the
> torrent link.

That is an interesting question. Ideally, of course, this would work too.

Gerv

[Bzbarsky (bzbarsky)]

> Ideally, of course, this would work too.

Then how do you save the torrent file?

Note that this is NOT how it works for various other "spawn off random stuff"
files like mp3 playlists and so forth. If we want it to work like you propose,
I would say that it _should_ be a protocol handler (because otherwise someone
embedding gecko who didn't perform major surgery on their embedding app to let
it know about torrent would have torrent working when clicking on links but not
when doing save link as).

[Ian-hixie (ian-hixie)]

I really don't feel comfortable with the idea that application/x-bittorrent
files should react in a magical way.

If we did this, the same result should happen whether you right-clicked on a
link and saved it, clicked on the link and viewed it, or referred to it via an
<img>, <object>, or background:url() syntax. This would leave no way to get at
the real end of the link, which would arguably make us non-HTTP compliant, IMHO.
It also seems fundamentally wrong to me. (It tickles my quality assurance "here
be bugs" sense.)

Couldn't we implement moz-torrent: (or some other scheme in coordination with
Bram Cohen) and simply have application/x-bittorrent offer to download the file
"using the BitTorrent protocol"? (Just like looking at an application/
octet-steam file should offer to "open the file in Mozilla" if it is really a
text/html or image/png image.)

Hmm. I need to think more about this.

[Tom-zeebit (tom-zeebit)]

Ian;

I can see your point; why bit torrent? Well, Bit torrent is different in that it
really is a big technology that is becoming more and more widely used. If
integrated it would be a major selling point for mozilla; able to download
torrents as standard.

I think however it needs to be clear as to what specifically one would try and
do here. The idea of integrating a bittorrent client into mozilla is A) Cool and
B) useful to the extreme. Coming up with other ideas (<img scr="bittorrent">) is
nice, but shouldn't detract from the original and very unique idea.

[Christian Biesinger (cbiesinger)]

application/x-bittorrent support could be an nsIURIContentListener; to show the
info in the dl manager, it could create an nsIDownload object and call its
nsIWebProgressListener methods normally. This is doable as an extension.

This would mean that this would be invoked when the file would otherwise be
shown by mozilla (left-click on the file), but not when saving the .torrent file
to disk (right-click, save target as).

Wow. This is a way for which these APIs work extremely well. I'm surprised, I
didn't think such a way existed.

whoa, how could this bug get 9 comments within an hour or so?

[Bzbarsky (bzbarsky)]

> Couldn't we implement moz-torrent:

We would need that anyway, actually, since we would need a way of making network
connections to get the data, and the way to do that in mozilla is to have a
protocol and a protocol handler.

Biesi, of the 12 comments (counting comment 0) three are pointless advocacy and
one is dup-noise... of the remainder, approximately 4 have information that's
useful for implementing this. The rest are attempts to figure out what people
are talking about. ;)

[Bzbarsky (bzbarsky)]

Hmm, yeah. Using an nsIURIContentListener may work better than a streamlistener
in that it would prevent HTML content served up as a torrent from being rendered
inline.

[Ian-hixie (ian-hixie)]

> I can see your point; why bit torrent?

That wasn't my point at all, please re-read my comment.

> Hmm, yeah. Using an nsIURIContentListener may work better than a
> streamlistener in that it would prevent HTML content served up as a torrent
> from being rendered inline.

So an http://.../foo.torrent file would be downloaded, but a
moz-torrent:http://.../foo.torrent file would be rendered inline, right? That
seems to me to be what we want if we do this.

[Robert-accettura (raccettura)]

Regarding right clicking and saving torrents. I think it should save the
torrent, and associate it with mozilla, just like a you can save a bookmark to
the desktop. And launching it initiates the download.

(In reply to comment #9)
> I really don't feel comfortable with the idea that application/x-bittorrent
> files should react in a magical way.
>
> If we did this, the same result should happen whether you right-clicked on a
> link and saved it, clicked on the link and viewed it, or referred to it via an
> <img>, <object>, or background:url() syntax. This would leave no way to get at
> the real end of the link, which would arguably make us non-HTTP compliant, IMHO.
> It also seems fundamentally wrong to me. (It tickles my quality assurance "here
> be bugs" sense.)

I don't see how this is really any different than a SMIL file, or a .ram, or
.asx, .qt, etc. All of the above point to streams that don't use the HTTP
protocol (IIRC they all use RTSP).

The proposal, is just to do this internally, by beefing up the Download Manager
itself. Rather than launch another Application.

I think we should lobby for a torrent:// protocol. It's a good idea, and when
BitTorrent matures into a 2.0 protocol, may be wise.

Regarding the use in embedding, such as image tags... I don't see the point.
For most cases, torrents take a few seconds to transfer any data. The page
would most likely timeout anyway.

>
> Couldn't we implement moz-torrent: (or some other scheme in coordination with
> Bram Cohen) and simply have application/x-bittorrent offer to download the file
> "using the BitTorrent protocol"? (Just like looking at an application/
> octet-steam file should offer to "open the file in Mozilla" if it is really a
> text/html or image/png image.)
>
> Hmm. I need to think more about this.

I kicked off this round of BitTorrent debates a few days ago with this:
http://robert.accettura.com/archives/000323.shtml

There are a few questions I recieved, that I will address on my blog regarding
my idea, and reasoning.. perhaps later tonight or early this week.

I think Gerv covered most of it with his rather lengthy opening comments on the bug.

Bottom line: I think it should be treated only through the download manager.
Just download per the bittorrent protocol. A useful feature for the end user.

As Gerv states, content providers LOVE bittorrent. We will be seeing more, not
less of it. Mozilla has a silent history of being inovative, and *better*. I
think it's great to lead the way once again, and provide users with a feature
they can really use.

[Bzbarsky (bzbarsky)]

> So an http://.../foo.torrent file would be downloaded

Yes, if you click on that link.

> but a moz-torrent:http://.../foo.torrent file would be rendered inline, right?

The moz-torrent protocol scheme wouldn't work quite like that. It would simply
be a way of taking the information in the .torrent file and encoding it in a
URI. The protocol handler implementation would then take the information in the
URI and use it to get the actual data. Just a way of passing data from the
application to the network layer.

But yes, if you concocted a moz-torrent uri of the sort that we would construct
from a .torrent file then you could get the content to render inline.

[Bzbarsky (bzbarsky)]

Note that Robert seems to be agreeing with me and Ian and disagreeing with
Gerv... on the right-click issue (though he also seems to think that he's
disagreeing with Ian).

Anyway, as biesi and I said this is trivial to hook into Mozilla as an extension
-- this is one area where our embedding APIs actually work and all.

[Christian Biesinger (cbiesinger)]

(In reply to comment #14)
> So an http://.../foo.torrent file would be downloaded,

Not in the "save link target as" case, though (it would save the .torrent
description file), and <img src> would also not work.

> but a
> moz-torrent:http://.../foo.torrent file would be rendered inline, right? That
> seems to me to be what we want if we do this.

If you want to add a moz-torrent: url scheme, sure... I disagree with comment 12
in this respect, you can ignore protocol schemes just fine...

[Robert-accettura (raccettura)]

(In reply to comment #17)
> Note that Robert seems to be agreeing with me and Ian and disagreeing with
> Gerv... on the right-click issue (though he also seems to think that he's
> disagreeing with Ian).

No, I don't think I'm agreeing or disagreeing with anyone. I have my own
opinion ;-)

I just think a certain way about that issue. Not meaning to create sides in the
debate. Guess I wrote that in the wrong location of that comment.

[Gervase Markham (gerv-mozilla)]

> The moz-torrent protocol scheme wouldn't work quite like that. It would simply
> be a way of taking the information in the .torrent file and encoding it in a
> URI.

Problem is, .torrent files can often contain a lot of data. Isn't there a length
limit on URIs? Or would it not be a problem because it would only be internal?

Re: right-click, Ian's reasoning seems sound. Right-click should save the
.torrent file (and we should take the association so double-clicking it starts
the download). People are used to dealing with this with .m3u, so I guess they
can cope with it in this case.

Gerv

[Christian Biesinger (cbiesinger)]

(In reply to comment #16)
> Just a way of passing data from the
> application to the network layer.

The network layer needs not be involved here... I mean, in the end, this is all
just internal to the extension that implements all this; what does a protocol
handler gain you?

(well, if you decide you want one so that it can be used, things are different
of course (as opposed to "have to implement one to support bittorrent"))

[Bzbarsky (bzbarsky)]

> what does a protocol handler gain you?

Hmm... I guess you could write an nsIChannel impl (since download manager _will_
need that) and just give it the http:// (or whatever) URI and not have a
protocol handler at all...

So ignore what I said. Comment 11 is what should be done.

[Robert-accettura (raccettura)]

(In reply to comment #20)
> Re: right-click, Ian's reasoning seems sound. Right-click should save the
> .torrent file (and we should take the association so double-clicking it starts
> the download). People are used to dealing with this with .m3u, so I guess they
> can cope with it in this case.
>

A third path could be prompting the user that it's a BitTorrent download, and
ask if it should "save the torrent so you can download later", or actually
retrieve the download.

That might by considered UI bloat, but I just thought I would throw that out as
an idea. Not every user may be aware exactly what a .torrent is.

[Gervase Markham (gerv-mozilla)]

Robert: that doesn't really make BitTorrent downloads as easy to use as HTTP/FTP
downloads :-) I think we can assume that anything served as
application/x-torrent, just as anything served as application/octet-stream, is
for saving to disk. This narrowing of focus avoids a load of UI issues.

Gerv

[Andrea-monni (andrea-monni)]

Looks like BitTorrent is getting momentum, check this story on Slashdot:
BitTorrent Gains Corporate Support --
http://slashdot.org/article.pl?sid=04/03/17/0210237&mode=nested&tid=126&tid=187&tid=95

It seems that among companies required to distribute large quantities of data to
their customers BitTorrent is becoming very popular.

[Bartkuik (bartkuik)]

Most users will see the 'upload 150%' feature as a bug, because their internet
connection becomes less responsive after a couple of downloads, and they will
'fix' it by restarting the browser. For an end-user, it's the same as a memory
leak that forces you to restart the app from time to time.

[Gervase Markham (gerv-mozilla)]

Most users will see the 'upload 150%' feature as a bug, because their internet
connection becomes less responsive after a couple of downloads,

Why so? The load is on the outgoing, not the incoming side, which is hardly used
- and I'd hope we could find a way to give priority to non-Bittorrent outgoing
traffic.

Gerv

[Christian Biesinger (cbiesinger)]

(In reply to comment #27)
> Why so? The load is on the outgoing, not the incoming side, which is hardly used

in case that's uploading near the limit of the connection, that really does kill
download performance as well (and increases latency a lot)

[Robert-accettura (raccettura)]

As Gerv said, it would be ideal be able to throttle (most likely by percentage
like most P2P products).

Upload does increase latency. But of course that varies based on the connection
as well.

BitTorrent stinks for dialup users. But broadband users love it. If your on a
network at school or work, you love it even more (since many home broadband
providers have caps).

Then again... on a cable modem with a 3.5Mbps cap. Several downloads at the
same time severely effect my performance.... so should we prohibit multiple
downloads? Of course not. Let the user decide what they want to do.

As said earlier, BitTorrent has stratigic advantage. If certain users don't use
it. That's fine. I'm sure there are users who will never use tabs either. But
that doesn't defeat their worth. Many find them to be a great addition.

I know at school, I can use bittorrent with no real degration of performance.

[Phillip Stewart (phillip-stewart)]

http://bittorrent.mozilla.org:6969/

[billistic (billwalsh)]

I would love to see native bit torrent support within firefox.

Sure users might not understand that leaving the download open after helps
people download the file but, but that's what writing documentation is all about.

[Jon-latchkey (jon-latchkey)]

Seems like a good reason to support it. =)

http://in.tech.yahoo.com/041103/137/2ho4i.html

According to British Web analysis firm CacheLogic, BitTorrent accounts for an
astounding 35 percent of all the traffic on the Internet -- more than all other
peer-to-peer programs combined -- and dwarfs mainstream traffic like Web pages.

[Cgranade (cgranade)]

The last post I saw on this was a month ago. Is there a consensus that this sort
of a thing would be a good core feature for FF? If so, is someone already
working on it, or is it in need of developers?

As for my 2 cents, I would like to see this implemented, though I think that
some of the behaviors specified herein should be made as options (such as
whether to expose what pieces have been retrieved). Also of import would be the
ability to restore a partially downloaded torrent.

[Talez (talez)]

Indeed BT would rock as a core transfer protocol under Firefox.

I even created a mockup to how a BT transfer could look in the download box.

http://members.westnet.com.au/talez/firefoxbt.png

How I imagine it:

* User clicks on a link and it acts like a HTTP download
* Firefox tells the user how fast its coming down and going back up as well now
* Bittorrent *ONLY* uploads while a user is downloading
* There is a new link for BT downloads called "Support" which will keep seeding
the download until it has uploaded 100% of the download
* There should be new options in the prefs panel for auto-support, rate limiting
the uploads and possibly turning off uploading altogether
* As you can see it would for all intents and purposes look like a HTTP download
with a few minor differences

I think this would be the easiest and simplest way to implement in terms of user
participation and UI bloat. There is one extra data field and one extra link for
an extreme improvement in functionality.

I really think its something to aim for in 1.1

[Robert-accettura (raccettura)]

Unless someone steps up to take this bug soon, this is most likely a future bug,
than a 1.1. Simply because some serious testing will be needed.

[Waazup (waazup)]

* There should be new options in the prefs panel for auto-support, rate limiting
the uploads and possibly turning off uploading altogether

Turning off uploading would be leeching and would defeat the point of having
bittorrent. I advice against a feature that would allow for turning uploading off.

[Talez (talez)]

(In reply to comment #36)
> * There should be new options in the prefs panel for auto-support, rate limiting
> the uploads and possibly turning off uploading altogether
>
> Turning off uploading would be leeching and would defeat the point of having
> bittorrent. I advice against a feature that would allow for turning uploading off.

With the rise of bt being used for legitimate downloading, it might not be as
taboo as it once was.

Who cares about Joe Blogs and his 16K/sec of upload when fileplanet has 400
megabits behind a torrent.

[Ian-hixie (ian-hixie)]

The whole point of bittorrent is the upload, if we allow that to be disabled we
might as well not support it, since it just becomes the same as HTTP at that
point. However, I do think we should default to limiting upload to some 3kb/s or
some such, so as to not ever hit anyone's ADSL upload limit (and thus throttling
their download).

[Jon-latchkey (jon-latchkey)]

Hi everyone!

I think that if Mozilla is going to support this in the download, it should also
 eventually support downloads transparently as a file handler as well. Why not
share those caches we all have on our hard disk that were originally received as
a public url?

For example:

<img src="bt://public.server.com/url/to/image.torrent" />

If this grows in popularity, I could see this affecting the usefulness of
services such as Akamai. Do torrents have mimetype information inside of them so
that the browser would know to render that torrent as a jpeg?? =)

jon

[Darin-moz (darin-moz)]

Hmm... making bittorrent easy for all users is a challenge. You still have to
help the user figure out how to open the necessary ports on their router :-/

[Tuukka Tolvanen (sp3000)]

Jari, the point of my comment was that
     a) shifting the user agent to transparently use the user's resources beyond
fulfilling the individual user's requests can reek of hijack; if its done, the
perceptional issue does need to be dealt with regardless of any moral
implications of the user's behaviour. ("Why does my Internet become teh slow
after downloading some files with Firefox, that doesn't happen with IE")
     b) the extent to which "giving back" is appropriate is not necessarily
constant across torrents

That said, I'm looking forward to it :)

[Gervase Markham (gerv-mozilla)]

Jari: I very much hope your application succeeds. I should note that if you
build BitTorrent support with libTorrent, it will need a licence change from GPL
to something compatible with our tri-licence. If you are the only contributor,
of course, that would not be a problem :-)

Email me if you need more info on this.

Gerv

[Sundell-software (sundell-software)]

I'm aware of the license issue, and will change it to LGPL if needed.

[Gervase Markham (gerv-mozilla)]

Jari: LGPL alone is also not compatible with the MPL. Compatible licenses
include the MPL/LGPL/GPL tri-licence, MPL/LGPL dual licence, and most variants
of BSD. As I said, email me if you need to discuss this.

Gerv

[Littlecritter (littlecritter)]

Hi everyone. Like Jari, I submitted a Google Summer of Code proposal for
implementing BitTorrent in Mozilla. My proposal was accepted, so I could only
assume that Jari unfortunately didn't get the job.

I have just finish trawling through various BitTorrent blog posts and bug
reports on bugzilla collecting whatever information and issues that were
discussed. It seems everything that's worth mentioning has already been
mentioned. Short of looking at actual Mozilla code, here are my thoughts on
implementing this:

-Initially, BT should only be supported in the download manager. Basically what
gerv said in comment #1.
-At this stage, I think an extension would be best. Eventually, I'd like to see
it merge into trunk.
-There will most likely be changes needed to necko, like to support throttling
and packet prioritising. Of course, these are optional, but if they're not done,
then we will have an inferior client. There might be other API changes needed as
well.
-The download manager UI really needs an overhaul.
-Downloads should survive between browser sessions...

With regards to download manager, throttling and downloads between sessions,
they seem to be on the agenda for Firefox 2.0. I think it would be good if there
is some sort of coordination with this and that effort.

So those are my first thoughts on implementing at the moment... too dizzy after
reading so much :)

[Timeless-bemail (timeless-bemail)]

fwiw some priority support was introduced by bug 278531

[Gervase Markham (gerv-mozilla)]

Ben Goodger has recently overhauled the download manager UI. If you are planning
significant changes, you need to coordinate with him.

Gerv

[Kevin Brosnan (kbrosnan)]

*** Bug 299866 has been marked as a duplicate of this bug. ***

[Betbest1 (betbest1)]

Opera now supports BitTorrent in the new version. See this URL:
http://www.betanews.com/article/Opera_Adds_BitTorrent_to_Web_Browser/1120670921

[Gervase Markham (gerv-mozilla)]

This development is now the mozdev.org "firepuddle" project:
http://firepuddle.mozdev.org/

Gerv

[Ali-ebrahim (ali-ebrahim)]

*** Bug 300766 has been marked as a duplicate of this bug. ***

[Zephyrxero-gmail (zephyrxero-gmail)]

I don't know if this has been mentioned already (78 posts is alot of reading),
but a good reason why this feature should be supported as an extension is so
that people can easily take it off if they want to use a different client for
BT. I do think it should be included with the standard version of FF though,
like the DOM inspector used to.

Also, as far as the using of bittorrent for webpages discussion goes... Has
anyone thought of offering their sites as a zip file for each page? Any embedded
objects (images, audio, flash, etc) could be included in this single file along
with the HTML and downloaded via bittorrent, then decompressed and used like a
regular site at render time. This may not be necessary for small/simple pages,
but popular sites with lots of pictures would definitely benefit when a high
traffic site, like Slashdot, links to it. Although Coral and Dijjer are already
trying to deal with this in their own ways...

[Elfguy (elfguy)]

I really disagree with this feature request, for 2 reasons. First, Firefox is
meant to be small and efficient, leaving most unnecessary features to extensions
and plugins. Adding bittorrent would not help normal users who never use BT, and
would not help power users since the implementation would most likely be very
basic and the power users would continue to use 3rd party programs anyways.

Second reason, BT is a very problematic protocol. It's hell with firewalls and
routers, because it needs both upload and download, at large port ranges,
leading to tons of user complaints about problems. Also most ISPs have bandwidth
limits, meaning many people decide not to use BT. Having it built in Firefox,
especially as the reporter suggest (being hidden and continue to upload past
100% without user consent) is a terrible terrible idea.

So no thanks, tons of bugs to work on anyways.

[Robert-accettura (raccettura)]

The bottom line is it's no more offensive than FTP (which we currently support).
 We could make the same arguments to drop FTP support from Firefox, since it is
a _browser_ not a download manager.

[Darin-moz (darin-moz)]

> The bottom line is it's no more offensive than FTP (which we currently support).
> We could make the same arguments to drop FTP support from Firefox, since it is
> a _browser_ not a download manager.

No way! FTP is core to the web browser -- always has been. Moreover, passive
mode FTP has none of the firewall issues that plague BT. I have to agree with
comment #81 completely. The solution in comment #41 is only good for a very
small number of users. How many normal people can and will configure their
router even when given a guide to follow?

By the way: Please, please don't spam this bug with any YAY or NAY comments! ;-)

[Jqshenker (jqshenker)]

While I personally think BitTorrent should be implemented as an extension (what
are the cons to those who DO use it? People who don't aren't bothered.)

But, I wanted to throw out a ***crazy*** idea. Just seeing if anyone is interested.

Imagine an extension that allows clicking on a .torrent file and it shows up in
the download manager, downloading and seeding (for a user-specified time
afterwards, say three hours). But!!! (this is the good part) If your download a
>300mb (or >1gb, whatever) file, it publishes that file (distributed tracker,
azureus-style) as a torrent using a DHT service such as OpenDHT for rendezvous.
Whenever anyone else somewhere else tries to download that file, it first looks
the tracker (looks the file up in the DHT). If there is none, it does the above
(it creates one). If there is one, it either:
-Downloads the file normally and then seeds
-Downloads the file using the torrent, seeding normally
depending on how fast the torrent would be (how many seeders, if there are few,
downloading normally would be much faster)

This would create a network of firefox-powered torrents of popular big files on
the web, reducing server load, completely automatically. Provisions would be
made so only popular files were torrent'ed, so billions of torrents didn't
clobber the DHT. Why isn't this possible? (not integrated into the browser, as
an extension!!!) I know someone will tell me I'm nuts, but really, why isn't
this possible.

Jacob

[Arthur Wiebe (artooro)]

Jacob,

Like you said it's a crazy idea while technically it is possible to do.
But I believe this bug is about supporting the BitTorrent protocol in Firefox
not about all kinds of neat extensions about BitTorrent.

[Jqshenker (jqshenker)]

Gotcha.

[Jon-latchkey (jon-latchkey)]

Interesting...

http://allpeers.com/more_f.htm

AllPeers is a free extension which combines the strength of Firefox and the efficiency of BitTorrent to transform your favorite browser into a media sharing powerhouse.

Regain control! You decide which media files you want to share with whom and to maximise your privacy, communications are encrypted.

[Ian-ianmacfarlane (ian-ianmacfarlane)]

This should probably depend on bug 230870.

[Matt Walker (matthaeus123)]

I really do not like Allpeers. There is a project in the planning phase called "Firestorm". It will be an extension, which lets firefox use bittorrent.

[Declan Naughton (piratepenguin)]

(In reply to comment #89)
> I really do not like Allpeers. There is a project in the planning phase called
> "Firestorm". It will be an extension, which lets firefox use bittorrent.

AllPeers is non-free anyhow. Can you post some information about Firestorm? The 2 efforts I found via google to bring BT support to Mozilla have been abandoned.

They are:
http://firepuddle.mozdev.org/
and http://moztorrent.mozdev.org/

The first one has a good bit of coding done (and it would seem as though it was nearly basically working at a time - see the download page). I'd seriously look at making it work with trunk, but it apparently only runs on Windows which I don't have access to and it's written in C++, where I only code in Javascript w/ XPConnect.

This would also be useful for other XULapps btw, such as Songbird. Votes++

[Matt Walker (matthaeus123)]

Firestorm project should have their initial release in the next cuple of days. This is probably the first promising bittorrent extension project I've seen.

http://firestorm.mozdev.com/

Maybe Mozilla could be able to help maintain the extension. It is all written in python XPcon.

[Dzbarsky (dzbarsky)]

Also, <a "href=http://www.foxtorrent.com/">foxtorrent</a> is an extension that does this.

[Matthew-gertner (matthew-gertner)]

Just a quick note that we now have a fully fledged BT client in AllPeers (see http://www.techcrunch.com/2007/09/09/allpeers-preview-for-techcrunch-readers/). We're definitely motivated to extend and improve this. The whole implementation is open source and based on the Mozilla stack (NSPR, NSS, XPCOM, etc.).

[Sokingu (sokingu)]

Couple of questions (I already contacted the Q-A contact on this bug but he couldn't help):

1) Has a decision been made to add bittorrent support to firefox or have it as an extension?

2) Is there a possibility that a patch would be accepted if it requires the boost library? (I have been suggested to ask this on .platform and I'll do if I don't get an answer here).

[Gervase Markham (gerv-mozilla)]

I think it's unlikely a patch would be accepted without having first been proved as an extension, so I would encourage anyone with interest to look at doing that first.

Gerv

[Matthew-gertner (matthew-gertner)]

Let me just reiterate what I said in https://bugzilla.mozilla.org/show_bug.cgi?id=236755#c93 : we have a full BT implementation that is open source and based on NSS. It's kind of bound up with the rest of our framework, which probably isn't going to get into the Mozilla proper any time soon, but if someone is contemplating a truly Mozilla-compatible BT suitable for inclusion in Firefox, I'd strongly encourage you to take a look. I'd be very open to discussions about how to factor out the BT functionality from other AllPeers dependencies.

[Matti-mversen (matti-mversen)]

*** Bug 478984 has been marked as a duplicate of this bug. ***

[Ryan Prior (ryanprior)]

Binary package hint: firefox-3.0

The Firefox download manager does not handle .torrent downloads.

Steps to reproduce:
* Navigate to a popular torrent site such as thepiratebay.org
* Search for "Big Buck Bunny" and click a relevant result
* Click the link to begin the download

Expected result:
* Firefox downloads Big Buck Bunny, as it would using HTTP or FTP

Actual result:
* Firefox downloads the .torrent file, offering to pass it on to Transmission.

Notes:
* This behavior is confusing to anyone who is not familiar with bittorrent, ie the "humans" for whom Ubuntu is designed.

[Daniel Aronoff (da0487)]

Thank you for taking the time to make Ubuntu better. Since what you submitted is a Feature Request to improve Ubuntu, you are invited to post your idea in Ubuntu Brainstorm at [WWW] https://brainstorm.ubuntu.com/ where it can be discussed, voted by the community and reviewed by developers. Thanks for taking the time to share your opinion!

Also, there are add-ons to handle your request. Check out addons Foxtorrent and Firetorrent
http://www.raymond.cc/blog/archives/2007/06/16/download-torrent-files-in-firefox-foxtorrent-and-firetorrent-review/

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Ubuntu Bug:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/339772

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:
https://bugzilla.mozilla.org/show_bug.cgi?id=236755

[Comsultia, Ltd. (open-comsultia)]

would be nice have supported torrent protocol in HTML5 video tag:
<video src="torrent://">

[Jo-hermans (jo-hermans)]

(In reply to comment #99)
> would be nice have supported torrent protocol in HTML5 video tag:
> <video src="torrent://">

Do you realize how long it would take to display such a page ? This bug is about the download mechanism, where you let the download run for hours if needed.

See bug 203571 comment 13 why this would be a bad idea.

[Comsultia, Ltd. (open-comsultia)]

I'm talking just about video source as bittorent, not HTML pages or jpeg.
Video traffic is a presently typical problem of VoD services and internet providers.
Will be very nice to have in Mozilla integrated player support for play bittorent video during download. Yes, and it's technically possible.

Inspired by Joost for example, and others internet p2p video services.

[Cjcypoi02 (cjcypoi02)]

(In reply to comment #101)
Sorry "Comsultia", but IMO it's a nonsense. Embedding is used if the download speed is high - and p2p is not always fast - and/or you want the user can only see the video, and not store it on HD.

Furthermore you have not read carefully bug 203571 comment 13:

> [...] it's not a good idea to bind this embedding process to BitTorrent,
> because every "BitTorrent connection" has a lifespan which need to be
> specifed by the user himself. A file keeps being uploaded after its download
> completes within BitTorrent, until the user decides to "finish" this file. If
> a video embedded into a webpage is downloaded via BitTorrent, when should the
> upload of this same video stop? Immediately after the download completes? Or
> when the user leaves the website? Both are rather too soon to keep the file
> healthy alive.

[Antoine Turmel (antoineturmel)]

These three projects seems dead :(

http://moztorrent.mozdev.org/
http://firepuddle.mozdev.org/
http://firestorm.mozdev.org/

Still it would be awesome to have a torrent library for XULRunner

[Chris Hubick (hubick)]

(In reply to Comsultia, Ltd. from comment #99)
> would be nice have supported torrent protocol in HTML5 video tag:
> <video src="torrent://">

I would like to see this too, but also supporting the new "magnet:" style torrent links.

Discussion proposal, answering questions raised by bug 203571 comment 13:

I think, regardless of protocol, referencing *any* file over a certain size within a video (or img, etc) element could result in the opening of the download manager, with that content being added to the active downloads (giving the user some opportunity to cancel the operation), ie, what happens if someone does <video src="http://2_gigabyte_video.webm"> on a HTTP/1.0 server that doesn't support range requests? I would expect any large content being downloaded could be shown in the download manager and also play within the page element as that data becomes available. I would expect such downloads to be automatically be terminated if the user navigates away from the download-spawning page.

I think, again regardless of protocol, the Firefox video UI displayed within the page has/needs some way to provide status for buffering, streaming stalls, etc, and the page level torrent UI could be handled using the same mechanism. I don't think elongated startup display times would be a problem as long as the user is provided status information ("connecting to server/tracker...", "downloading/buffering...", "estimated time till playback begins: unknown/1 minute", or some such).

Similarly, I would expect referencing a torrent file from a video tag to result the download manager being opened and having that torrent added to it's active downloads. I would expect the embedded torrent client to have user prefs for seeding/sharing/ratio/lifespan, like any other torrent download software. I would expect the embedded client to be patched with the ability to attempt to download chunks somewhat in order (ie, try to download the beginning of the video first).

If there is a 10MB video on a page, regardless of whether you watch the whole thing or just the first 10%/1MB before navigating away from the page, I would expect the torrent client to seed the content you did download until you reach the regularly configured share ratio. And, again, I would not expect any remaining content to be downloaded after you navigate away from the page, unless you resume the downloaded manually within the manager, perhaps so you can save the content upon completion for later viewing.

Video content is becoming increasingly popular on the web, and users today are confined to big providers like YouTube who can afford the servers and bandwidth required to support distributing such content. This restricts the ability of small individuals to create and distribute large multimedia content. While embedded torrent support might not be as seamless/ideal as other mechanisms, it does give *everyone* the freedom to become their own YouTube, and I hear that's what Firefox and the Open Web are all about.

[Nmaul (nmaul)]

Perhaps we can jump-start this bug back into actionable-land if we narrow the scope... what would it take to have basic, functional BitTorrent support for downloads? Not HTML embedded content, just downloads. I think the idea of supporting HTML5 video downloads is interesting, and worth pursuing, but if we set our sights on that we might never get off the ground at all (as evidenced by this bug being 9 years old, with basically zero progress).

We would like to use this for Firefox's built-in updater over in bug 596839. It has the potential to save Mozilla a *lot* of money. My gut reaction is that this is a feature which could pay for itself, fast.

So... what kind of time investment are we talking about here?