Open Peer and the Frontiers of WebRTC

At Bocoup, we love working on the latest problems in front-end development such as parallel processing, best practices in web application development, and media-rich experiences. This is why we consider the folks at HookFlash kindred spirits; they have made browser-based peer-to-peer communication their “thing”. We recently had the privilege of working with the HookFlash team, and (as can only be expected when collaborating with passionate, talented individuals) we learned quite a bit.

For Those Late to the Party

So much of today’s web is about communicating with one’s peers, the term “peer-to-peer” (or “P2P” for short) can seem like old news. When you write a Direct Message to someone on Twitter, isn’t the text delivered from one peer to another? Really though, the term is less about who is communicating and more about how they are communicating. A true “peer-to-peer” channel does not rely on any sort of specialized central service (i.e. twitter.com in the previous example); all the messages travel directly from the sender to the recipient.* This communication model is highly sought-after because it enhances privacy, security, robustness, and accessibility far beyond what is possible within “mediated” channels.

WebRTC is a developing standard to facilitate streaming data transfer between web browsers. It defines a JavaScript API for generating the information that clients need to communicate in real-time (this is called the Session Description Protocol, or SDP for short). Creating such rich communication channels is no small feat (check out the architecture reference to get an idea of the complexity), but it isn’t the end of the story.

This Space Intentionally Left Blank

If we take the extraordinary service rendered by the WebRTC API for granted (which we do only temporarily), we can more clearly see its limitations. Sure, peers are able to connect with each other directly, but how do they negotiate connections? What if the peer does not want to immediately accept a call? What if she is away from her device? How do the peers end the call? These questions fall under the purview of “signalling”, and the WebRTC specification makes no attempt to address them.

This is no oversight, however. Defining a fully-featured signalling protocol is a challenge unto itself, but it is tangential to the technical challenges that the WebRTC specification set out to address. As it stands, it has taken the standards body years to define a solution for streaming data transfer (and it still isn’t complete). By intentionally limiting the scope of the specification, the WebRTC working group is able to arrive at consensus far more quickly.

WebRTC defines all the functionality that developers around the world need to begin experimenting with their own protocol implementations. Any website can use WebRTC to implement fully-featured peer-to-peer applications (and indeed, many already have).

Unfortunately, without a standard, each of these web applications is a silo unto itself–there can be no communication across web sites. Thanks to WebRTC, web developers have all the tools they need to prototype open standards for signalling over WebRTC.

Enter Open Peer

Open Peer is Hookflash’s open-source signalling protocol. (Its open nature is important because it means anyone is able to create compatible applications for any platform, free of charge.) First and foremost, it addresses the needs described above. But since peer-to-peer communication has so much more potential than simple actions like “hang up” and “reject call”, Open Peer implements far more powerful abstractions.

For one, the concept of “identity” has been built into the protocol. This enables users to find each other by some persistent, human-readable name (think “Mike Pennisi” instead of 2001:0db8:8ba3:4043:1020:812e:b3d0:7aa4). But instead of relying on some centralized authority to provide this name, identities in Open Peer are federated (think e-mail addresses instead of Twitter handles). It also recognizes the fact that people already have identities with “legacy” systems (e.g. phone numbers and e-mail addresses) and provides hooks for them.

Support for identities necessarily requires the addition of some infrastructure into the protocol. If you want to be able to find your friend by name, some service must exist that knows how to locate him. After you’re connected, true peer-to-peer communication can begin, but the reliance on third-party services remains something of a necessary evil for the niceties of identities.

Open Peer attempts to mitigate the security and privacy risks by making the infrastructure as distributed and stateless as possible. The servers have no sensitive data, and they are completely interchangeable. This de-incentivizes the servers as a target for hackers and severely limits the abilities of malicious administrators.

By making a distinction between the concepts of identity and location, Open Peer enables a particularly interesting use case. Consider the following hypothetical situation:

You’ve just won a contest! The prize? A ten-minute phone call with your favorite performer, Englebert Humperdinck! Tonight, he will be calling you online using the Open Peer protocol. Now, the Dinck is a popular guy–not anyone can just call him at will. Despite this, when you receive a call at 6:00PM, you can be 100% positive that the caller is, in fact, the legendary British hearthrob. Once your ten minutes is up, Englebert ends the call, and you are left with a sense of awe, but (and this is the important part) no means to call him back. There’s no *-6-9 by default. Of course, if you guys had really hit it off, there would be nothing to prevent the crooner from sharing his contact details, but this is completely optional.

Users are only able to locate a given peer if they know their “name” and their “find secret”. By allowing peer-to-peer communication without the exchange of this information, Open Peer enables scenarios like the one described above. You’ll find more about this concept in the documentation of the Public Peer File.

The Future of P2P

While we find it easy to get excited about the promise of the Open Peer protocol, it’s important to remember that there is still a lot of work to be done, and nothing is set in stone.

WebRTC remains unfinished. The specification itself is still being written; you can get involved through the WebRTC working group’s public mailing list and the getUserMedia API mailing list. The WebRTC Google Group and webrtc.is offer coverage on the latest developments. And don’t forget that both Firefox and Chromium are open-source, so you can get in on the implementation as well. You can find a guide for contributing to Firefox here and a guide for contributing to Chromium here.

Open Peer is under heavy development as a collection of open-source projects. You can find SDK’s for a number of environments on GitHub: iOS, BlackBerry, C++, and the browser (Android support is in the works). Protocol nuts will no doubt be interested in reviewing the full specification.

Of course, the space for signalling protocols is wide open. Peer.js is another project that attempts to address signalling concerns for WebRTC. Though if you’re particularly opinionated, you might choose to propose a brand new open standard of your own design. If this is the case, all we ask is that you try to learn from the current proposals and those that have come before (e.g. Jingle, SIP, and Chord).

From a developer’s perspective, this may be the best aspect of the open web: if you’re passionate about the problem, opportunity abounds.

* – Sure, there will always be machines like routers and switches between the peers, but these devices have no privileged information and are completely interchangeable.