But beyond a statement about the internet infrastructure, this is also about figuring out a solution to avoid losing the internet. So to help it, we need to define a way to build the atomic components that will help it become resilient to any attack, whether they are from repressive dictators or over-reaching corporations.

Fortunately, the internet happens to be at a key point in terms of its evolution, with the transition from IPv4 to IPv6 being upon us. With one major effort to upgrade large part of the infrastructure, it seems that new efforts could help us increase the overall resilience of the net.

A few years ago, I put together some basic requirements for a tool that I would like to see, something I had called a “Personal Relationship Manager.” A few years later, there are several of those so I’m thinking that I can start planting similar ideas into the ground for possible implementations by people who understand protocols much better than I do. The following are imperfect thoughts based on my understanding of core internet protocols and discussions I’ve had around them with several people over the last couple of years.

A lot of this, of course, has substantial precedence. For example, the idea of completely rewiring connectivity is not really a new one. Here’s Doc Searls, about 3 years ago:

Connectivity-as-infrastructure is soft in several senses. One is that you don’t need a big utility company to provide it. Another is that data and its protocols are soft. They have no physical substance, yet they have supportive qualities that are substantive in the extreme. That’s because the Net is a way of connecting. It is not the wires and waves that do the connecting.

.. and there has been a lot of work put into making the internet protocols faster and more reliable but few have taken the radical approach of making the net completely self-reliant.

So without further ado, here are some basic requirements:

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

I will now go into the thinking behind each of these points.

Open

Wikipedia defines a protocol as:

a set of guidelines or rules.

The challenge then becomes who is responsible for setting those guidelines or rules. Ownership of the responsibility for setting the guidelines or rules should be diffused around the community of interest on the internet. In that sense, the particle protocol should be a protocol without a head group. Decisions around what to include and exclude in its core should come from the community as a whole, with no central office, no central committee, no central individual, ultimately responsible for it.

Open is the way of the net, where ideas are given dominance based on their individual value and not based on the value of the individuals that brought them forth.

Because it is headless, open is uncontrollable. One could argue that peer-to-peer networks are the closest thing we have to open networks as every node in the network serves and routes things for every other node and the disappearance of an individual node does not impact the network as a whole for very long.

A corollary to open then seems to be that the network will be peer-to-peer, making it impossible to shutdown the network altogether. Peer to peer networks have been the bane of the music and movie industry for a decade because they cannot be shut down and it seems that if we are to build a network that cannot be shut down, we can learn from that model.

Open also means unencumbered from any pre-existing patent. The particle protocol should be something that is owned by absolutely everyone and by no one in particular. The reason for this is that lack of ownership means that the owners cannot be leaned on by any organization or government. With that point of friction removed, the ability to create backdoors or shut down such a protocol would be more limited and require substantial efforts on the part of the people trying to do the shutting down.

Open also means that the particle protocol should be sitting at the lowest level of the infrastructure stack with little or nothing below it. Once again, this is to ensure its resilience as the closer it is to the foundation, the harder it is to remove.

Last but not least, is that open is not about money.  That is because the core portions of the particle protocol should be free in a monetary sense too. However, beyond the core, innovation should be allowed so anyone can build (and make money) by providing extra components for the particle protocol. However, the people doing so must realize that any changes they decide to make to the core are dictated by the underlying principles regarding the protocol and must be redistributed in the same open fashion.

Light

The particle protocol should have the lightest CPU and memory footprint possible. Some may feel it is too much of a constraint but the particle protocol should be so light that it can run on most devices. For its initial version, I think that the ability to run, without impacting their pre-existing operations, on mobile phones, computers, and devices with as low a footprint as a 400Mhz CPU and 128Mb of RAM (Apple watchers may recognize this as the original specification behind the first iPhone: it is no accident as I believe the particle protocol should run on any smartphone in the future).

Light, in my view, also means unattached, which means that the particle protocol would be wireless by default. Sure, devices could be created to connect some points of the network to some wired network (and this could turn into a whole new sector for the telecom infrastructure industry).

Finally, light also means unencumbered of extras. The problem to be solved here is resilience (ie. it can’t be shutdown). Anything beyond that is extra. So the particle protocol should allow for TCP/IP to run on top of it but things like extra security, guarantee of services, and so on, should not be part of its core. However, I’d like to see some kind of a plug-in approach that could allow that protocol to be extended with such features by anyone who wants to.

