[Web 2.5] Why Email Persists: It's P2P

"Anne 2.0" writes that email persists despite numerous attepts to replace it over many years because it is "good enough". Benefits she points to are: 1) Interoperability 2) Personalized Organization 3) Easy access control 4) Single point of information access. All good points, as are those that she enumerates where email fails.

However, there is a fundamental difference between email and all the mechanisms that have been proposed to obsolete it: Email is peer-to-peer. Everything else is server-centered. Email uses servers, true, but they merely provide relay service or secondary storage. The email application sees a field of peers, identified by unique addresses, and reachable via the nearest SMTP service.

What hasn't been tried is applying the user-centric P2P approach of email to writing and content-creation apps, which are the fundamental tools of the knowledge worker. Isn't P2P messaging really a feature of these apps, rather than a disconnected app itself?

Were a P2P wiki framework to emerge, enabling private wikis distributed among teams of collaborators, with commentary or chat embedded on any page, would the email client still persist as the primary—and frustrating—tool that it is today?

[Web 2.5] UWB Wireless Finally Working?

A Japanese outfit I've never heard of has announced a Wireless USB hub. Is ultra-wideband finally going to escape from the demo hall into the real world?

This device is essentially a wireless docking station for your PC. You plug a flash-drive-sized UWB radio into a USB port on your laptop, and plug USB peripherals into their small hub unit. Voila, you're connected to your peripherals wirelessly.

If this gizmo actually works, terrific. Even if it does, it's a bit of a yawn. UWB is supposed to empower ultra-mobile devices, like media-pods, cameras, smartphones, and flash drives. Imagine a flash drive that you never have to plug in to access; walk up to any PC, and have access to all your data (and always-on-you web apps :-) at gigabit speeds. Here's hoping this is a first commercial step towards that future.

[Web 2.5] The 'Web Office' Is a Tiny Niche

The web has solved a lot of problems in the past decade, but has had little impact on personal and team computing. We're still banging away in MS Office and shoving docs around via email, or piling them up on file servers. Any number of web-based online services and intranet software products have been offered to change this. They have seen relatively low adoption. As Exhibit A, I offer this Alexa graph of well-known web office (aka Office 2.0) sites, including—for contrast—the popular sendspace.com email-attachment manager:

click for full size

The Alexa numbers may well be inaccurate; what I find interesting are the trends of this graph. Why do they look so flat for all but email attachment distribution? I believe these services can't spread virally, unlike consumer web services, because business technology requires approval by management and IT staff. Management is leery of shipping confidential data out to web services run by a third party, and even if IT depts had ample time to evaluate new tools, they are uneasy about systems they can't control.

Certain "on-demand" apps like salesforce.com have made some headway among businesses which don't have the IT resources to deploy such solutions in-house. Management can approve outsourcing for capability which they couldn't otherwise access, e.g. CRM. But email is the only personal app which has made substantial headway as a service for businesses (perhaps because incoming email originates offsite anyway?).

Intranets.com, the biggest success of the Web 1.0 team sites, was acquired last year for $45M, a little more than they'd raised in venture cap. That was after six years of chasing users. Can an AJAX UI change the adoption curve of such sites? Check the trend lines on the graph for jot.com and projectpath.com (the most popular of five Basecamp domains), and draw your own conclusion.

The online web just isn't reaching a lot of users in this space, and server-based intranet solutions don't spread virally either, as end-users can't set up servers. The always-on-you web can change that.

The always-on-you web is any web app that runs on a user device (laptop, Wi-Fi smartphone, flash drive) and shares data with other users on a p2p basis. It's a web app that doesn't require an intranet or online server. It's a web app that the user carries, so it's always-on-you, as opposed to always-on(-if-you're-online). And it's a mechanism which can spread virally in a business environment, because users can deploy it themselves.

[Web 2.5] The Office 2.0 Conference

I just came across the web site for the upcoming Office 2.0 Conference which has an interesting list of speakers from web 2.0 startups.

As you might expect, most or all of these outfits offer hosted or intranet solutions. As such, they have to run the gantlet of the corporate IT dept for vetting/approval before they can solve any user problems. In other words, they can't spread virally among most enterprise users, a problem which consumer web services don't have.

Nonetheless, the goals of these startups are much the same as those of the always-on-you web, even if their solution architecture is Web 1.1 :-)

AOL Releases Search Logs. Who's Next?

Several hundred thousand paying AOL members have just been deliberately stripped of their privacy to the entire world.

Oh. My. God.

Now, folks, is there any question whatsoever that personal and business use of online apps like Writely, Basecamp, and Google Spreadsheets may be unwise?

As a member of such services, you don't own your data, and therefore you can't protect it.

Most ordinary web surfers already get this, which is why web-based personal computing apps have faired so poorly over the past decade. I wonder when the webtopian pundits are going to wake up.

Update: AOL's apology isn't remotely satisfactory. What are they doing to put the genie back in the bottle? They need to launch their legal eagles at those sites now redistributing this data, even if the license they attached to it allows redistribution.

[Web 2.5] Coming Attractions

I've been unable to blog much in the past month and topics for blog posts are piling up. Here's a preview of the posts coming in the next couple weeks...

David Beers, in an essay on his blog, proposes a mobile phone approach to the need addressed by the One Laptop Per Child (OLPC) project. He favors the "always-on-you web" model with a phone as the personal server device, rather than a flash drive. Wi-Fi smartphones would enable this, although Bluetooth or UWB (aka Wireless USB) are preferable for their point-to-point networking, i.e. no access point. (Wi-Fi can do that, but it has to be reconfigured by the user, who then loses Internet connectivity.) Unfortunately, Bluetooth has had little success outside of the wireless headset, and UWB continues to be next year's big thing.

* * *

Just to point out a flash-drive-based app system that is NOT the always-on-you web... Lexar is promoting the Power to Go software, which enables a variety of Windows apps to run directly from a flash drive. You could call this the "always-on-you office". This is cool, but if it's a web-oriented future we're rushing into, this is a backward-going time machine.

* * *

A reader wrote in to point out the Bouillon Project, which enables a peer-to-peer, worldwide wiki, wherein pages are accessible only when they've been recommended by your "friends" in the network. This sounds pretty neat, but it's not obvious to me what the mass-market application is, outside of the social networking game. I'll try to keep track of this to see what application ideas they propose.

[Web 2.5] The WebOS Bandwagon

Paul Boutin ought to jump off the WebOS bandwagon and have a look at the road! Like so many others for so many years now, he trumpets the vision of the WebOS, whereby PC apps and data move online... into the clutches of a posse of middlemen: the app service, the network service, and the billing service.

