Note: this is _not_ a duplicate of bug 203571. There is strategic value to mozilla.org in building in support for the BitTorrent protocol to Firefox and Mozilla, so that a user can click on links to .torrent files and have the file downloaded seamlessly in the Download Manager. 1) We could set up trackers for new Firefox/Mozilla versions, and it would ease the load on our download servers. 2) Content providers love BitTorrent because it saves them bandwidth. If we support it natively, our users will get a much better download experience than IE users hitting overloaded servers via HTTP for the latest hot download. This view is held by a lot of people - see the dupes of bug 203571. Unfortunately, a slightly over-excited initial comment and a rather confused discussion in that bug led to it being WONTFIXED, and any bug which mentions BitTorrent has been duped against it ever since, even if it has different ideas. My suggestions is roughly what Henry James, BitTorrent developer, is thinking of in bug 203571, comment 13, paragraph 5. Mozilla should handle files of type application/x-bittorrent internally, just like application/octet-stream - except that it would download the tracker file, and then download the referenced file using the BitTorrent protocol instead of HTTP.
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
> 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.
*** Bug 203571 has been marked as a duplicate of this bug. ***
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?
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?
(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.
> 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
> 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).
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.
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.
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?
> 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. ;)
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.
> 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.
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.
> 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.
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.
(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...
(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.
> 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
(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"))
> 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.
Whiteboard: See comment 11
(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.
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
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.
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.
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
(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)
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.
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.
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.
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.
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.
* 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.
(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.
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).
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
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 :-/
(In reply to comment #40) > 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 :-/ The solution for that is to wait about 2-4 minutes. If upload is non-existant, then prompt the user that they may need to open up a port in their firewall, and redirect them to a Mozilla Help page modeled after: http://userpages.umbc.edu/~hamilton/btclientconfig.html which should contain a notice that they may need to "contact their network administrator". that's the best we could do. Regarding upload... we should offer the ability to throttle, but not turn off, as the FAQ states, you are tit-for-tat with peers.
There is always the potential concept of 'fallback uri's'.... <img src="bt://uri/ , http://uri/" /> jon
As mentioned before, <img src="??(bittorrent link)??"/> are not possible/useful. First, "fallback" is not a standard HTML feature (correct me if I'm wrong), so that page would not work in any browser. Breaking compatibility is the opposite of what Open Source tries to do. Second, BitTorrent takes some time to initialize download (overhead). We would gain nothing but slow down the page loading process. In would be useful only for, let's say, >a few MBs, images. Those are usually linked to, not embeeded on page, as they contain data not everyone is interested in (let's say some scientific data or photographs); there's still no problem to offer an image over BT, it's just an ordinary binary file in this case.
> If upload is non-existant, then prompt the user that they may need to open up a > port in their firewall, and redirect them to a Mozilla Help page modeled after.. good luck explaining that to a typical user. the "firewall problem" means that it will be very difficult for this to ever be more than a fringe feature, enjoyed by a relative minority of our userbase. an extension would be more appropriate imo.
Darin: are there not now firewalls where you can request it to open a port for you? Some new feature in Windows XP, I believe. I forget the name. If that becomes widespread, the problem might be mitigated. But I agree, an extension is probably the best place for this code to start off. Who knows what would happen after that? Gerv
(In reply to comment #45) > Darin: are there not now firewalls where you can request it to open a port for > you? Some new feature in Windows XP, I believe. I forget the name. > I think your referring to UPnP.
Will everyone stop overcomplicating things? Why the hell are we putting torrent links inside IMG tags? To integrate this successfully you need to do two things: 1) Maintain the status quo 2) Make it better (1) Just treat it like it always has been with .torrent files on webpages. (2) If you click on a link Firefox loads up the torrent internally and downloads it as if it was another bittorrent client. (1) No port forwarding info. It'll just confuse people. And ISPs are going to cop the brunt of the **** from stupid idiot users. (2) Put uPnP support if you want. As more people get uPnP capable equipment the number of zero config uploaders will increase. (1) For the 99% of legitimate downloads out there, people not uploading won't mean ****. Sure it'll be nice but it won't be so mission critical to have uploading like if you were trying to distribute an anime sub or the like. It's not like people downloading over HTTP contribute anything already. (2) With the integration we'll have a nice distributed, multihomed file transfer method integrated into one of the most popular up and coming browsers. There. I've said my piece. You can all go back to bitching about non-uploads and trying to put bloody torrents inside <IMG> tags now.
A few short points on the topic: 1) UPnP is not a feature, but a security hole. I don't know that I believe that Firefox should be in the position of reconfiguring people's networks, transparently or not. If BT is blocked, then the user is going to be kinda hosed. 2) One of the largest points of the BT protocol is to decentralize the load on a server. By offering the option to disable uploading, one of the most fundamental assumptions of the protocol is no longer valid. Many clients will deny bandwidth to those who throttle uploads, thus causing many potential problems for Firefox BT users. 3) Though a BT would not be of any use to inside an IMG tag, it might be of great use inside an EMBED tag (for Flash, QT or Java). Thus, the issue of how to implement a BT link inside of a predefined HTML tag is non-trivial. 4) Firefox need not implement a pure BT client, but could also implement a client for XML serialized torrents, such as those generated by Azerus. These XML torrents could then be embedded into the page, or linked by virtue of a <link type="torrent" rel="http://path.to/torrent/" /> entity. Now that I've ranted my two cents worth, let me offer a few implementation suggestions for the HTML side of things. By using XML namespaces, we can identify BT related information as being seperate from standard XHTML 1.0 tags. For instance, an <a /> or <embed /> entity could have a new attribute bt:btref which links to a standard or XML torrent (determined from MIME type) which can be used to download the content. In that way, the standard href or src attributes act as a fallback URL. Browsers which don't understand BT could safely ignore the bt:* attributes. As an example, consider the behavior of the following hypothetical tag: <a href="http://example.com/largefile.swf" bt:btref="http://example.com/largefile.swf.torrent">test</a> Upon clicking the link, Firefox should (depending on user preferences): 1) Automatically begin downloading largefile.swf using HTTP. 2) Automatically begin downloading largefile.swf using BT. 3) Ask the user how to download the file. Thus, the user is still in control of downloading, we have not confused a torrent file with what it points to (since <a href="http://example.com/largefile.swf.torrent" /> would not invoke Firefox's BT client unless explicitly passed), and we have not overly confused non-BT aware browsers. Furthermore, no web standards would have been harmed in the process.
One quick note about the uploading issue: I belive that we must support some kind of limited-bandwidth upload, it just wouldn't be right otherwise. However, files should only be "uploadable" when the following is true: 1. The files are still available in the original downloads folder. -and- 2. The files are listed in the Downloads window. This would make it easy for users to monitor the files that are being uploaded, and won't require any major changes in the UI. Prog.
1. we are not making up/creating a BitTorrent protocol, we are implementing the existing protocol. 2. we are not modifying/creating HTML specs, we are using already existing specs.
Agree with comment #50. Mozilla should just start down/uploading the file when it receives a file with MIME type of "application/x-torrent". Torrent file can be used in HTTP(S) and FTP protocol. It should not be used in elements like <img>, <embed>, and <iframe>. And in case of <object>, I don't like the browser should render the file inline as well.
Why must you people needlessly complicate what should be a simple process?(In reply to comment #51) > Agree with comment #50. Mozilla should just start down/uploading the file when > it receives a file with MIME type of "application/x-torrent". Torrent file can > be used in HTTP(S) and FTP protocol. It should not be used in elements like > <img>, <embed>, and <iframe>. > > And in case of <object>, I don't like the browser should render the file inline > as well. Exactly. Could all the people who must insist on creating a whole new way of download torrents that would be needlessly oomplicated please create their own bug to have a "new standard" circlejerk in. Thank you.
It would break the web to use torrents in html itself. Torrents take a while to find other hosts to download from. They are not reliable (require many people downloading at the sime time to be reliable). They aren't a way to host the web. They aren't in the specs. I think that's enough conversation on the topic. If anything, such talk should be directed to the w3c, not Mozilla. **Please refrain from more comments on modifying specifications. This bug is for someone who wants to implement the protocol in firefox.**
(In reply to comment #53) > It would break the web to use torrents in html itself. > > Torrents take a while to find other hosts to download from. They are not > reliable (require many people downloading at the sime time to be reliable). > > They aren't a way to host the web. > > They aren't in the specs. > > I think that's enough conversation on the topic. If anything, such talk should > be directed to the w3c, not Mozilla. > > > **Please refrain from more comments on modifying specifications. This bug is > for someone who wants to implement the protocol in firefox.** Exactly. Let's just turn it into HTTP/FTP replacement its just begging to be already. The core reason this is so good and so "just begging to happen" is that big sites can get together to distribute bandwidth between them. Users uploading back to the network would just be icing on the cake.
And when I say the HTTP/FTP replacement I mean for downloading large files, not serving the whole freaking web :D
I'm sorry I wasn't more clear. No need to start flaming. What I was suggesting was a discussion to think about all of the things that people might bring up if we implement this protocol within Mozilla. I think it is very important to at least think ahead and not just focus on providing minimal implementation of BT for just downloading files. In case one hasn't noticed, it is entirely possible to do <img src="ftp://" />. I'm not talking about replacing HTTP/FTP, I'm talking about adding an option to HTTP/FTP. Why not HTTP/FTP/BT? Even in the specs, the src="" attribute is a URI, not a URL which makes me want to believe that the Founding Fathers wanted to make sure that 'The Web' lives longer than just HTTP/FTP does. I also agree that if we are going to talk at the 0 foot implementation level, the idea that using namespaces would most likely be the right way to go because as we all know, backwards compatibility is the right way to go. BT is useful for downloading data. As it progresses as a protocol through better client implementations, it will get even more useful for doing so. Newer features of clients (Azureus has this) like asking for pieces of the data with its starting sequence makes it possible to allow previews of data and display of images more quickly. Sure, BT might be slower than HTTP/FTP at first, but lets think down the road a bit. The imense popularity of BT will encourage people to improve upon it (just like Mozilla has gained in popularity/features as well...). Clearly others are thinking about these problems... swarmstreaming has sequenced pieces as well for previewing ability... http://onionnetworks.com/technology/swarming/ I agree, uploading should not be disabled...but as soon as people have all this data sitting in their downloads folder (and they happen to have the right ports open), why the heck should we not make that information anonymously available to others? Lastly, no, I don't think any of this needs to be in the first release of Mozilla's BT client implementation. But, let's keep an open mind towards versions 2,3,4,5,6 as well and keep our attitudes positive about this exciting turn of events and not flame driven. thanks, jon
Please don't use bugzilla as a discussion forum. If you want something more than the subject of this bug, which is "Support BitTorrent as a file download mechanism", for example "Support BitTorrent in [IMG|EMBED|OBJECT|whatever] tags" or "Extend BitTorrent to create a new protocol", open another bug saying exactly that. Make it dependent of this one if you want (it should be done before anyway), and let people who want/are able to implement it do their job here. Thanks.
> My suggestions is roughly what Henry James, BitTorrent developer, is thinking > of in bug 203571, comment 13, paragraph 5. Mozilla should handle files of type > application/x-bittorrent internally, just like application/octet-stream - > except that it would download the tracker file, and then download the > referenced file using the BitTorrent protocol instead of HTTP. Excuse me? Which part of my comment is "rougly" what you're suggesting now? Especially in the paragraph 5 you refer to, I made clear there are fundamental problems for Mozilla to "silently" handle BitTorrent downloads. So, for the protocol, I am absolutely *against* your suggestion of Mozilla handling the BitTorrent protocol internally. Actually I cannot even believe anybody would come to any different conclusion after reading my said comment.
And again for the protocol, I suggest WONTFIX for this "bug".
(In reply to comment #58) > So, for the protocol, I am absolutely *against* your suggestion of Mozilla > handling the BitTorrent protocol internally. Actually I cannot even believe > anybody would come to any different conclusion after reading my said comment. After reading both comments, it seems to me like you're both asking for the same thing but with different phrasing. Perhaps it is Gerv's use of the word "internal" that is causing confusion, but my understanding is that he is suggesting that the current download manager handle torrents, just as you suggested having a "sidebar" in the referenced paragraph.
Yes. I am suggesting that the Download manager handle torrents, and that the browser make it appear to the user as no more complicated than FTPing the file. The browser would handle all the details, and would feed back into the network as long as it continues running, dynamically managing bandwidth to make sure the user's use of their net connection was not impaired by the uploading. (This doesn't have to be complicated - measuring the bandwidth and using 50% would work fine.) The underlying idea here is to make .torrents accessible to your average Firefox downloader, who doesn't want to have to mess with helper apps, configuration, bandwidth management, ratios etc., without breaking the reciprocal nature of Bittorrent. Reread comment #1 for an expanded version of this explanation. Gerv
I'm curious if bug 142255 (provide a way to prioritize connections) could in any way benefit this. Perhaps give BitTorrent a lower priority once downloading completes. This would encourage the user to keep bitTorrent going longer (won't impare performance), while still providing some bits for other torrent downloaders. Just a thought.
Personally, while the techie in me thinks it'd be nifty to have BT be an alternate protocol, I agree that it doesn't make much sense practically. On the other hand, making BT accessible to Joe Blow is /not/ a bad thing. If Firefox could implement this as another means of downloading, then I think that would be a very good thing indeed.
(In reply to comment #60) > After reading both comments, it seems to me like you're both asking for the > same thing but with different phrasing. Perhaps it is Gerv's use of the word > "internal" that is causing confusion, but my understanding is that he is > suggesting that the current download manager handle torrents, just as you > suggested having a "sidebar" in the referenced paragraph. Please read my old comment again and see I explicitly recommended a Mozilla *plugin*, if anything, to handle BitTorrent download. Yes, I mentioned the sidebar as a possible location for this plugin, but a plugin is definitely the *opposite* of "internal".
(In reply to comment #61) > Yes. I am suggesting that the Download manager handle torrents, and that the > browser make it appear to the user as no more complicated than FTPing the > file. And the obvious question is: Why BitTorrent? Why not any of the other dozends of protocols out there? Why is BitTorrent so important for a *webbrowser* that it requires internal handling (as opposed to via a plugin)? It's not like I think BitTorrent weren't important (or I wouldn't be a member of the dev team), but a webbrowser definitely doesn't need it that badly. > The underlying idea here is to make .torrents accessible to your average > Firefox downloader, who doesn't want to have to mess with helper apps, > configuration, bandwidth management, ratios etc., without breaking the > reciprocal nature of Bittorrent. Think about this: If your idea gets implemented (and let's assume it's implemented well), how many users would use it? Your "average" web surfer doesn't need BitTorrent at all. There is nothing my parents needs to download which they can only get via BitTorrent. And of those who do need BitTorrent (one third of all Mozilla users max, I'd say), the heavy users still won't use Mozilla for it, since they all have their dedicated BitTorrent clients configured the way they like it (upspeed and share ratio are too important parameters to be left to default or automatic setting). So your targeted users group is those who do need BitTorrent but only casually. That's a very small group, I assure you. No way this could justify a bloat of the Mozilla core, considering even calendar and IRC have been removed from the Mozilla core (and very right so). Frankly, I (and many I know) don't even use Mozilla's download manager for HTTP/FTP downloads of large files (anything that takes more than 5 min, so the exact size depends on the bandwidth) because of the lack of a resume function (so wget comes to rescue). And with BitTorrent, there are only large files...
> Why BitTorrent? Because it makes up about 1/3 of all the data traffic on the Internet, so could therefore be said to be reasonably relevant to an application whose key function is obtaining files across the Internet? ;-) http://www.wired.com/wired/archive/13.01/bittorrent.html?tw=wn_story_top5 > Your "average" web surfer doesn't need BitTorrent at all. Not right now, perhaps. It's chicken and egg. > There is nothing my parents needs to download which they can only get via > BitTorrent. Quite possibly not. But there are a lot of distributors out there (*cough* mozilla.org *cough*) who would _love_ your parents, and 20,000,000 other people just like them, to get their product using BitTorrent rather than FTP, because they'd save a fortune in bandwidth. But they won't bother setting up a .torrent until at least some of the visitors have clients which will download them without leading to an increase in support calls. > And of those who do need BitTorrent (one third of all Mozilla users max, I'd > say), One third of users is a mainstream feature. We have many features which are used by a much smaller proportion than that, even in Firefox. > (upspeed and share ratio are too important parameters to be left to default > or automatic setting) I'd say we are aiming to make it possible for people to download files over BitTorrent who wouldn't understand sharing ratios if you spent ten minutes explaining them. :-) Gerv
fwiw, I think for Gerv's proposed primary scenario (forgive me if I mis-summarize), "Help distributors convert from HTTP to BT downloads to save bandwidth without incurring extra user support costs", it's out of the question to consider stealing (as in, using without informed consent) the user's resources for someone else's benefit after the user's goal (download complete) has been reached. For caring users, prefs to continue seeding should be supported, perhaps with discoverable UI (maybe akin to Malcolm's "Support" link) to get curious users to effortlessly become such caring users.
Tuukka, you are aware that the user is using the resources of others to download the file? Downloading from others without uploading the same amount could according to your logic be considered stealing. Something might happen with this bug request if my Google summer-of-code application is accepted. I'm the author of http://libtorrent.rakshasa.no/, Though i have no prior experience with the mozilla code-base nor XPCOM/XUL programming.
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 :)
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
I'm aware of the license issue, and will change it to LGPL if needed.
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
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 :)
fwiw some priority support was introduced by bug 278531
Ben Goodger has recently overhauled the download manager UI. If you are planning significant changes, you need to coordinate with him. Gerv
*** Bug 299866 has been marked as a duplicate of this bug. ***
Opera now supports BitTorrent in the new version. See this URL: http://www.betanews.com/article/Opera_Adds_BitTorrent_to_Web_Browser/1120670921
This development is now the mozdev.org "firepuddle" project: http://firepuddle.mozdev.org/ Gerv
*** Bug 300766 has been marked as a duplicate of this bug. ***
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...
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.
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.
> 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! ;-)
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
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.
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.
This should probably depend on bug 230870.
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.
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.
Also, <a "href=http://www.foxtorrent.com/">foxtorrent</a> is an extension that does this.
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.).
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).
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
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.
would be nice have supported torrent protocol in HTML5 video tag: <video src="torrent://">
(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.
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.
(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.
Assignee: file-handling → nobody
QA Contact: ian → file-handling
(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.
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?
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.