Easy to Use

The first dotcom boom taught me an important lesson about technology: if it is not easy to use, people won’t use it. The internet was around for a long time prior to 1995 but it wasn’t until then that people adopted it. Why was that? I think it was due to two factors: first, Microsoft built a TCP/IP stack into their operating system, making internet access a question of configuration and AOL started splattering the world with their disks, making access to the online world just a question of setting up a username and password and handing out your credit card information to them. The rest was automated.

In order for the particle protocol to succeed, it should be easy to install and easy to use. By easy to install, I mean that it should be a question of downloading it and, if needed, clicking on an icon to install it but that would be it. The software would install itself, look for ways to connect to its peers, identify any peers nearby, and automatically connect, becoming 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 protocol installer would look for is all the ways in which it can connect to other devices (wired: eg. via a modem or ethernet / wireless: eg. WiFi, Bluetooth, EDGE, 3G, 4G, etc…) and attach itself to all the available modes without disturbing the other software attached to those. There should be, embedded in the protocol itself, a logic as to how it would prioritize its connectivity, based on how many nodes are available in a particular connectivity mode and how reliant other nodes are on its connectivity to more than one connection (eg. tying 3G communication to WiFi links).

By being completely invisible, the protocol would become something that can exist without being acknowledged and can be installed without much notice after installation. So, if you were to take Libya as an example again, hacktivist could work to install the particle protocol on every communication devices the government owns, and protesters would leverage those installation for their own communication.

The only way to stop such a protocol would be to completely shutdown every electronic device available in an area/country. While it is not impossible that some strongmen could go down that route (I’m thinking of places like North Korea, maybe), the impact would be that the only way to shut things down is to shut down your own communications line. While it is theoretically possible, such a shutdown could create a race as to who is bringing their own network back up in order to communicate. If we were to take into account network theory, this is basically creating resilience by ensuring that the information assymetry created by a network shutdown forces ALL the players to rush back to restoring it, thus restoring nodes for all sides at the same time. In a perverse way, it leverages the assymetry to get rid of it.

End-less

Many years ago, my good friends Doc Searls and David Weinberger argued that the internet was a World of Ends. The principles were sound but unfortunately, by creating a view based on ends, they opened the possibility for creating points of controls.

If the internet 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 random basis. Then exerting control over one point would not necessarily work. What if the addressing were to change on a time and location basis as well as some other factors based on sudden changes in traffic (spikes or drops) with violent drops in traffic resulting in a complete re-assignement of the addressing space along with a drastic change in how long devices would attach to that space before changing address again.

Without those ends, and by creating a network protocol that would carry traffic while seeing radical changes in its addressing space could create a situation where an attack against a portion of the network would be seen as an attack against the network as a whole and solutions would be handled on a global basis.

So whether that network is shutdown because a political strongman decides to do or an earthquake damages a region, the network as a whole would have some form of self-healing capacity to start rearranging the damaged parts quickly and without any involvement from the users in the affected areas (network management should be the least of people’s problems in a time of crisis).

Beyond the principles: Addressing

Since this would be a relatively new protocol, I would throw some backward compatibility away. As protocol development takes place, I can only assume that it won’t be until 2012 that we would see the first implementations of this. As a result, I would go as far as to venture that the particle protocol should not have to worry about IPv4 addressing and should focus on working with IPv6 instead. The reason behind such an approach is that IPv6 will increasingly be the new standard for addressing beginning in 2012. IPv4 support, as a result, would be great to support legacy systems but this is about fixing problems in the future so let’s support the systems that are future proof.

Beyond the principles: Implementations

Ultimately, protocols live and die by their implementation. The first step towards implementation would be a lightweight version of the particle protocol that could work on linux, android and iOS devices.

Why those first?

First, linux. Linux is available in a variety of forms, including as an embedded OS for devices. In the future, I think we could see the particle protocol as something that would be available over embedded devices (particle boxes) that could be assembled cheaply and connected to power sources and network sources. Such boxes should be relatively inexpensive to produce (in discussion with people, I’ve been using the price of $25 in parts as a stake in the ground) and all schematics should be open-sourced.

However, the challenge with the hardware only solution is that linux is not something the general population uses on a regular basis. So creating a mostly linux-based solution would attract the attention of people who want to disconnect things to those devices and get the to disconnect them.

