If anyone feels like testing it out, I was actually just playing with webtorrent a couple days ago: <a href="https://stark-springs-9580.herokuapp.com/" rel="nofollow">https://stark-springs-9580.herokuapp.com/</a><p>It's very basic, and doesn't have proper error messaging. Would recommend only attempting to stream mp4 (h264) if you're giving it a shot.
I've been using <a href="https://instant.io/" rel="nofollow">https://instant.io/</a> a bit to share files with people. You don't have to care about captchas or size thresholds because you aren't storing anything on the server, except for the tracker file. The more people that download and stay on the page, the faster it will be for everyone else too.<p>Of course, it's not perfect. It appears to try and load the entire file to memory to seed, which makes sense, but that means you can't transfer a 1GB file without using 1GB of RAM...
this reminds me of <a href="http://ipfs.io/" rel="nofollow">http://ipfs.io/</a> although IPFS doesn't run natively in the browser (it's a go app) and has much wider objectives (ie. the whole <i>web site</i> is loaded from the swarm, not just specific media objects, and it is trackerless, essentially).
There is a gratipay account for WebTorrent if you want to support them: <a href="https://gratipay.com/webtorrent/" rel="nofollow">https://gratipay.com/webtorrent/</a>
sort of reminds me of that torrenttornado javascript extension by one of my favorite Mozilla add-on developers<p><a href="https://addons.mozilla.org/en-US/seamonkey/addon/torrent-tornado/" rel="nofollow">https://addons.mozilla.org/en-US/seamonkey/addon/torrent-tor...</a>
I see one issue here. Who is going to seed? Someone keeping a web page open after they got the download is even less likely that someone keeping their torrent client running after they are done downloading.
Reinventing the wheel.<p>Rather than restricting what browsers can send and making kludgy workarounds that waste resources, why don't we just allow browsers to send whatever they want?