I've written at some length on this blog about why that model hasn't caught on (and won't), and about an alternative model, the "always-on-you web", that brings web benefits to personal and team software without forcing your apps and data online. Have a look at the "Key Posts" sidebar group on my main page.

But the bandwagoneers play on, content to speculate on the road ahead, rather than contemplate the road underfoot, which is wholly impassable.

Dear Tim O'Reilly

Dear Tim O'Reilly,

I chose the name Web 2.5 for my blog (subtitled "the always-on-you web" and the first result at Google for "Web 2.5") because I believed the term "Web 2.0" to be generic. I would not have chosen this name had I known that CMP's trademark was in the works, because in that case a conference named the "Web 2.5 Summit" could be said to confuse the market, even if a Web 2.5 event sought a completely different audience than your Web 2.0 Conference.

I accept your assertion that your conference defined the term Web 2.0 as it is now broadly used. I agree that you have established commercial ownership of the term for conferences. And I know your motivation is pure when you assure the web community that Web 2.0 can continue to be used without restriction outside the conference context.

The trouble is that much of the web community is not comfortable with a term that is restricted so. We find ourselves in the bind of having embraced your term enthusiastically, widely, but now admonished not to use it, nor similar terms like mine, for conferences. We feel blindsided by this turn of events; we have a great deal invested in this meme; we are not sure how to respond.

We still earnestly hope, despite your signals to the contrary, that your partnership will cede the term Web 2.0 to the community, and rebrand your conference ever so slightly (a move that would surely generate tremendous coverage at this juncture). That feels to us like the kind of magnanimous gesture we might expect from your organization, at least as we understand it from its track record in the community.

We will be set adrift, for a time, if you refuse us this gesture. What new label should we apply to our movement? What thought leader should we turn to? What cost will this transition exact? Our creativity, I'm sure you will agree, is better spent in other endeavors.

Most Sincerely,

Liam Breck
Network Improv
5th of June, 2006

[Web 2.5] Eliminate E-meetings, Collaborate Better

I just came across this fascinating post on collaboration. It posits that group discussion fails when soliciting ideas and feedback. The first few replies in a discussion may be authentic, but every other reply is tainted by them.

It proposes one-on-one email between the facilitator and each participant, e.g. BCC all participants with the request, then summarize their replies, without attribution, to all for feedback/vote via BCC again. This restricts "conversation", which makes sense; everyone knows what a waste of time meetings are.

In the context of peer-to-peer wikis, a dicussion/chat mechanism could provide a "deferred reveal" feature, i.e. all responses are posted to the shared space, but if the topic is marked "no-reveal", only posts by the facilitator are visible to everyone, until the facilitator unmarks it, or enough time elapses.

Going further into wiki editing, the facilitator would put up a page and request enhancements, and participants would change the initial page, without seeing others' changes. The facilitator would then merge the best stuff. How big a pain is merging vs. losing great ideas that don't emerge, and arguing about lesser ideas?

Reminds me of "management by walking around".

P.S. don't read the other comments before leaving yours :-)

[Web 2.5] Nokia Releases Mobile Web Server

Nokia's open source Mobile Web Server software turns your Symbian phone into an Apache server. (They should have called it the Pocket Web Server.) Browsers reach your phone via the internet through a gateway component, which routes traffic to the wireless service. It makes the phone in your pocket internet-addressable, provided you have a data plan on your phone.

How would you use this? Personal publishing and file-sharing come to mind, e.g. offering photos and recordings of the event you're attending to an audience of friends. Everything you capture is immediately accessible to them, without a separate step to post it.

This is pretty cool, but it's not what I mean by the always-on-you web. The reason to carry a web server, or more importantly a web application server, is to enable productivity and team apps with a web UI. That is, a UI where interlinked pages, with hypermedia content, are the focus, instead of files/folders, applications, and a stack of windows. A web UI also allows you multiple local screens, each of which may view different pages in your webs/wikis. Users would naturally want to share some pages; those would be sync'd peer-to-peer, whenever net connectivity is available.

The portable web app server gives you a framework for online web apps like Writely and Basecamp, without driving your data onto the grounds of a third party, nor forcing you online whenever you need to edit. (That's key; most knowledge workers can't simply sign up at an online app service and start posting company data to it; you have to get approval from IT mgmt. That's not just a pain, it isn't very gosh-darn likely!) This personal web service could run on a wi-fi smartphone, an Origami slate, or from a flash drive on any available PC.

Update: Turns out that this post is a decent response to Gabor Cselle's recent musing, What's Missing in Web 2.0?.

Thanks to Oliver at MobileCrunch for alerting me to the news.

O'Reilly, Get Real

There was an O'Reilly-style way to handle the trademark issue: 1) Announce that CMP was about to receive the servicemark. 2) Note that, since the filing, many web 2.0 events have occurred. 3) Indicate their desire to strengthen the Web 2.0 Conference brand. 4) Ask the web community for feedback on how to proceed.

Monday Update:
During this debacle, many bloggers have noted that they never liked the term, and please can we try a different one now. As you've gathered from the title of this blog, I think it's a fine moniker. The web has evolved; blogs and wikis are novel and genuinely useful, and advertisers are crawling all over it. Social networking is probably a fad, as are other aspects, like Writely and Basecamp, but it's all worth trying. And the web will evolve further, inventing tools that give ordinary users a web context for everyday work without forcing them into the clutches of third parties—that's Web 2.5, the always-on-you web.

The web community attracted unrelenting cynicism and bitterness after the dot-com bubble burst, and Web 2.0 is a way of telling the world that we're back, we're here to stay, we're here to change everything.

Saturday Update:
As I noted in a comment to John Battelle's defense of his partners' actions, the servicemark 'Web 2.0 <event>' (where event is a generic term like conference or workshop) was the wrong thing to trademark. Having done so, not foreseeing how widespread the use of 'Web 2.0' would become, it was the wrong thing to defend. Changing the name of your shindig to 'Web 2.0 Confab' or somesuch would have caused your partnership little trouble, and would have been defensible, both legally and morally.

Yesterday, assuming that O'Reilly couldn't be this clueless (or this), I came out in defense of them. Today, I'm joining the mass demonstration.

Seriously, would anyone be willing to help organize and/or speak at a Web 2.X Conference in the Bay Area for this fall?

Get O'Real... O'Reilly Not to Blame for CMP Misstep

Update: As it turns out, I'm dead wrong. O'Reilly IS to blame for this blunder. (Rick Segal offers a pithy analysis.) I couldn't imagine they could be this foolish. May I suggest you not attend the O'Reilly Web 2.0 conference this year. I won't.

An Irish non-profit has received a cease-and-desist from CMP Media, claiming to own a service mark on the term 'Web 2.0'.

Uh-oh, I hope there isn't a mass migration to 'Web 2.5' if CMP sticks to its (rather low-caliber) guns. That term has been coined, folks!

Tim O'Reilly, a fellow with probably the best public image in all of tech, is taking heat (lots) for a legal move by another company. The blogosphere has taken the original post on the story at face value, and not bothered to read the text of the C&D; letter, an image of which is included in the post. Yet another example of how bloggers are not journalists.

Update: Intriguingly, there has been a fight going on at the Wikipedia Web 2.0 page about whether to mention the fact that CMP has claimed a trademark on the term. So far, the editorial consensus is to exclude this detail.

Apologies for the off-topic post, readers. We will return to the decidedly less hype-driven Web 2.5 story shortly.

53651 Users Can't Be Wrong...

But they often are. As pointed out by Josh Kopelman, this is the readership of TechCrunch (current count at right), without counting readers who go direct to the website (a lot). This crowd has a very different relationship to the net than the mass market. Many of them believe that the internet will someday become a global brain, which all logic & data will move into. Near-term, they believe the internet is the PC.

That is not a vision that the mass market will ever embrace. Ordinary users have a healthy fear of centralized control, and a rational aversion to organizations that would rent property that individuals would benefit from owning, like their data. If you sign up the entire TechCrunch readership to your shiny new Web 2.0 app service, you might not sign up anyone else.

Croquet Proposes Web X.0: P2P, R/W, 3D

Nothing like a little alphabet soup to start the day... Croquet, a research platform that has escaped from the lab, sprung free by a startup called Qwaq, proposes to be "an operating system for the post-browser Internet". Nothing ambitious, mind you.

The focus of their post-browser net vision is not publishing, but collaboration, purportedly on a large scale. Intriguingly, its architecture is peer-to-peer, so end-users can build the Croquet web one node at a time. That is a Good Idea. Today's server-centric net tends to serve organizations well, and individuals rarely. MySpace and Blogspot are about the extent of the user-defined net, and they don't support much more than blather.

The Croquet user experience is a 3D universe of interlinked worlds; or perhaps interlinked apartments, as each world is more likely to be a set of rooms than landscapes. Clearly the stack of overlapping "windows" pioneered by PARC and first commercialized by Apple is a terrible way to organize or present information. The browser, with its hyperlinks and history deck, is far more sensible, and akin to the ubiquitous spiral-bound notebook. Croquet takes this idea into the third dimension.

But 3D conveys the feel of wandering around with a patch over one eye and a cheap scuba mask on your face; you can't experience realistic 3D without stereoscopic display and peripheral vision. I've not seen any research showing that 3D UI dramatically improves on 2D UI for ordinary tasks. 3D is hugely popular for gaming, so the technology works, but it hasn't migrated to more productive uses. What does 3D add to mostly-textual content? Think about a bookshelf: it's a 2D array of titles; grab one, open it, and you see a pair of 2D pages, in a stack.

Another potential stumbling block for Croquet is its apparent complexity. Perhaps this is simply due to the way the web site describes it, but it sounds like a bear to master as a programmer. You have to learn smalltalk, for starters, and then a mountain of APIs and paradigms. The wonderful thing about the web is how little you need to know to do useful things. Given time, the Croquet team may hide some of its complexity. But given its academic origins, that time could be a long one.

Robert Scoble got a demo recently. The Wikipedia article describes the grand vision and project history.

Personally, I'd like to see a 2D, P2P, Read/Write web for personal and small-team applications; based on SVG, and incorporating PC documents/apps. Hmm, that sounds familiar... Oh right, I'm writing it! It's called airWRX.

Web 2.5 vs. In-Office Spam

In-house spammers, i.e. most people you work with, have become a leading headache at the office. These well-intentioned miscreants habitually send messages to a group of people, often with documents attached, when only one or two are involved in the issue in question. They repeatedly send a document after each edit which they feel is significant. It's gotten so bad that knowledge-workers are now spending their days in Outlook, trapped! Outlook, or any email client for that matter, is hardly a project-oriented workspace tool, as you may have noticed.

This situation highlights three gaps in the desktop environment, when compared with the web: 1) The PC has no project workspace, whereas an editable web site is a project workspace. 2) Email is a protocol, not an application; email should be delivered to project workspaces, not in-boxes. 3) The desktop has no content-sharing mechanism other than email.

