Oblomovka

2007-10-10»

I've now had a few nightmares, I am sorry to report. Recurrent nightmares, or at least endless rehashing of the NIGHTMARE THAT IS MY BOURGEOUS LIFE was what led my subconscious to forgo the whole dreaming thing for the last few years. It's not too bad, though - my last nightmare had dragons in it. We hid under the kitchen table; very effective. Then, Mike Myers turned up and filmed the new Austin Powers in my bedsit. He's uch more humble in real life. And by "real life", here I mean "in my dream".

So, a lot of people smershed my mentioning of the old P2P revolution in the last entry with my general thinking about the future move to the edge. I hadn't intended to make a direct comparison, but it's worth noting, as many did, the changes in the network since the glory days of 2001, and how that would effect creating edge services now, as the P2Pers were trying to do then.

First, and most obviously, the massacre of dial-up users is proceding as planned. There are still plenty of them out there, but we no longer have to feel guilty if we do not care about them. More importantly, always-on Net connections are pretty much everywhere. Even dynamic IPs are generally fairly static in the medium term. Hooray!

Second, the realisation by most protocol-designers that it's an HTTP world, and that we just try and communicate in it. HTTP was a fantastic fit for the early net, so good in fact the modern Net has now co-evolved to be a good fit with HTTP. Nobody cares a goat's fig about NAT because it don't mess with the HTTP -- and that's one of the main reasons the Internet is now so NATty. That makes everybody lean toward HTTP to work well in this new infrastructure. One of the reasons why REST stuff just works is that it lives in HTTP space, so there are no sudden moves. P2P protocols have always had HTTP elements, but I think it may be true that whatever develops next in the peer-to-peer realm will just look like local webservers talking in a RESTy way with other webservers - or to talk with humans or other userspace applications (I count humans as a "userspace application").

A corollary of this is that I think you really have to just deal with everything else that comes with HTTP -- including DNS. All the old P2P dances have sexy URLs of their own devising, and hashes, and DHTs, and all that jazz -- but without popping up in DNS-land, these servers are just invisible to everyone. Even Microsoft's own P2P DNS-a-like, PNRP, falls into this category. Sure, your machine may be announcing to other Microsoft peers that it's My-Computer474342.pnrp.net, until Microsoft does the obviously sensible thing and starts resolving those addresses in standard DNS (please somebody write in and tell me they do) , those addresses are just burial plots in a walled garden.

(John Gilmore once proposed a decentralised solution to this problem, whereby the toppest level domain would actually determine which protocol the IP service should use to find the rest of the domain. The current TLDs would be grandfathered in as '.com.icann', '.net.icann', etc. You wouldn't need to change any URLs, because search domain '.icann' would be default. But 'My-Computer743473.pnrp.' would run using Microsoft's P2P name-finding algorithm, '7a7898bef783ed731aaf.bittorrentilikehashes.bittorent.' would find a bittorrent resource, and so on. Obviously this would reduce ICANN's role to one Postel-looking geek adding a list of protocols onto a list and chatting to the BIND guys. Since that geek wouldn't need a multi-million travel budget, it will never happen.)

But I digress. The key point here is that if you can control your own DNS, and your can control your own webserver, you're pretty much ready to go as a generic everything server on the Net, whether you're hanging off the edge, or partying in the affluent middle zones.

Oh, you say, but what about NAT! What about the unreliability of the edge! What about if the kitchen table was made of wood, and the dragon just went RAAAARGGGGH and breathed fire over the top of it?

These, and other nightmares, I will discuss after this word from my sponsors.

The Democrats are currently considering caving to the White House on granting retroactive immunity to the telecommunication companies for breaking the law and spying on your phone calls. It's all going to happen this week. If you haven't already, please call the Congressional leadership and tell them not to give an amnesty for lawbreakers.

2007-10-05»

The two background themes of this blog conspire: my digestive problem is keeping me awake, and stopping my dreams. Well at least I'm not fitfully asleep, dreaming that there's a small weasel biting the left side of my trunk or something.

