Someone recently ported Node.js to a jail-broken iPhone, turning the iPhone into a fully functioning web server/app server/web service.

Smartphones are capable of hosting web services, where other applications can request and receive information from them.

The question is, why? For what?

There’s a disconcerting premise in a Denzel Washington movie that comes to mind, reflecting how information can be passed from one person to another like a virus, or in this case, a spirit (watch from 00:44):

That’s where the next generation of web apps explodes just after your brain explodes. Imagine 100 people at a party, each with a smartphone hosting some web service that responds to requests for information.

What info matters? What info matters to people at the party vs their networks?

Peer-to-peer software shows an early example of the power of highly distributed, single-purpose applications. Napster, Bittorrent, etc.

SETI set my brain on fire back in the 90’s; I remember talking with Dave about the possibilities of chunking out computing tasks to a vast network of desktops to leverage the collective computing power. SETI does just that to process info about the universe using a network of the world’s idle computers through a screensaver.

But these are single-purpose applications. Highly distributed, single-purpose APIs will open up entirely new classes of applications.

What’s an example? In the Node.js post I linked to above, he talks about leveraging what’s native on the iPhone–camera, accelerometer, geo, etc. Let’s take the camera.

Imagine a large crowd, say at a demonstration, and everyone there has the camera API exposed and running on their phones. Now write an application that creates a collective eye every 30 feet, then broadcasts this collective eye back to an app on everyone’s phones. And let’s say this app creates 10 collective eyes across 100 yards of space, and broadcasts all of those back to the app, or out to the web.

You’ve created a mesh eye, driven by time, space, and people. You’ve brought back the collective eyes back to those who generate it, such that the people who make up Eye 1 can see what Eye 2 is generating down the street, or around the corner.

(We can get into whether a mesh eye is practical (bandwidth, focal points), but there are some very useful, cool things you can do by aggregating multiple real-time video streams with close proximity to one another).

So we’re able to move from running apps on your phone, to running APIs that allow developers to build apps around them that run on the web, or phone, or wherever.

An clear example of this would be if Fitbit, an app that tracks your activity based on motion, were to ship an API instead of an app. Currently, you install the FitBit app on your smartphone, and it transmits your data to their servers, and you access the results through the app or through fitbit.com.

But if installed their APIs instead, other developers could build a range of applications around those APIs, so FitBit would serve as the layer that provides specific access to your motion and other info, but other applications build specific apps that leverage that.

Maybe I want to build an application that shows activity levels during the day in specific cities, and displays the results on a real-time chart. That’s currently possible by FitBit through their app and data they collect from you, but that’s a closed system (they do have a server API in beta).

So what I imagine is

1) Google shipping Node.js as part of Android, Apple getting over itself and doing the same. MSFT, etc.
2) Users asked if they want to participate in the API program (in some friendly way)
3) Anonymity of data pulled from the phone; note that the APIs running on the phone can have nothing to do with what’s running on the phone at all, and simply run as a service.
4) phones participate as an available API source based on bandwidth & battery reserve
5) a directory of available APIs running in the cloud somewhere

Devil’s advocates step forward:

–cell phones don’t have fixed IPs. So what? Create a proxy system, where the IPs are fixed and hosted at the proxy, and the smartphone logs into the proxy when the phone’s available.

–cell phones aren’t always on, so they aren’t reliable. Ok, for what? Design apps that don’t depend on full-time connectivity.

–why wouldn’t we just build an app for that? Well, you’re not getting it. Creating generalized APIs that any app on the web can access is significantly different from apps that run on your phone just for yourself.

All of those are valid criticisms, but bandwidth, processing power, storage will continue to improve and increase. Privacy matters, certainly, and should be part of the framework.

Every node becomes its own hub. The possibilities are as limited as there are smartphones and imaginative, useful applications of something like Node.js running (efficiently) on your phone.

Cool stuff.