Creating a workgroup web site is an obvious approach to the problem, either on the intranet or at an online service. However, web workgroup tools have seen little adoption, largely because they are server-based. As such, they cannot be deployed by end-users; they require IT Mgmt approval and/or support. (IT Mgmt is especially skeptical of online services which pull company data offsite.) Also, centralized tools force users to think twice about everything they write into them, as all of it will be accessible to colleagues and managers, for all time.

Enter web 2.5: a peer-to-peer web (which runs for each user from a flash drive or other mobile device) with both shared and private workspaces. In these shared webs, an electronic discussion is simply an object on a page with other content, e.g. a spreadsheet. New messages in that discussion, or changes to the spreadsheet, are distributed only to those who are sharing that web. They either choose to be alerted to changes as they arrive, or peruse them as time permits, depending on their role in the effort. In-office email is virtually eliminated.

[Web 2.5] There Is No 'WebOS Market'

Richard MacManus draws up a WebOS market review. It's premature to call it a market, especially given the untimely demise a few years back of startups like WebOS.com and Desktop.com.

A WebOS is a solution looking for a problem. The idea of making the desktop user experience (with its clumsy silo-style applications, and haystack of files & folders) appear on the web is completely wrongheaded. The web offers a user experience that transcends the desktop; even non-technical users get this.

Rather than pushing the desktop up to the worldwide web, we should be creating web environments that can live on your person—the always-on-you web.

[Web 2.5] Yahoo Will Whack Your Email

A few years back, I set up a Yahoo email account. I hardly ever used it, accumulating at most a few hundred kilobytes of data, including incoming attachments. I logged in pretty infrequently. The last time I logged in I received this notice (click for full size):

The key elements:
- You have not logged in during the past four months
- All email has been deleted and cannot be recovered
- Subscribe ($19.99/year) to prevent another four-month whack

"This email will self-destruct in four months." Cool feature. Now, how do you feel about Yahoo as a potential provider of online desktop applications, for which they store the data? For that matter, how do you feel about Google or Microsoft, or anywhere?

If you use online apps that store your data, you don't own your data. That fact has not escaped the mass market, and no volume of hype will hypnotize it to the contrary. The always-on-you web, which puts your data in your pocket, is the only suitable method for web apps that rival the desktop in the mass market.

[Web 2.5] Pocket Wikis in Sync

The wiki is the app at the heart of the Always-On-You Web. Personal and shared webs obviously have to allow edit-in-place; what's the point of publishing read-only content to yourself? :-)

