

P2P API Discovered in Latest Builds of Chromium - abraham
http://www.readwriteweb.com/hack/2011/03/p2p-api-discovered-in-latest-b.php

======
est
The p2p api is really the libjingle used in Chrome Sync, which is used to sync
your Chrome/Chromium bookmarks and stuff. And it was introduced to
Chrome/Chromium many years ago. If you checked your Chromium error log you can
see lots of lines says p2p error.

The real news is now the p2p functionality shows a possible Javascript
interface[1] to be used in Chromoting[2]

I guess the next step would be handcraft XMPP envelopes in Javascript. Each
browser instance you open on any device would be indentified as a JID/resource
string.

[1]: <http://code.google.com/p/chromium/issues/detail?id=41776>

[2]: <http://code.google.com/p/chromium/issues/detail?id=51198>

~~~
patrickaljord
Nope, it's very new and unrelated to libjingle, check this post with links to
the commits. Those are real p2p udp sockets:

<http://news.ycombinator.com/item?id=2315908>

------
spot
"If NaCl gains enough traction, Chrome could become the next IE6."

Since Chrome and NaCl are both Open Source and Auto Updating, this has to be
the dumbest analysis ever.

------
malandrew
I hope this is related to an idea I floated about 1.5 years ago on the WHAT-WG
working group. Given how mature node.js and evented servers have become this
makes even moar sense than it did when I originally tossed the idea about.
[http://lists.whatwg.org/htdig.cgi/whatwg-
whatwg.org/2010-Jan...](http://lists.whatwg.org/htdig.cgi/whatwg-
whatwg.org/2010-January/024772.html)

------
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://peter.sh/2011/03/css-quotes-mock-ups-of-the-html5-date-
picker-and-the-p2p-api/)

[http://src.chromium.org/viewvc/chrome?view=rev&revision=...](http://src.chromium.org/viewvc/chrome?view=rev&revision=76604)

[http://src.chromium.org/viewvc/chrome?view=rev&revision=...](http://src.chromium.org/viewvc/chrome?view=rev&revision=76731)

[http://www.whatwg.org/specs/web-apps/current-
work/multipage/...](http://www.whatwg.org/specs/web-apps/current-
work/multipage/commands.html#peer-to-peer-connections)

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