More difficult to disconnect, however, is an overall telecom infrastructure and here are I am making some technical bets: that iOS and Android will be the major operating systems powering mobile phones in the future. Taking that approach, a version of the particle protocol working on those devices could turn every smartphone with those OSes on them into a network point. I’m sure that this might make some people unhappy (Apple would probably not approve) but I suspect that it could allow for quick deployment of devices in regions needing them.

Any other implementations would be welcome, of course.

Conclusion

Protocols are agreements and this set of concepts is only a proposed set. I’d like to see discusion around the concepts in the technical community but, at the core, the problem is simple: we need an communication network that works based on network effects, making the network much stronger with every node that joins it. Recent events, both geopolitical (Egypt, Libya) and environmental (earthquakes and tsunami in Japan) have shown that our networks are still brittle.

The particle protocol is the beginning of a discussion to strengthen the network at one of its lowest layers and ensure that disruption in one physical location can be healed by its proximity to other locations.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title The Particle Protocol. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

At $30/month, Wi-Fi service can currently be seen as an expensive toy for the mobile worker. But if you consider the possibility to make phone calls for the same price, the price seems low. Compared to most cellular phone programs that offer a few hundred or thousand minutes every month for roughly the same price, the idea of unmetered service could represent a huge growth opportunity for anyone offering a hotspot. However, the issue will then become one of available bandwidth. As more and more hotspots are added, the pervasiveness of Wi-Fi makes the possibility to bypass the phone network more real.

The next step in that evolution would be for the Wi-Fi protocol to include some kind of mechanism to check the strength of signal. If you think of the cellular phone system, you will realize that your cell phone conversation moves from station to station as you are moving. Every second, the cell phone checks where the nearest antenna is and changes access accordingly. This ensures that you get the highest signal possible and allows for the phone to stay connected even as you get further away from the original antenna you used. Wi-Fi does not currently have that checking capability in place but when it does, Wi-Fi phones could become more common.

It is interesting to see this happen as cellular phone companies might find themselves displaced in much the same way they are starting to displace land lines. New technologies keep cropping up that disrupt the way business is done and put more pressure on revenues (because they are, invariably, introduced to users at a cut-rate price in order to gain market shares).

However, the economics of wireless networks rely on a limited use of equipment (for example, as more people sign up for a mobile phone service, the quality of the service drops because more people are trying to use the same equipment). With the rise of Wi-Fi and the introduction of small operators (coffee shops, etc…) it will be interesting to see what will happen. My guess is that we will eventually see all the large mobile phone operators introducing Wi-Fi plans over the next 12–24 months. We will then see the rise of one or two new companies that will hook up smaller operators into a different set of networks. As the cost of providing the service increases (because more bandwidth will be required), the smaller players will shake out of the market. Once that has happened, the winners in that fight will start to increase prices again.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Disruptive Technology. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Tivo and Digital Media Servers. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

First of all, by acquiring Linksys, Cisco gets a strong foothold in the small office/home office market as well as the hobbyist/consumer market. Why? Largely because this is where Linksys’ strength is. What Cisco gets out of this is a new source of revenues in a market it has had troubles getting into. The announcement that they will not change the name of the company and will let it run as an independent unit seems to point to that end.

Second, it provides Linksys with strong support in enterprise sales. Linksys has been getting into the enterprise largely through the back-door, with employees installing cheap wireless routers in offices. Now, with Cisco’s backing they can get into the enterprise as part of a more complete solution.

The next question is what this does to Cisco’s strategy as a telecom vendor. Linksys already sells voice over IP products. There may be some people at Cisco edging their bets in terms of the telecom bet. It could be that they figured that VoIP could also come in through a cable connection, which in itself would undermine sales of equipment to large phone companies and move more telephone traffic into the hands of cable companies. Alternately, Cisco could start selling solutions that would allow for a complete end to end solution for VoIP: Large offices would use Cisco’s existing solutions and smaller branch offices could take advantage of the Linksys offerings.

However, the real prize in this acquisition is in the wireless space. Linksys has already established itself as one of the strongest players in that market and Cisco will probably take advantage of those gains, eventually demising its own offerings in that market. The advantage for them is consolidation of product lines and an early toe in the 802.11g arena.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Cisco acquires Linksys. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