But the wiki as represented by Wikipedia isn't nearly flexible enough for the always-on-you web. For one, it shouldn't limit the content to rich text plus bitmaps (i.e. HTML). And it cannot corral the content in a single wiki instance. Always-on-you wikis that run directly from a flash drive, or live on your laptop, (see TiddlyWiki & PmWiki) won't be directly accessible to your collaborators; they need their own copy of the data in their own instance of the wiki. And that calls for a synchronization mechanism. A wiki-sync.

There are two ubiquitous sync systems, which everyone uses constantly... and I bet you can't name them. They are email and instant messaging. Huh? Yes, the number one way that documents are sync'ed by co-authors is via email attachments. This method imparts no implicit context for the object in question; discerning its meaning is left to the humans. But it works well enough, apparently. IM is simpler still, relaying a text block to some number of online participants, in near-real-time.

These simple, common mechanisms are the right stuff for sync'ing shared, locally-sited wikis. When a change recipient is online, they get the update instantly; otherwise the change is stored and forwarded when they're next online. The only thing to add is a tag that uniquely identifies the object that changed, so incoming updates can be processed behind the scenes.

My firm is designing an open sync service that will allow members to keep multiple instances of a data object in sync across the net. It's not just for wikis, any app could use it; it's not just for portable apps, hosted apps could use it. We'd love to get feedback from wiki warlocks and mashup masters about it, so drop me a line or leave a comment if interested.

Web 2.5 Joins the BlogBurst Network

I'm blushing while blowing my own horn, but this blog has been accepted into the BlogBurst network, a wire service which promotes choice blog content to major publishers. (Bloggers in the mainstream media bed? horrors! :)

Well, it figures. The always-on-you web is subtly emerging, and today we're the only blog on the beat. I'll enjoy it while it lasts.

[Web 2.5] Privacy Promotes Productivity

Why is it that the web wave has left the desktop dry? Technical factors have been a barrier, but they're a berm made of sand; they dissolve in time. Social factors are more subtle, and a lot sturdier. The common architecture of web software raises some real social concerns, which have hardly been examined, let alone remedied.

The founder of an enterprise IM startup recounted this anecdote: "While deploying our IM software at a hedge fund, I noticed the admins using AIM, and suggested to an admin that the new intra-office IM system for the traders would be helpful to the admins as well." Her response: "Will my boss be able to see what I've written?"

The answer was yes, of course. The firm bought the app to improve knowledge retention, among other reasons. The lesson here is that employees are averse to the vision of a manager peering over their shoulder when they're alone at the keyboard. If they know that it's merely possible, they will curtail their efforts, per the philosophy The Less Said the Better.

The PC, for all its deserved reputation as unmanageable, is a personal sandbox in which an employee doesn't feel constrained and watched. She is free to play with ideas and drafts, and chooses what to circulate to colleagues. That freedom is a boon to productivity.

That freedom doesn't exist in contemporary web software. Today, web applications are based on servers, so everything done with them is knowable by operators and managers. This has caused many web workgroup installations to meet resistance and even fail; employees are used to the virtual vanity erected by their PCs, and they prefer it to the open stage of a centralized environment.

Drawing the benefits of the web—easy navigation via hyperlinks, and a metaphor reminicent of the spiral-bound notebook with section tabs on the edge—out of the internet cloud requires a different architecture. Something more akin to the independent-peers arrangement realized by PCs and email.

That's the architecture of the Always-On-You Web: lightweight, personal web servers which run from mobile devices, and are accessed on any local screen device via a browser. Mobile web servers are peers, sync'ing any content designated as shared, and keeping private all else. The Always-On-You Web has no centralized servers.

---
PS: in an effort to energize the bland blogspot layout, I've added an evocative banner image. It's a little artsy and a little risque. I'd love to hear reader reactions...

[Web 2.5] Introducing 'indi', a Web 2.0 Site in Your Pocket

Last week at the ETech conference, the indi "personal web site" from InfoEther made a tentative debut for the digerati. Judging by the blog coverage it didn't receive, they didn't grok it. Maybe the only concepts the ETech audience can wrap their cortical folds around these days are those bits of fluff about to be sucked off the floor by Google or Yahoo. ;-)

The indi is a web application platform that runs directly from a flash drive on any PC. The application environment is written in a mix of Ruby and the Flash ActionScript language, with the UI rendered by the Flash player in the PC's browser. For perspective, the bandwidth of a USB 2.0 drive is comparable to a hard drive. Broadband, schmoadband. This environment isn't going to feel like any web site known to man. If the PC of the moment happens to be online, indi apps can hit the net to pick up mail or updates to a team calendar, or do multi-player gaming, or anything. If you can't get online, you've still got everything you need: data & apps, ready to rock.

The indi is a statement that personal web services like Writely and GMail don't have to run in the cloud. Rather, the data and apps of such services ought to live in your pocket, where they belong to you (not a third party) and are always immediately accessible.

Now, I know something about this space, since my company is working on an app with a similar architecture for a completely different market. You should consider me both biased, and well-informed.

The indi's designers chose Flash for the front end. In a word, "aghh". About the only compelling Flash app I've ever encountered is the Orbitz Pool Table game. And that crashes IE with disappointing frequency. When I first got Firefox, which doesn't bundle Flash, I was delighted by the Flash-free web experience. It's now my standard mode. Flash is to the web what game shows are to television.

Flash is a closed client and a proprietary protocol. It can't legitimately claim to be a presentation format, like SVG or PDF. (If it could, it would have euthanized PDF a decade ago, as Acrobat is one of those sad pieces of code that begs for a coup de grace, despite the worthy design goals that spawned it.) Thankfully, use of Flash seems to be declining steadily with the rise of the AJAX model.

However, if you plan to build a for-play web site, Flash is the only game in town. And games seem to be a key target for the indi. Bang...Aghh!

In applying the Ruby language for the data management side (which runs outside the browser), the indi gets full marks for geek chic. It also provides a variant of the OpenStep UI framework (originally developed for the NeXT) for ActionScript. This puts the UI logic inside the Flash player, instead of streaming to the browser, the way our SVG Terminal does. The indi approach is analogous to an AJAX UI framework running in a browser, talking to business logic on a server; except that the range of Flash is far greater than that of DHTML/CSS. From the perspective of most developers, this is a rather tall stack of unfamiliar, though critically-acclaimed, technology. Where's the Java or Javascript? Eschewing Java may be a business decision; licensing the JRE for mass-market/consumer distribution may not make sense in this case. And they've opted for an open UI library, rather than Macromedia's offerings.

Naturally, the indi isn't shipping at this point. A private beta is in progress, and in email, I've been told the debut date is July 4 of this year; how clever, since the indi is named for "digital independence". (Amusingly, the beta user guide is in PDF—come on, guys, eat your own dog food!) In good blogger form, I've had no contact yet with InfoEther. I've requested a beta invitation... if they oblige I'll be writing more.

