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