Google Chrome To Have Real-Time Communications Capabilities

Some problems:

0. The separation between audio and video streams and other data happens in the browser, not in your own JS code, which is the root of most of the problems that follow.

1. There's a .send() method on connections, which allows you to send arbitrary data to the peer. But it suffers from a variety of arbitrary restrictions: they recommend that browsers rate-limit it; although it's UDP, out-of-order packets will be discarded before you get a chance to look at them; packets over 504 bytes get rejected with an error. I suspect that the most sensible response to these problems in the end might be to encode other data as audio or video streams in order to get it across the internet, but I am not yet sure that this is possible.

2. Only STUN and TURN are supported; you still can't connect to a person with a real internet connection unless you have a STUN server to nanny you through it. And of course the API isn't sufficient to allow you to implement STUN.

3. You can't bootstrap a connection to a peer without already having a way to communicate with the peer, such as COMET through a website. You already know the IP address and port where they were five minutes ago before you restarted your browser, and also their public key? Too bad. You need a website to bootstrap the initial negotiation, and if the website is down, your app can't connect. (In my skimming I haven't been able to find the spec of how the initial negotiation works.)

4. As I mentioned earlier, I'm not sure encoding other data as audio or video streams is possible. (I found an API for recording, but not one for playback.) If it isn't, that means you're entirely at the mercy of the browser's encryption and authentication algorithms to protect your communications; you can't write DH and AES and HMAC-SHA256 in JS on top of the provided API. Which means that the spec needs to get the protocol exactly right, and if and when weaknesses are found in the protocol, it's up to the browser vendor, not the JS app, to fix them.

Basically what it amounts to is that WebRTC doesn't amount to providing APIs for writing a Skype clone into browsers. It amounts to providing a scriptable Skype clone in browsers, with virtually all the important decisions about trust models, fault models, and the like already made for you.

I found this very disappointing, because what I want to build is something better than Skype. It also has the practical problem that writing a spec for such high-level capabilities takes longer and has more risk of a fatal flaw than writing a lower-level spec.

I haven't bothered offering these comments to the Google guys because they aren't really a matter of "Hey, I think that if this API had an extra parameter, it would achieve the goals you have set without breaking XYZ;" it's more a matter of "What you are working on building is not what I have been wishing for. Why don't you work on this other similar project instead?"

But look what we did with XMLHttpRequest and progressive document rendering and the DOM. It might still be possible to turn this shit sandwich into something awesome, if they don't cripple it too badly.