The indi is a different take on how you can use the web... it's the Web 2.5 take, and it has a lot more to do with the future of the web than all of the ASP 1.1 outfits combined—Writely, 37Signals, et al. Not that we don't need decent online apps, it's that the useful scenarios for them pile up to a much smaller heap than those for the indi and its ilk.

[Web 2.5] A Killer App for the UMPC/Origami

The Origami tablet design from Microsoft seems to have been universally panned. Unlike most of the critics, I actually use an ultralight slate tablet constantly, the NEC LitePad. I'm composing this post with it. (Though I never use handwriting; I write with a shorthand method of my own design.)

Here's a radical idea for the UMPC: think of it not as a PC, but as a server. A device that could fire app UIs at any/many available screens, via wi-fi. Now you're not constrained by the tiny screen and pen input, but you fall back on them when no other PC is handy.

A scenario: You walk into the conference room with your UMPC, and all participating screens light up with your slides, plus UI to let your colleagues annotate them. The UMPC screen shows your slide notes. Later, your head back to your office, and your desktop screens and small office projector light up with whatever they showed before you left to give the presentation.

Windows doesn't offer much infrastructure to accomplish this example, but the web does, especially AJAX & SVG. Re-defining the UMPC as an always-on-you web 2.0 server unlocks a world of killer apps for it—apps which are better served from your pocket than the internet.

[Web 2.5] GDrive? GWrite? Gee Whiz (not).

ASP 1.1, here we come! Google seems ready to roll out the GOffice, with calendaring imminent, file service in the works, and ink drying on the Writely acquisition. Is Microsoft worried? I doubt it.

Google has it exactly backwards, especially regarding online storage. Rather than an online repository and desktop cache, what users need is a mobile repository (e.g. 32G flash drive with UWB wireless) for always-on-you apps & data, with an online subset of data for (semi-)public viewing and mash-ups.

Wireless flash drives are inherently bigger, faster, and more reliable than any WAN-based service. The net should be used to sync shared content on your drive with others, not deliver it just-in-time.

32G not enough? Take 2, take 5... they're cheap and small. Flash doesn't have this density today, but at the curerent rate of improvement, it will within three years. Got to have it now? Carry a pocket USB hard drive.

Heavy storage consumers will also need auto-archiving of older content; user-encrypted and housed at more than one service provider (who has no visibility into the data due to encryption). Google won't be among those providers, because it has to see your data to figure out what ads to show you.

The sad thing about this waste of Google's effort and brand is that it's been tried before. Theirs was the vision of Intranets.com, and numerous other players, who blew a ton of venture cap during the dot-com era. Intranets.com was the most successful of the lot, they sold to WebEx last year for $45M. Mind you, they raised $40M and spent six years to get there.

Was the lack of Ajax the reason for all those failures? Or was it user reluctance to hand over their data to a posse of three middlemen (net, ASP, billing) and rent it back from them? Google is going to find out.

[Web 2.5] The SVG Terminal for Firefox Gets Better

Ok, it's just a little bit better, but the new release of our SVG Terminal does text highlighting when you drag your mouse on a text field. And we've given the demo app that comes with it a shape palette, mimicking the UI of a drawing app.

To recap, the SVG Terminal is a module for Firefox 1.5, and a simple protocol, that enables apps to deliver evolving vector graphics views on network screens and fine-grained interactivity with users. It directs all user input from the browser to the app/service, which sends updates as SVG fragments to the browser. (You could think of it as X Windows for XML.)

It's designed for apps running on a mobile device which need to present a sophisticated UI on nearby screens via wi-fi, and apps which need to drive multiple network screens with graphical scenes in near-real-time.

And hey, if you like what we're doing, please blog us!

Web 2.5 Means 100% SVG? Online, No. Offline, Yes!

Given our release last week of the SVG Terminal, some folks may have taken the impression that we're proposing all-SVG and a host-terminal model for the next-generation web. That's not the case!

Web 2.5 is about applying web look-and-feel to everyday computing, and fully mobilizing your everyday tools by deploying them as web-like services on mobile devices: laptops, Wi-Fi handhelds, and flash drives. These web 2.5 services drive local screens, using presentation standards like SVG and HTML.

I will confess a bias against HTML... tables & divs & gifs just never impressed me as a composition toolkit. I grant you that for accomodating the limitations of diverse display environments, this approach has merit. But to implement serious authoring tools and effective visualizations, web software needs what the PC has had for years, a flexible 2D rendering API. That is the role of SVG.

Because of the close proximity of these mobile-borne services and local screens, it makes sense to pass user input directly to the service. Otherwise you pile a ton of custom javascript code for each app onto the screen system to provide near-real-time interactivity for XML content.

In the web 2.5 model, with PC-quality apps running out of your pocket, an SVG terminal is the most potent and simple mechanism for presentation and interaction.

[Web 2.5] The SVG Terminal for Firefox Debuts!

Our SVG Terminal (released today) is a javascript module for Firefox 1.5 and a simple protocol that enables apps to deliver rich views on network screens and fine-grained interactivity with users. It directs all user input from the browser to the app, which sends updates as SVG fragments to the browser.

It's designed for apps running on a mobile device which need to present a sophisticated UI on nearby screens via wi-fi, and apps which need to drive multiple network screens with graphical scenes in near-real-time.

The SVG Terminal fits under the AJAX (asynchronous javascript and XML) umbrella, but differs from most AJAX code in a few ways: The UI is described entirely in SVG, instead of HTML. Almost no input processing is done by the browser. The browser maintains a connection to the server, rather than performing discrete XML-HTTP transactions.

The SVG Terminal package includes a simple demonstration app, and source licensed under the GPL. The demo app has only been tested on Windows to date, but should compile on Linux & MacOS X with minor changes. The javascript code requires Firefox 1.5. Future releases will provide text wrapping and highlighting, and soon airWRX will show off the real power of the SVG Terminal.

[Web 2.5] The SVG Terminal - UI on the Server, the Server on You

One of the cliches most excersized by web proponents is "The browser is good enough!" In other words, users don't really need web views to be as flexible as those on a PC. If you visited the Superbowl play-by-play site last Sunday, and enjoyed its mixture of AJAX & Flash, you might tend to agree. How easily we forget that interactive media is not a productivity tool or modeling system; it doesn't have to gain much control of the screen to succeed.

SVG is one large step for the web world towards the fine-grained view control that PC developers wield on behalf of users rushing for less leisurely goal lines. However, SVG is not a reason to reinvent the fat-client model with Javascript widget frameworks, wherein the server is reduced to a storage device firing raw data to clients for presentation and manipulation. (Java attempted this a few years back.) For many applications, SVG is a means to intercept that trend and run the other way: push everything but rendering onto the server.