In the discussions surrounding my suggestion of how we can level the playing field, I’ve learned a couple of things:

First, whatever solution we come up with must be easy to implement. It is easy for those of us who are more technical to come up with XML rules and complex structure to represent the world. However, most people neither have interest nor experience in experimenting with such thing. Hence the first rule of any answer is that whatever solution is implemented, it needs to be simple.

Second, trust is a very large issue and some portions of it are being addressed. For example, FOAF allows you to establish trust between friends. But what about concepts (can I trust this person’s opinion on a movie review? can I trust their opinion on an Internet standard?), things (do they own the product? did they buy it or was it given to them for free? If it was given to them for free, who gave it?), people (I think that’s somewhat covered by FOAF but there’s more that needs to be built into it). This is a wide space and needs to be properly categorized for a model to work.

The next question is one of granularity. Should a trust statement apply to a whole site or to a particular entry on that site. As Scott points out “implementing this on a per post level would definitely increase the amount of work to blog content which isn’t good at all.” So what’s the option here? Is there a way to modify editing tools so they have a caveat emptor option?

Another question is how that information is displayed. Should there be a browser plug-in? an RSS reader plug-in? Should it be embedded in a feed or a page? How would the user know when the level of trust on an entry or a site is lower than expected? And, more importantly, how would one be able to check that a “trust statement” can in itself be trusted.

Lots of questions to which I do not have an answer yet but I think that they are worth pondering and I will post further on this soon. (but can you really trust that last statement? )

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Trust, truth and networks. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

Yes, absolutely free. How much for that domain name in the window? Nada, zilch, nothing.

But for a lot of people, it seemed too good to be true. And for a lot of people, it just didn’t happen. At about 9:01pm, the site started to experience VERY sluggish response times. First, they claimed the NSI registry stopped answering.… Then their nameserver crashed… Then the web server crashed. Then, hopeful registrants around the Internet started talking.. and talking… and talking…

It’s Scalability, Stupid!

In the end, the issue came down to one simple overlooked issue: Yes, you guessed it.

It’s give me an S…
give me a C…
give me an A…
give me an L…
give me another A…
tired yet?
give me a B…
give me an I…
and another L…
and another I…
and a T…
and finally a Y!

What does that spell.… SCALABILITY!

While they were expecting under 500,000 unique visitors, they logged over 2 million attempts to enter the site and in the end under 10000 names were registered.

As a result, RegisterFree went from being the new kid going against Network Solutions to joining the ranks of Victoria’s Secrets and ABC in the annals of sites that failed to scale to demand.

By 12:10am tonight, RegisterFree issued the following statement: Ladies and Gentlemen:
This was truly awesome. We never expected ANYTHING like the AMAZING response we
received to our RegisterFREE Free Hour Promotion. At certain times over the course of the evening, the NSI registry (the universal database which provides domain name availability checks) was unable to process requests for those domain name availability checks. As a result, traffic was significantly slowed at times, and some people were unable to register their domain name. We hope to receive better support from NSI Registry during our next promotion, which will be coming up very shortly. We can safely say that hundreds of thousands of people came to RegisterFREE.com tonight, and thousands were able to register their domain name for free. At this point, we ask all those who were unable to register a domain name to send an email to cs@registerfree.com and let us know, so we can deal with each query personally. Congratulations to all of those customers who did get through and were able to submit their registration request. RegisterFREE.com STRONGLY believes that Domain Name Registration should be 100% free, and we will have this promotion again very soon. Again, thank you for your continued patience and support as we try to make all domain names 100% free. The RegisterFREE team.

Now I can hear many of you scoff at the fact that they couldn’t scale.

Yes, it’s true, they mis-planned but how many of us plan for such traffic surges? And how do you plan for something like that. Do you overbuild and hope that people will come? What is the factor by which you have to multiply your expectations and get an appropriate number. Last summer, drugstore.com went down on its first day, deluged by over 1 million requests. Should we use 1 million as the magic number?

Many large web sites have been designed with little attention paid to scalability and every time one of them fails, we all look bad. Why? Simply because the Internet is considered as unreliable when that happens and THAT scares away potential customers.

Don’t believe me? Try asking my 82-years-old neighbor! When Yahoo! and Ebay were taken down, she was so scared by the negative press that she told me she wouldn’t shop online because hackers would steal her credit card and overcharge it. After explaining to her that she was only liable for $50 maximum and that incidents like this were rare on the Internet, I think I managed to rescue one more customer on the Internet.

