[lambda]

Because websockets, by definition, can only connect to the same domain as the page was served from (or another domain that opts in using CORS), websockets do not speak raw TCP but instead a special protocol that is designed to not allow them to trick browsers into accessing services that aren't expecting the browser to connect to them (such as using websockets to connect to SMTP servers and send spam, unbeknownst to the user), and because websockets can only be used for connecting from the browser to a server, not for listening for incoming connections.

Don't be fooled by the name. Websockets are not a general socket interface in the web browser. It is simply an API and protocol for establishing a persistent, bidirectional communication channel between the browser and the server in order to better support applications like chat, notifications, live editing features, and the like, without having to resort to COMET techniques like polling, long-polling, and so on.

[abraham]

XHR is restricted by domain and yet browsers provide APIs for extensions to get around this. Just be cause the spec specifies a browser/client <-> server design does not mean that browsers can't also be the server.

And that API could be extended to support p2p design patterns if browsers decided to do so.

[lambda]

Ah. I thought that you were talking about what you could do with the websocket spec as it exists, but you actually seem to be talking about what you could do with some hypothetical future websocket spec.

Yes, it might be possible to extend the websocket spec to handle peer-to-peer applications. But that would be difficult, and would not fit well with the purpose it is designed for, which is creating a persistent, bidirectional communication channel between the browser and the server, securely, in such a way that it can't be used to subvert the user's browser to do malicious things.

The big issue is that when you browse to a web page, the assumption is generally that any scripts on the page should be able to communicate back to the server it came from, or possibly other servers that explicitly opt in, but not to arbitrary other machines on the internet. And even connecting back to the same server, you need to be careful not to allow the script to talk to services that don't expect a (possibly malicious) third-party script to be communicating with them from the user's machine.

The websocket API and protocol are carefully designed to prevent these sorts of problems without the user having to intervene and understand what's going on. If you tacked a peer to peer protocol on, that would add a lot of complexity (since you'd also need to add some sort of peer discovery, NAT traversal, firewall configuration, and the like), and make it even harder to guarantee these properties. Essentially, adding peer to peer support in the browser requires you to solve so many extra problems that it doesn't really make sense to think of it as an extension to websockets, but instead just do it as an entirely different standard.