This is the concept of the SVG Terminal. The server maintains the view model as an SVG document object, and updates clients as it changes. The clients relay all user actions directly to the server for processing. This mechanism may not perform flawlessly on WAN connections, but on the LAN or to wireless peers, it's very smooth. For the web server coming to your pocket, it's ideal.

This architecture is very similar to the message-driven approach of windowing systems like MacOS and MS Windows. One tremendous difference is that multiple screens can share the same view, which may include variations for each screen and support efforts by each user to affect the view. At last, web experiences will go head-to-head with PC user experiences, and begin to beat them, especially for always-on-you wikis, living and working on mobile devices.

We're now prototyping an SVGTerm, based on the SVG Scene library we released last summer. It should be released within a week or two. It employs the Firefox browser, which began rendering SVG with the release of v1.5.

[Web 2.5] Embracing & Extending Bill

It is a long fall from the internet clouds, where web pages coalesce into sites, to the PC continents, where documents accrete on disks. True, a browser can present a traditional document retrieved from a web site by invoking a local PC app to take over the browser, though editing it is futile. Newly extant are browser-based office suites enabled by AJAX, in which the app itself is remote, and just vaguely familiar. But rare is the PC app that is a component of a web page (leaving aside the Flash plugin). And utterly extraordinary is a locally stored web composed of ordinary, editable office documents, interlinked to form a site.

This is a sad state of disunity, the moreso because a mechanism to remedy it has been widespread for more than a decade, and built into Microsoft Office and most other PC apps: Object Linking and Embedding, a.k.a. OLE. Using OLE, knowledge workers could employ well-known apps to assemble project webs, and cease scrambling around desktop/server folders and email attachments to find related files. They are obstructed by the lack of a browser that is an effective "OLE container", to manifest web features around otherwise isolated documents.

Far from giving more control of the web experience to Microsoft, this approach embraces and extends its apps, leveling the field for new challengers in the knowledge-tools game. In these unified webs, server-side editors (which interact continuously with the user just like desktop apps) co-exist with traditional editors. That combination enables all kinds of web-styled solutions, in which users leverage well-known tools, and needn't fuss with relearning a word processor.

Happily, OLE-defined content can be viewed without the original editors, and could be modified without them using server-side editors. But how, you may ask, would desktop apps that were coded to write files send content back to a net service? The browser-container must catch the read/write requests of embedded apps and transmit them via HTTP; XDrive and other online storage services use this mechanism.

This "net service" is likely a background process on the user's phone or pocket server, which also delivers the web pages on which the OLE apps are embedded. Note that when pages in a project web are published to the worldwide web they would be translated to XHTML, SVG, etc. as is common practice.

[Web 2.5] Talking to the Web Server that Just Walked In

A peripatetic web server can't just tack up a sign on the nearest wall reading, "Hey, I'm the cool new site in this room! My IP of the moment is 192.168.0.101." So how do you talk to the web server running on your wi-fi handheld using a friend's laptop at the coffee shop? It's a case of "Don't call us, we'll call you—often".

A wandering web server has to sing "here-i-am" periodically on the local network. Potential clients have to listen for that tune, which will come across on an agreed port. However, contemporary browsers aren't prepared to listen for anything except responses to requests they've posted to known servers.

Fortunately, the solution is trivial. All we need is a faceless desktop app, with an icon by the taskbar clock, that tunes in that port, taking down the info for any web server that chants. When you want to talk to one of them, you click the icon to view the list of singing servers, and hit the one you aim to chat up. That starts a browser for the server in question.

Our current airWRX prototype uses this technique inside its client component, though now I wish we'd separated it out as described above, so anyone could grab and reuse it in their own projects. (That wouldn't be much work, so if interested, drop an email to airWRX->networkimprov+net.) The server singer can be implemented in a one-line pearl script, or a brief C program that runs from the command prompt or in its own thread in a larger app.

You'd think that this scheme would already be specified somewhere, for instance Apple's Bonjour protocols for ad hoc IP networking. But as far as I can tell, it assumes that services are lethargic beasts, whereas clients flit about; the fleas must seek the dogs. In the case of a web server running on your laptop or wi-fi handheld, it's the ephemeral animal. If clients constantly call "are-you-there" looking for newly arrived or departed servers, a room full of clients would waste a lot of the available bandwidth. It's more logical to have the servers do the talking.

[Web 2.5] TiddlyWiki, an Offline Browser App

A reader recently pointed me to TiddlyWiki, a Javascript notetaking app that runs in a browser but has nothing to do with a server; it saves changes to its HTML content to a local file. Though prosaic in the PC experience, this is such a strange idea in the web world that many people require real time to grok it!

TiddlyWiki's presentation concept is also unusual; it acts like a collection of blog entries which are displayed in an arbitrary order according to how you hit item links. Items are inserted into the page as you click, which is certainly preferable to popping up windows or loading whole new pages for small snippets of content.

The javascript code is tiny, under 200K, so naturally it fits on a flash drive. However, it does require a newer browser, so storing a browser on the flash drive as well might be recommended. This is possible with FireFox, which has a portable configuration.

TiddlyWiki delivers only part of the web experience to personal notetaking: hyperlinking within a single page. That's a feature now conspicuous by its absence from most desktop software. However, the notion of a web (interlinked pages, each with definite content) is absent from this "web app". If a wiki is an edit-in-place web, then TiddlyWiki is not a wiki at all, it's a structured text collection with a fixed schema and full-text (non-indexed) search.

Also missing from the standard web experience is any kind of multi-user access, since it's bound to a single browser. You can upload a TiddlyWiki HTML file to a web server to simply publish it, which is how their web site is built. Shared entries which propagate to a server or peers automatically would make this a much more interesting environment. Also useful would be a way to incorporate non-HTML content, e.g. a table of numbers clipped from a spreadsheet, or some SVG for a pie-chart.

[Web 2.5] Hosting Holds Web Evolution Hostage

The worldwide web is essentially a collection of centralized servers, albeit distributed at a variety of hosting sites. A tiny number of web servers are sited outside data centers. A handful of non-web online apps employ decentralized servers, mostly as a way to avoid crushing demand on a single site for audio/video.

People want to use the web for more things, like everyday work. Its info-model and ease-of-use are compelling. But its centralized architecture is only suited to certain applications, like mass-market media, whizzy mail-order catalogs, and clubs which meet in e-text; a.k.a. "content, commerce, community".

By contrast, the dominant architecture for everyday work is decentralized: the PC. Given the headaches of a certain widespread PC OS, IT managers fantasize about centralized blade servers and display terminals. The proliferation of laptops and flash drives and smartphones clearly points the other way. In short: No, Mr. McNealy, the network is not the computer.

The { web = hosted } mindset is now an obstacle to the evolution of the web. It's a modest leap of imagination to see that the web becomes an everyday work environment once implemented on a decentralized architecture: peer-to-peer. This means web servers that live on user devices (especially mobile ones), hit local screens with their apps, and synchronize with others belonging to afilliated users whenever they can access the net.

