When global agreements aren’t necessary.

I want to eliminate the need for ICANN — the group that decides all the Internet names! Did that get your attention? That’s good, but please note that I would like to have ICANN around for a very long time. The operative word in that first sentence is ‘need.’ I want to eliminate the need for ICANN, in the same way I want to eliminate the need for any world atlas when I’m only travelling just a few blocks away. While an atlas may be detailed enough to be useful for such a short trip, it’s definitely more cumbersome than necessary. I don’t even need to know the name of the city I’m in, if I’m only travelling along 1 street, just 2 blocks to the south. I could change city borders during that trip, and I wouldn’t need to realize it, unless there happened to be a wall at the city border line. In that strange case, the wall should have a plaque or guard that tells me about the city border. I don’t need the atlas if I can just read the plaque when I get there.

So how do we name things without agreeing on the names ahead of time? Simple — when I’m looking for something, my name trumps yours. When you’re looking for something, your name trumps mine. No need for bickering about it, because both of our names work for us, the way we each want them to. We only have to agree on names when we want to consistently label the same thing from our different vantage points. If you have a name for something and I don’t, I can just simply use your name, rather than going through the work of making up my own. I can also just make my own aliases to the same thing later.

Here’s a series of examples to clarify my point. I’m just going to assume here that the address systems overall resemble UNIX file systems, which look like this:

/top_directory/sub_directory/sub_sub_directory/file

Now what I’m looking for is not a directory or file — it’s an online service of some sort. For example, under the current ICANN way of naming things, everyone looking for the Google search service would just use “google.com.” “Com” is a top level domain for all corporations, and “Google” is the domain name of that particular search corporation. Doesn’t the word domain sound so… feudal? Even if you worked inside Google, you still might have to use “Google.com,” unless you know the server IP number. That IP number takes longer to type than “Google.com,” so there’s no real point in using anything but the domain name.

In this new non-ICANN naming system example, I’m just looking for my own online service, which I host on a server box inside my own apartment. Here’s the name path to the server of that service:

/

That ‘/’ essentially means “start at the top, and go no further.” I can stop right at the top, because in my naming system, my own services always come first! This address path or naming system wouldn’t work for anyone else, because when they use ‘/’ they just see their own services, not mine. At some point, we do have to reach some agreement on shared names. But the main point is that we don’t have to go all the way to a big powerful organization like ICANN to get them to agree on our own names. We just have to agree amongst each other.

For example, if we all live in the same apartment complex, we can agree to simply name our services according to our apartment numbers. I live in unit 6 and you live in unit 30, so either of us could use this path to get to my services:

/6/

I don’t have to use “6/” to get to my own service, but it works anyway, because we agreed on this name. To get to your services, we could just use this address:

/30/

Again, you don’t have to use “30/”, but both “/” and “/30/” work for you. Only “/30/” will work for me, because we don’t share that apartment.

Let’s bring another friend into this naming game, because we both want to use her online data services too. She lives down the same street, but in a different apartment complex. Her apartment number is 6, so that conflicts with my apartment name. Our complex’s street address number is 1534, and hers is 1537, so we agree to add a street number layer to our respective naming systems.

Her address (for us) now looks like this:

/6/1537/

My address looks like this to her:

/6/1534/

And your address looks like this to her:

/30/1534/

Again, neither of the residents at 1534 (you and me) need the “1534/” portion to get at services within our own complex, but these addresses work anyways. For our female friend down the street, “/6/” or “/30/” would take her to completely different services, hosted in her apartment complex instead of ours.  We add the street address number here for the same reason you wouldn’t tell someone who lived in a different apartment complex to “just go knock on the door of unit 6.” Their “door of unit 6” is very far away and different from yours.

I call this user-centric naming. We, the computer “users,” are each the center of our own online universe. We can make a lot of pronoun and descriptive aliases to our own services — like “me,” “I,” “Jared,” “Apartment_6,” “cybermonkey,” etc. But we don’t have to! Anyone else can use these same pronouns for themselves without conflicting with me. The center of our online universe is each just “/.” We each start at our individual centers, and work outward from there.

The next apartment unit south of me is “/7/.” The next apartment building south is “/6/1532/.” The manager in that apartment set his services as the default for the complex, so I can also just use “/1532/” to get to his services. The same apartment one street west is “/6/1534/Aardvark/”. The apartment complex in the next town (with the same address otherwise) is “/6/1534/Main/Nextville/.” The apartment complex in the next state south (with the same address otherwise) is “/6/1534/Main/Myville/Louisiana/.” Most people in the U.S.A. agree you can use “LA” and “Louisiana” interchangeably, so “/6/1534/Main/Myville/LA/” works too. People who live in Myville, LA can leave the “Myville/LA/” part out if they want to. They have to use “/6/1534/Main/Myville/MS/” to get to my services, but people in our town can leave the “Myville/MS/” part out. People in a different country might have to use “/30/1534/Main/Myville/MS/USA/” to get to your services. People on another planet would use “/30/1534/Main/Myville/MS/USA/Earth/.” That address works for everyone on Earth too, but they can leave “Earth/” out if they want to avoid the extra typing.

Now you may be asking, what if I want to name my server “chiapet”? Go ahead! If you have other servers, like maybe “donkey”, you could choose one of the two as a default server that the apartment number “/30/” address goes to, instead of making your complex-mates enter “/chiapet/30/” every time. I could also make my own “chiapet” server and you would have to use “/chiapet/6/” to get to it. You could also name a server 30, so that address would be “/30/30/”. So below an address level in your control, you can add as many inner layers as you want. If you provide default paths that outsiders get forwarded to when they enter your basic “/apt_num/street_num/street_name/etc/” address, no one else ever has to deal with these inner layers. You could also provide direct paths to protected inner layers only to trusted friends. It’s ultimately all up to you. If people are coming to your services, then past a generally agreed “ownership” border, addressing is done under your naming system.

One interesting aspect of having your own naming system is the ability to make your own abbreviations or shortcuts. If I don’t have a server named “foxtrot” and you do, I can set up “/foxtrot/” as an alias to your “/foxtrot/30/” server, so we both get to skip typing the “30/” part every time. I can also shorten “/Whitehouse/Washington/DC/USA/Earth/” to just “/whitehouse/.” Anyone else is free to point their “/whitehouse/” to any other house, preferably one painted white. You could point your “/whitehouse/” to my /whitehouse/6/” — which has the effect that your “/whitehouse/” service destination changes when mine does. We don’t all have to agree on the one true whitehouse, and we can each change our minds about it any time it pleases us.

This user-centric addressing system makes ICANN’s naming bureaucracy completely unnecessary, even as just an arbitrator. You don’t need to arbitrate decisions when there’s inherently no conflict.