Twice in the last week or so I’ve had people ask me about using WebRTC with Thali. I’ve already addressed WebRTC and Thali here. But recently Dominique Legault pointed me at a very cool project, freedom.js, that both explains why people keep bringing up WebRTC and helps us to really understand the question of - what is a peer to peer web and why does WebRTC in the browser not create it?
Before I jump in, a disclaimer. This is not an attack, direct or indirect on Freedom.js. Freedom.js says that it is trying to bring P2P to the web and that is, in my opinion, what it is doing. It doesn’t really claim to be the P2P Web. I only mention it because, it is cool and because it is a great example of what Thali would look like if we tried to build it in a stock browser using WebRTC.
So, back to our story. The reason why I think people keep bringing up WebRTC is because it runs in the browser and it lets you open a listener. Voila, done, P2P web, right?
Well... no. To understand why let’s ask a few questions about how a P2P app would run in a stock (that is, unmodified) browser.
Where did the web page come from?
To use WebRTC in a stock browser one has to load a web page that contains Javascript that calls the WebRTC APIs. Where did that web page come from? Who hosted it?
Where did the SDP invitation come from (aka how did the browsers find each other)?
To connect two browsers via WebRTC one has to have some way to send a SDP invitation to both browsers. This is effectively WebRTC’s discovery mechanism. In a stock browser there is no way for the browsers to directly discover each other. They have to have a third party server (probably the same one they loaded the HTTP from) that acts as a broker. Who is that third party?
How did the browsers authenticate each other?
WebRTC may support DTLS which in theory can support things like mutual authentication but good luck using that in a stock browser. The WebRTC browser API is explicitly based on the idea that one uses a Web based identity provider. Who is that identity provider?
How did the browsers get through their local NATs/Firewalls?
If the two browsers are behind firewalls/NATs how do they open that P2P link? WebRTC’s answer is STUN/TURN and as previously explained in an article on STUN/TURN/ICE I don’t believe STUN/TURN meets any reasonable definition of privacy or distributed functionality.
So what is the P2P Web anyway?
The reason for all these issues is that the WebRTC API as specified by the W3C for use in browsers was, near as I can tell, never intended to be used as a foundation for a peer to peer web. It was intended to solve a very specific problem which is that in some cases (think live video or audio streaming) it’s necessary to be able to create a direct lossy channel between two browsers for performance reasons. That is what WebRTC in the browser is intended to do. But all the infrastructure that makes this possible, discovery, connection negotiation, identity, firewall/NAT traversal, etc. was intended to be handled by the old client/server web.
So while WebRTC in the browser does add an element of P2P, it can only do so in the context of the client/server web.
So no WebRTC at all?
As I mentioned in the previous article on WebRTC I have no fundamental objections to WebRTC as a transport protocol. There are some practical issues with using it that need to be overcome such as the fact that it is UDP based, not TCP based and that existing software we depend heavily on like HTTP servers and PouchDB and TOR don’t support it. And Thali’s local P2P radio stack is also TCP based (e.g. when we run over Bluetooth or the Multi-Peer Connectivity Framework). But those problems are solvable. It’s just that from a Thali perspective it made more sense to take a TCP approach that re-uses all the existing gobs of code out there rather than using UDP/WebRTC and starting from scratch.
But if someone is invested enough in WebRTC to solve these issues then Thali is happy to see an extension that uses it. Our discovery and connection negotiation system is meant to be flexible and supporting multiple transports would be an awesome test of that flexibility.
What about WebRTC in the browser?
It’s tempting to think about what we might be able to do if we had say a Thali application on one device and a user on a stock browser on another device. Could WebRTC make it easier for them to interoperate?
The short answer is - I don’t think so. The same discovery, security, connection negotiation, Firewall/NAT traversal problems still exist. And WebRTC connections generally have to start with HTTP requests. So if one user is using a Thali device running a HTTP server that starts things off then what is the point of then switching to a WebRTC connection unless we happen to be doing live streaming?
Conclusion
So while one can correctly say that WebRTC in the browser does add a P2P component to the client/server web it is unfortunately not a workable foundation for a truly peer to peer web. So personally I don’t see much value to embracing WebRTC, in or out of the browser, at this point for Thali. But I suffer no illusions of infallibility, if I’m wrong, please let me know! Feel free to leave comments below.
I don’t think freedom.js is any cool at all since none of the examples seem to work. For example when I try to enter the global chat room I just get an “Error: undefined” message. I have tried with all latest browsers too so I don’t know why you think it’s cool?
I was referring to it more in concept. I didn’t actually test it out since the point of the article is that it doesn’t do what I want.