The Particle Protocol

In the pre­vi­ous entry, I defined the Inter­net atmos­phere as every piece of the infra­struc­ture that allows us to get access to the cloud. In this entry, I will explain how to alter that infra­struc­ture so it becomes more resilient in the future.

But beyond a state­ment about the inter­net infra­struc­ture, this is also about fig­ur­ing out a solu­tion to avoid los­ing the inter­net. So to help it, we need to define a way to build the atomic com­po­nents that will help it become resilient to any attack, whether they are from repres­sive dic­ta­tors or over-reaching corporations.

For­tu­nately, the inter­net hap­pens to be at a key point in terms of its evo­lu­tion, with the tran­si­tion from IPv4 to IPv6 being upon us. With one major effort to upgrade large part of the infra­struc­ture, it seems that new efforts could help us increase the over­all resilience of the net.

A few years ago, I put together some basic require­ments for a tool that I would like to see, some­thing I had called a “Per­sonal Rela­tion­ship Man­ager.” A few years later, there are sev­eral of those so I’m think­ing that I can start plant­ing sim­i­lar ideas into the ground for pos­si­ble imple­men­ta­tions by peo­ple who under­stand pro­to­cols much bet­ter than I do. The fol­low­ing are imper­fect thoughts based on my under­stand­ing of core inter­net pro­to­cols and dis­cus­sions I’ve had around them with sev­eral peo­ple over the last cou­ple of years.

A lot of this, of course, has sub­stan­tial prece­dence. For exam­ple, the idea of com­pletely rewiring con­nec­tiv­ity is not really a new one. Here’s Doc Searls, about 3 years ago:

Connectivity-as-infrastructure is soft in sev­eral senses. One is that you don’t need a big util­ity com­pany to pro­vide it. Another is that data and its pro­to­cols are soft. They have no phys­i­cal sub­stance, yet they have sup­port­ive qual­i­ties that are sub­stan­tive in the extreme. That’s because the Net is a way of con­nect­ing. It is not the wires and waves that do the connecting.

.. and there has been a lot of work put into mak­ing the inter­net pro­to­cols faster and more reli­able but few have taken the rad­i­cal approach of mak­ing the net com­pletely self-reliant.

So with­out fur­ther ado, here are some basic requirements:

• Open
• Light
• Easy to use
• End-less

I will now go into the think­ing behind each of these points.

Open

Wikipedia defines a pro­to­col as:

a set of guide­lines or rules.

The chal­lenge then becomes who is respon­si­ble for set­ting those guide­lines or rules. Own­er­ship of the respon­si­bil­ity for set­ting the guide­lines or rules should be dif­fused around the com­mu­nity of inter­est on the inter­net. In that sense, the par­ti­cle pro­to­col should be a pro­to­col with­out a head group. Deci­sions around what to include and exclude in its core should come from the com­mu­nity as a whole, with no cen­tral office, no cen­tral com­mit­tee, no cen­tral indi­vid­ual, ulti­mately respon­si­ble for it.

Open is the way of the net, where ideas are given dom­i­nance based on their indi­vid­ual value and not based on the value of the indi­vid­u­als that brought them forth.

Because it is head­less, open is uncon­trol­lable. One could argue that peer-to-peer net­works are the clos­est thing we have to open net­works as every node in the net­work serves and routes things for every other node and the dis­ap­pear­ance of an indi­vid­ual node does not impact the net­work as a whole for very long.

A corol­lary to open then seems to be that the net­work will be peer-to-peer, mak­ing it impos­si­ble to shut­down the net­work alto­gether. Peer to peer net­works have been the bane of the music and movie indus­try for a decade because they can­not be shut down and it seems that if we are to build a net­work that can­not be shut down, we can learn from that model.

Open also means unen­cum­bered from any pre-existing patent. The par­ti­cle pro­to­col should be some­thing that is owned by absolutely every­one and by no one in par­tic­u­lar. The rea­son for this is that lack of own­er­ship means that the own­ers can­not be leaned on by any orga­ni­za­tion or gov­ern­ment. With that point of fric­tion removed, the abil­ity to cre­ate back­doors or shut down such a pro­to­col would be more lim­ited and require sub­stan­tial efforts on the part of the peo­ple try­ing to do the shut­ting down.

Open also means that the par­ti­cle pro­to­col should be sit­ting at the low­est level of the infra­struc­ture stack with lit­tle or noth­ing below it. Once again, this is to ensure its resilience as the closer it is to the foun­da­tion, the harder it is to remove.

