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 site is down now. Did they kill it already ?

Would you happen to have a working demo of the webtorrent.js in the browser?

Check out http://instant.io which is powered by WebTorrent

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].

[0] https://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protoc...

[1] http://libswift.org/

[2] https://github.com/skunkwerks/swirl/

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.

> There is an unbelievable amount of overhead involved

It's a handful of bytes per segment. Plus you can use SCTP with essentially no overhead. Emscripten uses it to emulate UDP.