Yet I've found this concept to be challenging for people. A pocket web server sounds like a contradiction in terms; I might as well have claimed to have a self-contained internet on my keychain. Folks have trouble separating the web info-model (multi-format, interlinked pages), from the architecture on which it is now deployed (centralized servers). That very separation has to happen for the web to make a difference in everyday work.

[Web 2.5] The PC Was Never All That Personal

By design, the PC is not a mobile computer. In order to accomodate the per-unit tax levied for Windows & Office, PC designers jam more and more electronics into the box, keeping price and power requirements high. The result is a desktop or luggable supercomputer, rather than a true personal computer, which by definition should be effortlessly mobile. The few vendors who have tried to build pocket-sized PCs end up with devices that are underpowered for Windows, and terribly overpriced (see OQO). PCs get denser, not smaller.

Low-power x86 silicon has been around for years, and for cheap. Leveraging it requires a lightweight software architecture, which Microsoft will not embrace outside the PocketPC. Mind you, the PDA, with its poor input mechanisms, is a PC accessory, not an alternative.

The architecture of the web—rendering & input on remote displays—will let power-constrained mobile computers become full-fledged personal computers. Offloading the screen and rendering logic to local PCs allows reallocation of power to application processing and battery life. By this scheme, you don't need to carry a screen device in most work environments, as PCs are ubiquitous. For on-the-road I/O you may carry one, in the best size for your immediate needs.

Handheld-to-remote-display is a perfect application for Bluetooth; Intel Research prototyped it over 3 years ago (see Web 2.5 Pocket Servers). Unfortunately, handheld makers don't grok the potential of web architecture, consumed as they are with building so-called smartphones to head off the threat posed by ordinary mobile phones.

Real pocket web servers will eventually appear—they've been technically feasible for several years—if not by Bluetooth, then by UWB. They will likely evolve from flash drives. Contemporary flash drives are already a plausible deployment vehicle for always-on-you web servers. You plug in the drive, your personal/peer-to-peer web services run directly from it, they hit the local screen and possibly others via Wi-Fi, and you unplug the drive to quit.

Web 2.0 technologies, particularly SVG & AJAX, fill two big gaps in the web model, and thus open the door to Web 2.5, wherein web services run from your pocket, wherever you are, whenever you need them.

Web 2.5 Pocket Servers

Web 2.5 services should run from almost any mobile device, but the ideal host is a wireless pocket server—something the size of a flash drive or credit card. Unfortunately, wi-fi doesn't allow for a battery-powered access point, which is what the pocket server should be in a wi-fi context. Bluetooth hasn't caught on as a replacement for USB, and a high-rate WPAN, based on some form of "ultra-wideband", has yet to escape the demo theater. That's why we haven't seen more of these guys.

There are two candidates, however, one a research project at Intel, the other a new offering from startup Realm Systems...

The Intel Personal Server is a Bluetooth gadget which has not yet escaped the laboratory. Its software is web-based, with some extensions, like UPnP and Windows file service. Its designer, Roy Want, is a disciple of the late Mark Weiser, visionary of ubiquitous computing. (I also count myself as adherent of guru Weiser.)

The (steel yourself for the heavy-metal website) BlackDog is a USB-connected pocket server. You plug it in and the host PC instantly fires up, um...well...um, X Windows. (I am frankly embarrased to have mentioned the term in public.) I guess these guys just haven't gotten out on the web much lately. The OS on board is Linux, so X was an easy path to desktop apps. The connectivity between the X apps running on the unit and the X terminal running on the PC can should be used to link a web server with a browser on the PC.

Since wireless pocket servers are still rare, we're building airWRX to run directly from an ordinary flash drive, or on a wi-fi handheld, or (if you're the type who totes a laptop everywhere in standby) in the background on a laptop.

Web 2.0 ASPs - The Emperor's New, New Clothes

The Silicon Valley hatchery is suddenly bursting with Web 2.0 ASPs (which I define as a service that hosts customer-generated private data, as well as logic applied thereto). They're hacking RoR & Javascript and scratching napkin—er, business—plans, while plotting the demolition of the desktop software cathedral. They wisely eschew the term 'ASP', embracing the more mysterious mixed-case palindrome, 'SaaS'. Is there anything really new under their chic 2.0 threads? Let's have a look...

New User Experience! Yes, AJAX lets you build a more responsive UI than DHTML. Flash and Java have also enabled flexible UIs for some years.

New Revenue Stream! Internet advertising is booming, no doubt. Google spends some $2 billion annually to place ads on other sites. But will you hand your customer's private, 'secure' content to Google for keyword scans? Will users click through often enough when they're trying to get work done?

New Bold Approach! Can the reinvention of Word, Excel, and Outlook really be regarded as innovation? Hasn't Linux made it clear that a cheaper, more manageable desktop replacement just isn't that intriguing?

New Market Leaders! Well, two, anyway: salesforce.com and WebEx. Together they account for 40% of the SaaS market. WebEx could also be regarded as a network service, whose software belongs in the cloud. Salesforce has profited from the spectacular flame-out at Siebel.

New Exit Strategy! Yahoo, Google, and Microsoft are expected to fill the role of the dot-conned Nasdaq, buying everyone in sight at high multiples of founder fervor.

So much for what's new. It appears to me that most of the Web 2.0 ASP proposition lies is in what's old—those virtues that Web 1.0 ASP hyped to no avail...

No software to install or upgrade. Great, but the era of manual PC software maintenance is passing. Local-code-on-demand isn't exclusive to browser-based apps.

Simple, effective web UI. There's no question that this is a huge benefit. Multi-format pages interlinked to form sites, viewable by multiple users, is a great way to organize and present content. In fact it's too valuable to remain an online-only mechanism much longer.

Accessible via any browser, anywhere. Anywhere the net connection is reliable, that is. What if you could put the web server in your pocket? Would you prefer its service to a network one? Is there any reason besides the previous two that this app should be online? If not, then Web 2.0 ASPs will be just as popular as their Web 1.0 forebears.

We might as well call this ASP 1.1

NYTimes: Can This Man Reprogram Microsoft?

Steve Lohr piles onto The Network Is The Computer bandwagon, describing Ray Ozzie's new role. Here's the note I sent him in reply:

The sudden strength of Google and successful IPO of salesforce.com have yanked attention away from lessons learned by dozens of ASPs after the bubble burst: that there are hard reasons why users want to control their own data and apps.

First, individuals reflexively dislike the idea of others owning their data, even if access is free. Next, electricity is reliable and ubiquitous, otherwise we couldn't depend on PCs. Internet access is some decades from being as prevalent as AC, especially because much of it will be wireless, unlike electricity. The internet isn't really "always-on".