Lots of great conversations with people about my ongoing flailing ideas here. I am awful at replying to email, because by the time I've found the reply button, there's another email to read and oh, bright shiny blog thing, but I did read them all. Even the guy who said that I'd just rediscovered Ray Ozzie's Groove (sorry if I was a bit rude in my reply, Andre).

What made me rub my hands with glee was that all of the replies were by people who I know are much smarter than me, which means I'd managed to fulfil my primary aim of expressing an idea so irritatingly vaguely that better heads will fill it in for me.

A telltale of my favourite smart people is that they don't prematurely pessimize, which is to blindly announce "Well that would never work because X, Y, and Z". Buzzkill. No, my kind of smart people go "Well, you'll have to fix X first, which I think you could do by doing A, B, and -- oooh, I bet we could solve 'Z' with some string and that doorknob over there! Let's go!"

However, to speed things along, I'm now explaining to such people there's a class of problems that I don't even want to fix in this thought experiment (which, to remind everyone, is -- what happens if we push to the edge everything that we're currently throwing onto Google Documents and other Web-based services). Examples of this class of problem in my gedankenexperiment are:

• There's not enough bandwidth for a home or mobile servers.
• Customer-level connections are too unreliable for services.
• Hard-drives are too fragile to lug around with you.

These are examples of problems that I hand-wavily announce will bore themselves to death. That is to say, I don't want to talk about them, because I believe they are very dull, and I am confident there are clever people who don't find them quite as boring as me will solve them for me.

There is risk here. You do have to be careful of what problems you assume will die of boredom, because sometimes they turn on you and bore your entire future vision to death instead.

NAT traversal is a good example of that. NAT traversal is a tremendously dull topic that was far too boring for most of the people excited about P2P technologies in 2001 to think about for very long (although the ones that did find it fascinating kept the rest of us up until 4AM drawing funny diagrams). They had a revolution to lead! Endless opportunity lay just beyond the horizon!

P2P was what Web 2.0 was supposed to be, incidentally, five years earlier, almost literally (the Web 2.0 conference came from Emerging Technology which came from the ashes of P2Pcon). Sadly, P2P never developed escape velocity, and the entire fledgling industry collapsed more-or-less into BitTorrent and Groove, and that was that. NAT traversal was one of the problems that still hinders it, as is the fact that client PCs generally don't act like servers, but vanished off and on the networks in irritating ways. By the time you'd coped with constantly self-dismantling networks and impossible to reach edge nodes, I understand most P2P developers wanted to gnaw their own legs off in tedium. The endless opportunity had to be endlessly postponed while everyone fixed this one last problem with getting the Network to work over firewalls, and with constantly changing dynamic IPs, and a whole rats-nest of other dull issues.

If you want a more modern way of thinking of the risks of a boring problem, think of the utterly dull issue of cross-platform JavaScript compatibility. An entire generation of AJAXian prototypes died on intranets because they weren't cross-platform, and it took decent JS frameworks and know-how built by Stakhanovite miners in the dark pits of tedium.

But we prevailed! The problem, pinned down by the corpses of endless headslapping programming hours, finally died of its own boredom, and JavaScript ultimately came into its own. About seven years later than anyone imagined.

Boring problems can heavily delay the arrival of the future, but they don't really change the game.

So because we are all Buckminster Fullerish futurists here, let's airily discount them. Our problems with bandwidth, at least in the United States, are down to awful, creaking monopolies, that will slowly die choking on their own gorged subsidies and foul bellhead toxins (and if not, there's always China). The fragility of harddrives isn't going to last another generation.

The unreliability of consumer connections, though. Um. I don't know whether this is a problem that will die or be fatal. One could argue that it was what actually *did* kill the P2P unboom. Certainly, unreliability is something that the Internet is supposed to deal well with, and when it doesn't, we could certainly do with some deliciously generalisable solutions. It's not like it's not a problem if you keep servers where they're supposed to be, in yonder cloud. When your main server goes down, what do you do? And can you do that when your edge server drops off the Net a couple of minutes every day, or a bunch of seconds every hour?

Oh, all right. Have your damn comments. You're just going to pile on and say you don't have the slightest idea what I'm talking about, and have I tried peppermint tea, aren't you?

|