New P2P and real time communications APIs currently under development by W3C could revolutionize the architecture of the web and the way users can interact with one another.

Currently the web is mostly a client-server architecture. That is the web browser connects to a server to download a page or any data for that matter. Servers are the single source of information on the web and browsers are their clients. This could be all about to change and so bring about the biggest revolution since the web was invented. If you think HTML5 or Ajax are important, then the new P2P and real time communications APIs that are under development by W3C should open your eyes to the fact that it is a much bigger world out there than you have so far dreamed of.

When you think for a moment about the current architecture of the web you have to admit that it is restrictive. Why should there always be a server in the loop? Why can't my web browser simply talk directly to your web browser? This is the simple question that the W3C's Web Real-Time Communications Working Group has been set up to answer.

Part of the Ubiquitous Web Applications Activity, this working group sets out to define client-side APIs to enable Real-Time Communications in Web browsers. To quote from its mission statement:

"These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers (unless needed for firewall traversal, or for providing intermediary services)."

So, as envisaged by the working group, one browser will be able to connect to another to share audio and video data. The API specifications are:

• API functions to explore device capabilities, e.g. camera, microphone, speakers.
• API functions to capture media from local devices e.g. camera and microphone
• API functions for encoding and other processing of those media streams,
• API functions for establishing direct peer-to-peer connections, including firewall/NAT traversal
• API functions for decoding and processing (including echo cancelling, stream synchronization and a number of other functions) of those streams at the incoming end,
• Delivery to the user of those media streams via local screens and audio output devices

This goes beyond instant messaging and suggests that the browser will have the potential to become the one unified communications device you need. So while we currently argue about whether the iPhone or Android is best, it might be that "answer your browser will you?" is a common expression in the near future.

But this is just the beginning and it is unlikely that the working group has thought of all of the ways that the API it is trying to define could be used. That's the task of the creative programmer and you can see that in a world where Ajax doesn't just mean downloading some data from a server, both realtime interaction and P2P type services are exciting possibilities. You could share pictures, your blog or music, for example, with another browser user without having to upload to a server.  You could work on a collaborative project or keep a community diary or calendar.

One way to think of it is as every browser becoming a server and not just a web server. This is potentially the revolution the web has been waiting for. It returns personal computing to the personal level and creates a distributed system with fewer single-points of failure. It could be both more anonymous and less secure. Having briefly escaped the tyranny of the mainframe in the early days of the IBM PC we have returned to it under server surfdom. A realtime P2P API could transform the landscape yet again and re-establish a non-centralized architecture/

Put like that it is amazing that we have put up with client-server architecture for so long. The working group is looking to publish its first public working draft later this year.

As always there are some precursors for any proposed API and in this case the most obvious is Opera Unite. This implements many of the same features that the working group is trying to standardise and it is built into the the current version of Opera right now.  See the video for an introduction to Unite:

Of course it won't be long before other browsers start to implement the same protocols so wait just a little while if you want to work with the standard.

The only thing that the technology lacks at the moment is a good project name - surely it couldn't fail for such a stupid reason?

More Information

Real-Time Web Working Group

Introduction to Opera Unite