Last but not least, is that open is not about money.  That is because the core por­tions of the par­ti­cle pro­to­col should be free in a mon­e­tary sense too. How­ever, beyond the core, inno­va­tion should be allowed so any­one can build (and make money) by pro­vid­ing extra com­po­nents for the par­ti­cle pro­to­col. How­ever, the peo­ple doing so must real­ize that any changes they decide to make to the core are dic­tated by the under­ly­ing prin­ci­ples regard­ing the pro­to­col and must be redis­trib­uted in the same open fashion.

Light

The par­ti­cle pro­to­col should have the light­est CPU and mem­ory foot­print pos­si­ble. Some may feel it is too much of a con­straint but the par­ti­cle pro­to­col should be so light that it can run on most devices. For its ini­tial ver­sion, I think that the abil­ity to run, with­out impact­ing their pre-existing oper­a­tions, on mobile phones, com­put­ers, and devices with as low a foot­print as a 400Mhz CPU and 128Mb of RAM (Apple watch­ers may rec­og­nize this as the orig­i­nal spec­i­fi­ca­tion behind the first iPhone: it is no acci­dent as I believe the par­ti­cle pro­to­col should run on any smart­phone in the future).

Light, in my view, also means unat­tached, which means that the par­ti­cle pro­to­col would be wire­less by default. Sure, devices could be cre­ated to con­nect some points of the net­work to some wired net­work (and this could turn into a whole new sec­tor for the tele­com infra­struc­ture industry).

Finally, light also means unen­cum­bered of extras. The prob­lem to be solved here is resilience (ie. it can’t be shut­down). Any­thing beyond that is extra. So the par­ti­cle pro­to­col should allow for TCP/IP to run on top of it but things like extra secu­rity, guar­an­tee of ser­vices, and so on, should not be part of its core. How­ever, I’d like to see some kind of a plug-in approach that could allow that pro­to­col to be extended with such fea­tures by any­one who wants to.

Easy to Use

The first dot­com boom taught me an impor­tant les­son about tech­nol­ogy: if it is not easy to use, peo­ple won’t use it. The inter­net was around for a long time prior to 1995 but it wasn’t until then that peo­ple adopted it. Why was that? I think it was due to two fac­tors: first, Microsoft built a TCP/IP stack into their oper­at­ing sys­tem, mak­ing inter­net access a ques­tion of con­fig­u­ra­tion and AOL started splat­ter­ing the world with their disks, mak­ing access to the online world just a ques­tion of set­ting up a user­name and pass­word and hand­ing out your credit card infor­ma­tion to them. The rest was automated.

In order for the par­ti­cle pro­to­col to suc­ceed, it should be easy to install and easy to use. By easy to install, I mean that it should be a ques­tion of down­load­ing it and, if needed, click­ing on an icon to install it but that would be it. The soft­ware would install itself, look for ways to con­nect to its peers, iden­tify any peers nearby, and auto­mat­i­cally con­nect, becom­ing another node in the network.

By easy to use, I mean that there ought to be no actual work to use it once installed. The first thing the pro­to­col installer would look for is all the ways in which it can con­nect to other devices (wired: eg. via a modem or eth­er­net / wire­less: eg. WiFi, Blue­tooth, EDGE, 3G, 4G, etc…) and attach itself to all the avail­able modes with­out dis­turb­ing the other soft­ware attached to those. There should be, embed­ded in the pro­to­col itself, a logic as to how it would pri­or­i­tize its con­nec­tiv­ity, based on how many nodes are avail­able in a par­tic­u­lar con­nec­tiv­ity mode and how reliant other nodes are on its con­nec­tiv­ity to more than one con­nec­tion (eg. tying 3G com­mu­ni­ca­tion to WiFi links).

By being com­pletely invis­i­ble, the pro­to­col would become some­thing that can exist with­out being acknowl­edged and can be installed with­out much notice after instal­la­tion. So, if you were to take Libya as an exam­ple again, hack­tivist could work to install the par­ti­cle pro­to­col on every com­mu­ni­ca­tion devices the gov­ern­ment owns, and pro­test­ers would lever­age those instal­la­tion for their own communication.

The only way to stop such a pro­to­col would be to com­pletely shut­down every elec­tronic device avail­able in an area/country. While it is not impos­si­ble that some strong­men could go down that route (I’m think­ing of places like North Korea, maybe), the impact would be that the only way to shut things down is to shut down your own com­mu­ni­ca­tions line. While it is the­o­ret­i­cally pos­si­ble, such a shut­down could cre­ate a race as to who is bring­ing their own net­work back up in order to com­mu­ni­cate. If we were to take into account net­work the­ory, this is basi­cally cre­at­ing resilience by ensur­ing that the infor­ma­tion assym­e­try cre­ated by a net­work shut­down forces ALL the play­ers to rush back to restor­ing it, thus restor­ing nodes for all sides at the same time. In a per­verse way, it lever­ages the assym­e­try to get rid of it.

End-less