But enough negative publicity along the lines of what I expect to see in tomorrow morning’s newspaper (especially considering the great coverage RegisterFree managed to get BEFORE the event) is undermining consumer confidence in the Internet and that is what I worry about.

But Wait! It Gets Better!

More troubling was the fact that they were blaming it onNSI. While I don’t particularly like NSI, I have to say that their whois was working tonight. I spent all evening checking domain names in the NSI whois while I was trying to get into registerfree.com. It worked fine for me, actually working faster than it usually does. I even ended up registering domain names from there. RegisterFree.com pointed out that someone at NSI decided to take the “registry processing systems offline for an indeterminate amount of time” but other registrars were fine. After the promotion ended, RegisterFree was still the subject of some discussion regarding ethical issues. It may be just a technicality but other registrars like Bulk Register and Enom (just to take a couple of names from the ICANN accredited list) are cheaper.

So can registerfree be trusted? I just provide the links. You make the call.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Trouble in RegistrarLand. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

Why network computers fail

The Denial Of Service attacks that crippled several websites this week show that our increased dependency on the network is not without its faults. I was talking to a friend of mine who was complaining about not being able to read her email (she’s got a Yahoo! account). Meanwhile, other users were deprived of use of their calendars or address books because they could not access the service. Did this information need to always be online? Not really. While the online element allows portability (being able to get to those applications from anywhere in the world… anywhere, that is, where you can get access to a net connection and a browser) but throws in an extra wrinkle: you have to have access to a network. Any problem with the network and the application fails. Ultimately, network computing fails because it tries to offload too much to the server.

Why non-connected devices fails

Meanwhile, non-connected devices have taught us that they can do certain things really well but could do them better if they were connected. Not every application needs to be connected (most of the time, I don’t need my word processor to be connected) but most seem to be dramatically enhanced by being connected. Games? Most of them are interesting but ultimately, computer games were a fallacy in that they didn’t allow for multiple players. The net connection allows for that. Business applications? New levels of sharing are now possible with business application, allowing teams to be more efficient and to work across long distances.

A new paradigm: Hybrid Computing

However, those applications can stand on their own. What we are witnessing is the rise of a new kind of applications and a new kind of computing: Hybrid Computing.

What is Hybrid Computing?

In order for an application to fall into the hybrid computing category, it has to be able to follow two conditions:

• The device or software program should be able to work on its own, without being connected to the net at all time.
• The device or software package is enhanced through its connection to the net.

Examples of Hybrid devices and software packages

While we all already have heard about the Palm VII wired palmtop, a device that offers the functionality of regular palmtops with a little extra when it comes to connectivity, there are many other pieces of software that have not received the same kind of publicity. For example, imagine being able to get information about the CDs you’re listening to while you’re listening to them. Yes, you can do so on your computer but now, you can also do so with the TuneBase family of CDDB-compliant devices, that hook up to your TV and CD player. While still a little kludgey (one should have all that directly embedded into a single CD player unit, it shows the power of hooking up a CD player to the web. The player can get enhanced information from the web but doesn’t have to in order to work: that makes it a hybrid application.

Lately, I’ve also been playing with a new application from Contact Networks. It’s a simple piece of software that hooks up to your outlook directory and allows you to exchange electronic business cards over the web. If, for example, I update my information in that contact manager, the change is sent to the web. If you have the same application, the next time you synchronize your address book, my contact information will be made current in your contact manager. It’s a great concept if people start using the application. After all, who really has the time to keep track of ALL the contact info lines for everyone they’ve encountered. Once again, this is an application that takes a non-networked concept (address book) and creates an hybrid application around it.

Those hybrid applications harness the power of a local machine and use the net to enhance that power. Either way, they can work on their own or connected. And for years to come, until we make the net truly ubiquitous (have you ever tried using a net connection in the New York Subway, let alone make a cellular phone call?), we will have to live in a world where large areas are off the grid.

Over the next few years, as computing devices become more pervasive, we should start seeing more of those hybrid devices because after all, the Internet is nothing more than another evolutionary step in the computing and communication world.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Hybrid Computing. You can follow him on twitter here or receive his weekly newsletter by subscribing here.