This is neat, but what we really need is BitTorrent over WebRTC, for actual decentralized BitTorrent in the browser. See http://webtorrent.io
The project's goal is to build a browser BitTorrent client that requires no install (no plugin/extension/etc.) and fully-interoperates with the regular BitTorrent network. We use WebRTC Data Channels for peer-to-peer transport.
WebTorrent is designed to match the BitTorrent protocol as closely as possible, so when the time comes, existing BitTorrent clients can easily add WebRTC support and swarm with web-based torrent clients, "bridging" the web and non-web worlds.
WebTorrent is already working as a node.js bittorrent client (just do `npm install webtorrent -g` and use the `webtorrent` command), and as a web-based client (though the docs for this latter part are currently very lacking -- this will improve in the coming days!).
Nice! Why not create a different protocol then if they're not yet compatible? Adoption for a browser-based p2p streaming tool should be seamless. If the only problem is BitTorrent integration, go your own way.
Site is back up! I set up TLS today and made DNS changes. :)
> Why not create a different protocol then if they're not yet compatible?
I want existing bittorrent clients to add WebRTC support. The task of convincing the existing clients to do this will be a lot easier if the protocol is unchanged except where absolutely necessary to accommodate the WebRTC signaling (peer introduction) process.
I don't want to get distracted by trying to improve the BitTorrent protocol itself. It works quite well, despite not being the most elegant for implementors.
The strength of Bittorrent comes from the network. If you start with little to no peers, you will have a hard time convincing users to migrate. If you can leverage the existing Bittorrent network, you will be able to build something meaningful much more easily.
And the likelihood of that integration is unlikely. Just because WebRTC operates over TCP does not mean it acts anything like a proper TCP socket. There is an unbelievable amount of overhead involved, not to mention how reliant most modern torrent work can be on UDP nowadays. It simply can't scale, it might be good enough, but it can't scale. In-client WebRTC 'support' would nearly mean an entirely different stack, built on WebRTC's clunky non-standards and take years of proper testing. Why go through the effort? And hell, torrent clients are bloated enough already.
And let's not even get started on the comparable differences in security (personal or code-wise) when running this all through Javascript training wheels, then through the browsers' secret optimization sauce, browser/plugin fracturing, then through the gamut of ads, fingerprinting, cookie drops, and who knows what else kind of tracking can be slipped in from here forward... Let's call it what it is; a cool, non-commercial, in-browser p2p file sharing protocol, not BitTorrent.
Just to further this point: AFAIK, The BitTorrent protocol was not designed in order to stream content in any kind of order. I think the emerging P2P web technologies is good opportunity to iterate on BitTorrent and design a better-fit protocol.
Bittorrent the protocol was built so that you can fetch any part of the content in any way order you want (that's the beauty of it: traditional forward streaming is not different than out-of-order streaming)
Bittorrent the network, now, lives because peers have an incentive to behave correctly and spread the content on nodes as much as possible. It's a specific use of the protocol, but not the only one. The problem is that many people (even technical) conflate the protocol with how it's used the most: spread stuff illegally. In order to do this there is a need for peers fetching parts out-of-order. But if, say, Netflix were to distribute its content over Bittorrent, it would be perfectly fine to stream in-order, because the Netflix peers all have all the content so there is no need to spread the content here.
And there already is an enhanced protocol, in the IETF pipeline: PPSP [0]. It integrates a lot of good things that were incompatible with Bittorrent yet desirable. It's also called swift (before it was cool), and has 2 implementations [1] [2].
Correct, it was not. Though even a moderately healthy swarm today can easily stream (prerecorded, this is important) linear content. It's a lot easier now that residential bandwidth and seedboxes are so prevalent.
So (in theory) I can upload this to my server and stream content from torrents straight out (since I'm on lousy ADSL while my VPS sits on ... well a way faster connection)?
If that's what these guys after, that's amazing :-)
I created (and later closed) a similar service using mega.co.nz instead of torrents. The main problem I see with your approach is that you serve video from your server (and presumably do the torrent fetch server side). This opens you up to liability, makes you responsible for DMCA take downs and puts the workload on the server.
In contrast NimbusVid was entirely client side. The drawback was that the source data needed to be a web friendly seekable format; you couldn't play an arbitrary video file.
Of course at that point you might as well install the real thing, rather than a plugin. It's a shame there isn't a standard web-based torrenting protocol. I imagine it's technically pretty hard to do, but even if it wasn't, now that MPAA is on W3C's board and owns it, and with Google, Microsoft and Apple also being in bed with them, there's slim to zero chance such a protocol will ever become reality.
" there's slim to zero chance such a protocol will ever become reality."
Even if you think that, I don't think you should say it out loud. Lots of great things were created because people were dumb and tried to do the impossible. There's too much gloom and doom and I think that's putting people off. Not to say that we shouldn't highlight the issue, just more in a positive light i.e "X is really tough, but if it's done this could change the Y landscape"
WebTorrent makes BitTorrent work in the browser using WebRTC. It's designed to match the BitTorrent protocol as closely as possible, so when the time comes, existing BitTorrent clients can easily add support for this extension and peer with web-based torrent clients.
WebTorrent is already working as a node.js bittorrent client (just do `npm install webtorrent -g` and use the `webtorrent` command), and as a web-based client (though the docs for this latter part are currently very lacking -- working on it!).
Torque is an absolute piece of steaming manure imo. A torrent client running any time you start your browser with no GUI? how many torrents are seeding? when does it start / stop? What's the bandwidth throughput how do i turn it off?
One thing that's good that came from torque though is BitTorrent's RPC api (originally known as BtApp.js) , which I reverse-engineerd (Since it's some of the messiest JS code ever) into DuckieTorrent, it works just by passing your browser's torrent tasks to your already existing torrent client: http://github.com/SchizoDuckie/DuckieTorrent/
The "right" way to solve it is for everyone to use seekable MP4 (or seekable WebM), especially since things like Chromecast don't natively support anything else. That's hard to do but possible if you provide a highly desirable service (people will start to complain for torrents in unsupported formats).
China is so far ahead of the west in real-time (and live) peer to peer streaming. Look at video systems like QVOD (now dying after state intervention), Xigua, JJVod: they all have a central tracker and use swarms of users to supply realtime video streaming. PopcornTime was a decent example of this but China's been doing it for years - it was live television streaming over p2p first with PPLive, PPS, Sopcast, etc and this then morphed into streaming of films and television. All use a slightly modified version of bittorrent. Most use bittorrent hashes to mark content.
I still can't understand why this has been Bram Cohen's main focus for the last few years and he still doesn't have a working prototype.
Safe is the word but BitTorrent Inc have a habit of throwing things at the wall to see what sticks. They've released so many little products over the years. Sync is one of the few examples that has gained some traction. I'd have expected some kind of live streaming beta if there was a decent example around. But from what I've read, he seems to want to market it to legit networks and distributors and they are not going to do business with BitTorrent Inc.
The service did nothing at all on Chrome with ad-block-plus installed.
On Firefox the service did show some very nice blue balls moving from left to right after I did a search on some common video content and selected it, but that was about it.
Awesome idea, but I don't see how this will last very long. I expect your host will pull the plug in a few days to a week, especially if you're opening yourself up to downloading and then hosting the content.
I run www.moviemagnet.net which surprisingly is hosted in the US, but hasn't been taken down yet.
Can I put a "Watch Live" link to iflix.io which would stream the specified torrent (known by it's hash) next to each torrent download button ?
I love the concept, and I think it's wonderful especially for mobile device users...
The only fear I have, as other have noted is that I do really see how you will be able to scale if it takes off, and how you will be motivated to maintain it if it does not :/
BitTorrent doesn't order file fragments by design. So how can you stream it without downloading the whole thing first (to the server at least)? Which defeats the purpose of streaming really.
You can. BitTorrent doesn't order file fragments by design, but clients can choose to ignore this and request pieces in order. See Popcorn time and many other implementations out there.
Why don't the other clients in the swarm penalize the client for this behaviour? Downloading all the fragments in order means that if the initial uploader drops off, everyone is stuck.
It kinda works here because the shared files are already very popular, and there's a lot of seeders (ie peers who have 100% of the file and can share any part).
Haven't got this to work yet. I'd love to see a BT streaming solution not as a centralized service, but as a locally running app. Does such a thing exist?
My personal preferred suggestion: the Bittorrent Channel for Plex[0]. Plex is, effectively, a media indexing, library management, and transcoding daemon, that also provides plug-ins (Channels) to access virtual media items. In this setup, you have a streaming player (e.g. a Roku) and a PC running Plex--you access the torrent through the interface on the media player, and the PC will start downloading and transcoding the torrent and streaming the result to the media player.
Not possible currently with web technologies because browsers don't let javascript connect to arbitrary TCP servers. The webtorrent project aims to make torrent clients compatible with WebRTC, so when that gets widespread adoption it should be possible.
Tribler has been around for a long time and it has tons of good research behind it. However, it simply doesn't work. Tried stream a variety of content and it just doesn't show anything unless it's a really healthy torrent which is very rare.
Hosed. Getting timeouts for /details. 2 issues in general, though:
(1) The BitTorrent protocol is not hospitable to linear downloading.
(2) Pirated video content is extremely incompatible with browser-based playback... stuff like MKV and AVI containers, DTS/AC3 audio, multiple audio tracks, segmented RAR files.
If this works even for vanilla MP4 content, I will be super impressed - but the browser is the wrong place for this type of media app right now.
Yify torrents are total garbage at any rate, you'd be better off just not watching whatever you wanted to watch rather than stare at the eyesore that is Yify. Seriously, Yify encodes are like watching something through a window coated in vaseline.
Yuck. This is a good example of why you're supposed to reduce the dimensions of the video if you want to reduce bit rate with H.264. If you simply reduce the bit rate, you end up losing detail.
e.g. for a video with a typical level of motion, if you want to achieve 1 Mbps, encoding at 854x480 is going to look significantly cleaner & sharper than encoding at 1280x720 (even when upscaled).
This is why adaptive streaming uses quality levels with varying dimensions. e.g. on Netflix, the low bandwidth streams are not 1920x1080, as that would look like garbage.
No...I'd rather not watch something fuzzy. If you think it looks OK, then you may as well download proper SD rips. They'll look better with less artifacting.
Don't mean to hijack the thread, but has any of these stream-from-torrents-services developed any kind of "magnet link metadata database"? By metadata, I do not mean the common torrent metadata, but some kind of queryable index.
What I have in mind would be some kind of mapping between magnet link and themoviedb (or tvdb, musicbrainz id, etc). Seems like an obvious feature for me...
How long until the creator gets arrested with a full military gear tactical swat team and paraded before CNN as an evil technical mastermind hurting the country's entertainment industry and an interview with MPAA ?
At least use a server located in countries which US cannot freely exercise it's jurisdiction powers to buy you time. Hosting Digitalocean node in Singapore won't help.
The project's goal is to build a browser BitTorrent client that requires no install (no plugin/extension/etc.) and fully-interoperates with the regular BitTorrent network. We use WebRTC Data Channels for peer-to-peer transport.
WebTorrent is designed to match the BitTorrent protocol as closely as possible, so when the time comes, existing BitTorrent clients can easily add WebRTC support and swarm with web-based torrent clients, "bridging" the web and non-web worlds.
WebTorrent is already working as a node.js bittorrent client (just do `npm install webtorrent -g` and use the `webtorrent` command), and as a web-based client (though the docs for this latter part are currently very lacking -- this will improve in the coming days!).