Many years ago, my good friends Doc Searls and David Wein­berger argued that the inter­net was a World of Ends. The prin­ci­ples were sound but unfor­tu­nately, by cre­at­ing a view based on ends, they opened the pos­si­bil­ity for cre­at­ing points of con­trols.

If the inter­net has ends, it can be closed down.

But what if it didn’t have end-point. What if it had addresses that changed on a more ran­dom basis. Then exert­ing con­trol over one point would not nec­es­sar­ily work. What if the address­ing were to change on a time and loca­tion basis as well as some other fac­tors based on sud­den changes in traf­fic (spikes or drops) with vio­lent drops in traf­fic result­ing in a com­plete re-assignement of the address­ing space along with a dras­tic change in how long devices would attach to that space before chang­ing address again.

With­out those ends, and by cre­at­ing a net­work pro­to­col that would carry traf­fic while see­ing rad­i­cal changes in its address­ing space could cre­ate a sit­u­a­tion where an attack against a por­tion of the net­work would be seen as an attack against the net­work as a whole and solu­tions would be han­dled on a global basis.

So whether that net­work is shut­down because a polit­i­cal strong­man decides to do or an earth­quake dam­ages a region, the net­work as a whole would have some form of self-healing capac­ity to start rear­rang­ing the dam­aged parts quickly and with­out any involve­ment from the users in the affected areas (net­work man­age­ment should be the least of people’s prob­lems in a time of crisis).

Beyond the prin­ci­ples: Addressing

Since this would be a rel­a­tively new pro­to­col, I would throw some back­ward com­pat­i­bil­ity away. As pro­to­col devel­op­ment takes place, I can only assume that it won’t be until 2012 that we would see the first imple­men­ta­tions of this. As a result, I would go as far as to ven­ture that the par­ti­cle pro­to­col should not have to worry about IPv4 address­ing and should focus on work­ing with IPv6 instead. The rea­son behind such an approach is that IPv6 will increas­ingly be the new stan­dard for address­ing begin­ning in 2012. IPv4 sup­port, as a result, would be great to sup­port legacy sys­tems but this is about fix­ing prob­lems in the future so let’s sup­port the sys­tems that are future proof.

Beyond the prin­ci­ples: Implementations

Ulti­mately, pro­to­cols live and die by their imple­men­ta­tion. The first step towards imple­men­ta­tion would be a light­weight ver­sion of the par­ti­cle pro­to­col that could work on linux, android and iOS devices.

Why those first?

First, linux. Linux is avail­able in a vari­ety of forms, includ­ing as an embed­ded OS for devices. In the future, I think we could see the par­ti­cle pro­to­col as some­thing that would be avail­able over embed­ded devices (par­ti­cle boxes) that could be assem­bled cheaply and con­nected to power sources and net­work sources. Such boxes should be rel­a­tively inex­pen­sive to pro­duce (in dis­cus­sion with peo­ple, I’ve been using the price of $25 in parts as a stake in the ground) and all schemat­ics should be open-sourced.

How­ever, the chal­lenge with the hard­ware only solu­tion is that linux is not some­thing the gen­eral pop­u­la­tion uses on a reg­u­lar basis. So cre­at­ing a mostly linux-based solu­tion would attract the atten­tion of peo­ple who want to dis­con­nect things to those devices and get the to dis­con­nect them.

More dif­fi­cult to dis­con­nect, how­ever, is an over­all tele­com infra­struc­ture and here are I am mak­ing some tech­ni­cal bets: that iOS and Android will be the major oper­at­ing sys­tems pow­er­ing mobile phones in the future. Tak­ing that approach, a ver­sion of the par­ti­cle pro­to­col work­ing on those devices could turn every smart­phone with those OSes on them into a net­work point. I’m sure that this might make some peo­ple unhappy (Apple would prob­a­bly not approve) but I sus­pect that it could allow for quick deploy­ment of devices in regions need­ing them.

Any other imple­men­ta­tions would be wel­come, of course.

Con­clu­sion

Pro­to­cols are agree­ments and this set of con­cepts is only a pro­posed set. I’d like to see dis­cu­sion around the con­cepts in the tech­ni­cal com­mu­nity but, at the core, the prob­lem is sim­ple: we need an com­mu­ni­ca­tion net­work that works based on net­work effects, mak­ing the net­work much stronger with every node that joins it. Recent events, both geopo­lit­i­cal (Egypt, Libya) and envi­ron­men­tal (earth­quakes and tsunami in Japan) have shown that our net­works are still brittle.

The par­ti­cle pro­to­col is the begin­ning of a dis­cus­sion to strengthen the net­work at one of its low­est lay­ers and ensure that dis­rup­tion in one phys­i­cal loca­tion can be healed by its prox­im­ity to other locations.