This is part one of what I hope will be a series of posts describing the drivers behind our vision at .pw. At .pw our goal is to provide a unified, ubiquitous, intuitive and extensible communication platform to users and businesses worldwide. Decentralization (as described in this post) is an important element in our vision and product strategy.

Decentralization is not a new concept. The IT landscape in the early 80s moved from a centralized, time-share based, thin-client computing model to a decentralized, poweful, rich, thick-client desktop. In hindsight this shift from centralization to decentralization seems obvious now. Computers started out as large, expensive machines that occupied enormous rooms affordable only by a privileged few, and utilized as a precious resource in a shared manner through teletype access terminals. Moore’s law eventually reversed the direction of the pendulum, resulting in the shift of balance to an extent where today’s desktop workstations rival the most powerful machines in those days. This was the first wave of decentralization.

The second decentralization wave is now upon us. The Internet connection usage model has always followed a client-server paradigm. This centralization has been a result of several facts we take for granted that are very rapidly turning into false assumptions.

Drivers of the 2nd wave of decentralization

1. The transition to ipv6

Perhaps the most critical juncture in this decentralization wave will be the transition to ipv6. Infact if anything, this wave of decentralization has been considerably delayed due to lack of ipv4 addresses, resulting in end user devices having to exist behind NATs which are not service friendly. Devices behind NAT cannot expose a service endpoint even if they have the processing capacity and bandwidth, without complex port forwarding. Due to the nature of TCP/IP, a server must be available on a unique public IP address.

In the early days of the Internet, it was the lack of reliability of endpoint connectivity that resulted in a clear demarcation between clients and servers. Today however that distinction is blurring, with desktops having access to similar bandwidth and processing capabilities as servers. The NAT-imposed limitations however continue to maintain that demarcation. Servers are no longer distinguishable from clients by their power or connectivity, but simply by the fact that servers have unique IP Addresses and end user desktops don’t. End user clients invariably live with a virtual IP address, unable to expose their desktops to the Internet as a server, despite having equivalent connectivity and processing power.

With ipv6 however we have billions of ip addresses per human on this planet, so unless interstellar travel makes a monumental leap, life is discovered on thousands of other planets, and the Internet becomes the backbone of inter-galactic communication, we will likely never run out of ip address space. This means every single device produced can have a unique endpoint address - cellphones, home appliances, automobiles, heck even your t-shirts and undergarments may be connected to the mesh with a unique IP address, and will likely run a web service

2. Connectivity ubiquity

Connectivity is becoming ubiquitous and bandwidth cheaper. With the advent of wimax, edge, EV-DO, CDMA we are already connected almost everywhere through every device. Gone are the days when 99.99% network availability was a datacenter-only luxury. Today many of us already assume always-online connectivity at our home, on our office desktops and even our mobile devices.

3. Bandwidth costs are tanking

The only thing falling faster than the post-subprime stock market is the cost of bandwidth. Broadband has now become affordable to the masses. The success of youtube and other media heavy websites is a testament to this important change.

Impact of the 2nd wave of decentralization

1. Blurring of the client-server paradigm

As a result of the above changes, the distinction between a client device and a server device will begin to blur, and all devices will be expected to act as both clients and servers in a computing cloud/mesh.

2. Protocol re-definition

Many of the popular protocols we use are designed keeping in mind limitations that we discussed above. For instance many popular protocols require servers for guaranteed delivery - eg SMTP/POP/IMAP assume a clear distinction between an always connected and available server and a disconnected/offline client. Email delivery therefore requires a chain of intermediate servers to send a message from one user to another. However in a world where all devices are always connected and have unique IP addresses, an intermediate chain of servers is not required for message delivery. Additionally HTTP, our most popular protocol is designed to be unidirectional, wherein a client sends a request to a server and the server responds with a response. These protocols seem appropriate in an environment where there is a distinction between a client device and a server device. However with the blurring of this distinction, newer protocols will likely be more conversational and P2P. XMPP is one such protocol (though Jabber currently does follow a client-server deployment model)

3. Push vs Pull and the era of instantaneous communication

The killer app of the Internet - email - is, as of today, non-instantaneous. An email sent from one user to another traverses through a series of mail servers to a final mail storage server from where it is downloaded by users using POP/IMAP/Webmail, all of which are Pull/Polling based protocols. If your client is configured to fetch email once every 5 minutes, each email received by you is likely to be 5 minutes delayed.

Some of the Web 2.0 touted protocols like RSS, Atom etc are no different. They are all pull-based polling-type protocols. Pull is necessitated with an offline client. The assumption is that since the client is not always online, it will pull the required content when it actually does come online. This does not connote subscription in its true form. Though RSS/Atom are touted as content subscription protocols, they are not really subscription protocols. Compare this to the offline world. If you were subscribed to a magazine, would you expect it to be delivered to your doorstep every month (Push), or would you expect to visit the local magazine store every 5 minutes to check if it is out yet and buy it once it is out (Pull eg RSS). Subscription connotes a push based behavior. RSS can only simulate it, but it is not true subscription.

Pull based protocols are slower and inefficient (both bandwidth-wise and processor-utilization-wise) than Push based protocols.

Decentralization however will result in the proliferation of new push-based protocols. Content and Communication will be pushed to endpoints rather than polled. Only in the rare scenario that a device is not connected will content have to be temporarily stored on an intermediate server until it can be pushed to the client once the client connects.

What does this have to do with .pw?

At .pw we are creating a communication platform that will enable various devices to leverage a decentralized, always-online, reliable network - a computing cloud of peers so to speak.

Sign up at http://start.pw and join the ride!!