[lenni]

Is there any indication what this API could be useful for? The article really only talks about NaCl in depth.

What does an P2P-API do? Surely, all you need for a P2P application/protocol is a WebSocket. If you invent a new app for P2P you'd want to tailor it to your specific need, no?

[patrickaljord]

Websockets are only useful to talk to a server. At last year google io presentation, they said people wanting to play an html5 game or do a voip call shouldn't have to use a server, especially if they are in the same room. They should be able to connect directly to each other.

More info here:

http://peter.sh/2011/03/css-quotes-mock-ups-of-the-html5-dat...

http://src.chromium.org/viewvc/chrome?view=rev&revision=...

http://src.chromium.org/viewvc/chrome?view=rev&revision=...

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

[abraham]

Why are websockets only useful to talk to servers? Why wouldn't the be good for p2p?

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

[dekz]

I don't believe you can open a websocket directly to another user. At least without the use of a server relayer.

[abraham]

I'm not all that familiar with the websocket specification but isn't it pretty much just TCP connections? In which case p2p would be very similari to say TCP bittorrent?

[lambda]

No, it's not a TCP connection. It is a persistent, bidirectional communication channel, initiated by the browser, which uses its own protocol on top of TCP. It is basically designed to just be better than AJAX and COMET for things that need long-lived bidirectional communication between the browser and server; it is not intended to be a general purpose TCP API.

You can read about it on Wikipedia: http://en.wikipedia.org/wiki/WebSockets Read the API spec: http://dev.w3.org/html5/websockets/ Read the draft protocol spec that was implemented by some browsers, but later pulled due to security concerns: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-... And read the current working draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketproto...

[abraham]

> No, it's not a TCP connection. It is a persistent, bidirectional communication channel, initiated by the browser, which uses its own protocol on top of TCP.

So it is a TCP connection. It may have its own protocol on top of TCP but as long as the browsers can create TCP connections between each other then then it can be made to work right?

[patrickaljord]

You can't run a Websocket server on your browser. Only a client. So you can't get p2p by definition because in a p2p network every node is a server.

[abraham]

Why wouldn't you be able to run the browser as a websocket server? A browser can run everything on a computer a p2p node can.

[malandrew]

There's not much detail in the RWW article, but take a look at the link to a thread I started on the WHAT-WG mailing group in Jan 2010. In it I cite a real-life potential use case for P2P in the browser.

[patrickaljord]

Take a look at this spec http://www.whatwg.org/specs/web-apps/current-work/multipage/...