Complex enterprise apps like CRM & ERP benefit from having an "on-demand" service offering so customers can get started without investing huge sums before seeing returns. Eventually, many of those customers will choose to move such systems in-house, if they find them to offer competitive advantage.

Personal and workgroup apps aren't complex or expensive to set up. Laptops or flash drives can be "always-on-you". The hidden reason why people wish for web-based personal apps is the web's info-model: multi-format pages interlinked to form sites. It's a much better way to organize and present data than folders-with-files-edited-by-apps.

You don't have to hit an internet server with a browser to use the web info-model. You can carry a web server with you. The real disruption coming in this decade is "distributed web 2.0", in which user mobile devices become web servers.

Web 2.5 is Distributed Web 2.0

As handhelds get more powerful, and laptops lighter, and flash drives denser, something strange and wonderful will happen... the web will colonize them. Not as clients, but as servers! If centralized web services are cool, then distributed, mobile ones are a snowstorm; a shower of unique, lightweight systems, each tailored to its bearer.

Pocket web servers bring the advantages of the web information model into everyday computing: multi-format pages, interlinked to form webs; presented on multiple screens, in varying modes, to one or many users. But unlike cloud servers, you are never disconnected from pocket webs; noone can cut you off from your tools & data.

Software on the distributed web will be a service, in many cases. Pocket web servers will typically belong to two or more services (e.g. one public, and one private to your business) which provide software, backup, synchronization of shared data, and support. These services will also have centralized features, like semaphores for shared resources, and gateways to enterprise systems.

Pocket web apps can do tricks that cloud web apps can't, due to internet latency. They can handle all user input with one package of code, and do it fast; exactly what PCs do today to create responsive UIs. Pocket web apps can do tricks that PCs can't, due to PC architecture. They can deliver customized views of a page to a set of participating clients; exactly what web application servers do today.

The distributed web is the best of both worlds, and it's the natural site for some of the apps now being written for the cloud using AJAX. Office apps are much more alive in your pocket.

Web 2.5 is the Personal Web

The web model has not yet penetrated an area that is arguably the most important in computing: personal and team authoring, the focus of the personal computer. We're all still banging in MS Word and hanging docs on file servers, or shoving them around in email. The web information model, with its interlinked, multi-format pages, and multi-user views, is missing in action. Why?

Because the focus to date, from ASP to AJAX, has been on pushing personal computing up to the web, rather than bringing the web down to the personal computers. And what's wrong with pushing up?

First, you don't get a fully responsive user experience from web services in the cloud, AJAX front-ends notwithstanding. Think about dragging a slider to set an effect level on a photo or video clip: with a web service, the effect is generated on the server, which sends a generated jpeg to the browser for every mouse move you make. Never mind how fast your broadband is, Internet latency chokes this UI. On a PC, mousing is caught immediately and routed to the effect code, which makes pixel-by-pixel revs to your display. Siting all the UI code near the data source is also a lot more sane than breaking it into client & server modules. (Wasn't the web supposed to spare us from client/server headache?)

Next, the religion of The Network Is The Computer has indoctrinated the congregation to ignore an obvious issue with connectivity: We depend on PCs only because electricity is ubiquitous and reliable. If the power is out, you've usually got acts of god in progress, and little divine inspiration for work. Only when net links reach powerline quality can we trust all computing to the heavenly cloud without real fear of downtime. I hear the choir cry, "How far off can that be? Wireless internet everywhere (via Wi-Fi & WiMax) is nigh!"

Has noone noticed that electricity is wired?! AC supply is so dependable precisely because it is not wireless! Really dependable wireless internet might take a while, like a decade or three. Wireless is hard.

There's a simple, cheap, effective way to pull your head out of the cloud and bring the web revolution home, without sacrificing always-on accessibility: Put it in your pocket! On a web 2.5 server swinging from your keychain. Hmm, that sounds like a USB flash drive... Bingo. Always-on is sexy. Always-on-you actually works.

Welcome home, web 2.0! I don't know how we got along without you.

We Have Axes to Grind

This byte-stream covers the nascent world of mobile web 2.0 servers, as seen from one land-mass thereon: the pocket application server known as airWRX. We'll note developments all over the pocket-web planet, but make no promises to be objective. (You have been warned!)

This is the first post; April 2005 is the April Fool's Day archive.

Human-Embedded Web Server Announced

Originally Published April Fool's Day 2006

Boston - April 1, 2006 - The scientists and engineers at stealth bio-ubicomp startup Network Improv today announced the imminent debut of the Human-Embedded Web Server, along with the Human-Embedded Wi-Fi Antenna. These products are the first in a new class of Human-Embedded Web Computing, a market projected to be worth $347.71 billion by later this century.

This breakthrough web software is uploaded into a nerve cluster at the top of the spinal cord, a cluster that emerged in vertebrates tens of millions of years ago, and had long since fallen into disuse. Known as the Antediluvian Sauroskein, scientists have wondered for years how to repurpose the cluster for health or augmentation applications. The Human-Embedded Web Server (HEWS) is the first successful application of the cluster in at least ten million years, and the first ever application for digital computing.

The HEWS allows its bearer to run both sophisticated web-based apps, including the new Writely Brain Suite, developed in tandem with Network Improv by Upstartle (a startup acquired by Google last month for far more than was rumored). These apps are truly always-on. The HEWS also allows the user to interact in fundamentally new ways with their own mind, accessing details of long-forgotten life stories, and latent knowledge. All presentation of HEWS-generated content is by SVG, a next-generation web language that allows complex visualizations of subtle processes.

Network access to the HEWS is facilitated by the Human-Embedded Wi-Fi Antenna (HEWFA), a microscopically thin titanium pathway in the shape of a cursive 'f'. The HEWFA is implanted by a tattoo technique, which can be performed by any licensed tattoo technician. The HEWFA interface lets any personal computer with a browser and Wi-Fi card access the HEWS over a Wi-Fi network.

The HEWS and HEWFA draw power from the natural electrical field of the human body, and never need to be charged, provided the user is eating a balanced diet. The HEWS will automatically detect a low-electric-field condition in the user's body, and induce a mild coma if necessary to avoid loss of power to the HEWS, which could erase the HEWS code and data from the nerve cluster.

National auditions for the beta test team that will prove the HEWS and HEWFA in real-world scenarios will open at the end of this month. Please check the Always-On-You Web blog in the coming days for audition information and locations.

A few skeptics have questioned the wisdom of providing direct access to the human nervous system via a web browser. Network Improv has addressed this problem with a unique security solution that precludes unauthorized access to the HEWS through the HEWFA by interlopers on the wireless network. In keeping with common practice, the company has declined to provide any details on the functioning of the security mechanism, but strongly assures the public that it is fully foolproof.