i don't mean that chrome os is the same as chrome the browser. i mean that building everything you need into a browser, and preparing to launch a browser-based OS are the same task.
I've been looking through the spec. It's full of things that make me groan in agony, but at first glance, it seems like it might actually be sufficient to build a Skype competitor as an extension or web app.
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.
You might be (more) interested in the P2P communication APIs currently being added to Chrome. Details are scanty to say the least, but allegedly they will provide P2P UDP sockets.
In relation to #2 and #3, I think you underestimate how hard it is to get a p2p connection. It's very hard, and sometimes impossible, which is why a TURN server will often fallback to simply relaying data, in which case someone running the server has to pay for the bandwidth. Thus, you need to pay for a TURN server if you want to run a p2p service (or make users relay the data, like Skype does).
In relation to #4, you want the encryption to be done by the browser. Encryption is very hard to do right. You're crazy if you think you'll implement it correctly by yourself in JS.
WRT #2 and #3, I know it's very hard; that's why it's particularly important to be able to take advantage of those few nodes that do have publicly routable addresses so that I'm not at the mercy of some bozo whose TURN server billing got screwed up.
With relationship to #4, yes, I know it's hard; that's why I think it should be a JavaScript library rather than written into the spec of the browser behavior. I don't recall where I said I wanted to do anything "by myself". I rather prefer to enable open-source collaboration and decouple the security protocol from the necessarily lumbering standards process.
Chrome is gaining features, yes. However, since with each release the Chrome team manages to eke additional performance out of it, I think it's a little premature to decry it as "bloat".
As has been mentioned, Google's not going to put in features if it slows down Chrome--they care about speed too.
The other problem with adding features, interface bloat, doesn't apply as much either, since most of these features are available for webapps to use, and replace the requirement for Flash, which is the main thing making browsers slow.
