Is WebRTC really decentralized?

[lmatteis]

If a webtorrent-enabled website goes down, the browsers will not be able to communicate with each other. This to me is a serious problem that needs to be taken in account for systems that are built to avoid a single point of failure.

In regular BitTorrent you at least have the possibility of announcing on multiple trackers. Is this a possibility for webtorrent? I guess once could simply go to another webtorrent-powered site and see whether their torrent is being served there, hoping that other peers have switched from the other site.

Are there any ideas for making this self-sufficiently decentralized? Can WebRTC work without going to a site? Perhaps there's a way to allow users to download the HTML version of the site and access other peers even if the site went down? Check this out https://github.com/cjb/serverless-webrtc/

[Svenskunganka]

Just like BitTorrent does webtorrent use "trackers" to route peers and you can specify multiple webtorrent trackers for each torrent.
Webtorrent itself is already partially decentralized and does not require a website to function. The issue you're adressing is an issue with the http-protocol and not really related to webtorrent. CloudFlare has partially tackled this issue by offering a cached version of the site that's currently down, and webtorrent functions just as it normally would do on that version.

You can write a userscript using webtorrent and it would function normally, so it does not need to be hosted anywhere.

Even if a bunch of people are browsing a site that uses webtorrent suddenly goes down, the peers are still able to communicate since they're already connected. And if the webtorrent tracker is hosted on another server than the actual website that went down, the peers would also still be able to announce to the tracker.

[lmatteis]

I guess you're talking about the node.js version of webtorrent. My post was specifically regarding the WebRTC infrastructure which requires users to browse to a website in order to instantiate the WebRTC communication. This is the single point of failure required in the WebRTC world.

[qgustavor]

If a webtorrent-enabled website goes down
The simplest solution: service workers. In fact the only problem I see on service workers is about security (you can't control how or when it updates like you can with a native app) but it perfectly solves the offline server problem.
... the possibility of announcing on multiple trackers
I think that when the project grows more public trackers will be released by people with want to contribute to the project, the code is open and instructions are easy. The problem is that those trackers are expensive, as secure connections are required, but seems it's becoming cheap. If the actual code doesn't allow multiple trackers I think it will be implemented as it's common in bittorrent.
Perhaps there's a way to allow users to download the HTML version of the site.
Why not downloading the node version? For most of us it's not hard, although, for example, a NW.js interface and a installer can make easier for users.
Check this out https://github.com/cjb/serverless-webrtc/
WebRTC requires at least two messages being transferred, in this case by copy-pasting as those are too large for QR codes (although it works if you use multiple). It can work to replace trackers and connect to the DHT, but it's a quite hard to use, I think the many trackers idea is better.
All points that Svenskunganka said are valid. I'm also trying find some solutions to replace trackers, like using XHR instead of WebSockets to make trackers possible to deploy where those are unavailable and getUserMedia modems for local peer discovery, but still nothing done. As said there are points of failure (not too few) but with the options we have there isn't too much to do.

[feross]

In addition to the excellent answers already provided, here are my own answers:

In regular BitTorrent you at least have the possibility of announcing on multiple trackers. Is this a possibility for webtorrent?

Yep, right now I'm running wss://tracker.webtorrent.io (this is what https://instant.io uses) but there's nothing stopping you from running your own tracker! This is the module: bittorrent-tracker.

Are there any ideas for making this self-sufficiently decentralized? Can WebRTC work without going to a site?

Yeah, eventually I'd love to get a DHT working over WebRTC for trackerless torrents, just like normal BitTorrent has. Issue here: #288 PR welcome!

Perhaps there's a way to allow users to download the HTML version of the site and access other peers even if the site went down?

Yep, this would help get around the problem of the site serving the JS going down. You can try saving https://instant.io to your desktop and seeing if it works. Other options include:

• service workers
• hyperboot (http://hyperboot.org/)
• a downloadable desktop app or chrome extension