Case for Smartphone Web Activity Feeds
Sensor networks have historically been the domain of the military and large-scale commercial applications - powerful, but expensive to setup and operate. At the same time, Morgan Stanley is reporting that by 2012 the smartphone market will outship the global PC market (notebook, netbook, desktop, etc), which will easily create the largest, always-on, broadband-enabled sensor network to date. Only one problem, most mobile OS vendors (Apple, RIM, Google, etc) are app store obsessed at the moment, each fighting for the developer mindshare to stockpile their native app arsenals.
But, for a second, imagine if instead of rushing to build mobile apps which pull data off the web to local devices, what if we also had the infrastructure that could efficiently push the data back to the web? Billions of smartphone devices pushing real-time updates to our web applications - now that would be exciting.
Motivation & Use Cases
The question is not whether pull or push is more efficient (you need both), but enabling push from the smartphone as a platform capability could enable an entirely new class of applications: instead of focusing on an experience of a singular mobile user, you could aggregate data from many agents and build "network aware" applications! For the sake of an example, imagine we had the following:
http://www.apple.com/mobile/feed/{subscriber_id}.xml
http://www.blackberry.com/mobile/feed/{subscriber_id}.rss
http://www.android.com/mobile/feed/{subscriber_id}.js
Yes, that's an RSS feed - it is as simple as that. Each vendor already offers their own platform for "push notifications" to deliver data to the phone, so why not offer the reverse? What if each phone also had a representative notification feed that any web app could access?
Calendar notifications, battery notifications, geo notifications, and so on, it is all fair game! Add a subscription and an access control management layer on top, and all of the sudden, any web-developer is now but a URL away from enriching the experience of any mobile user: process a notification from the phone, push an update back. Not to mention, the capability to aggregate data from thousands of mobile devices for trends analysis, data-mining applications and so forth - a global mobile sensor network at your disposal!
Mobile Activity Feeds via PubSubHubbub
Maintaining direct tethered links to each individual mobile device is obviously an expensive and a technically challenging proposition, especially if we are after real-time updates. But the good news is, we have already solved this problem in a different context. WebHooks allow us to establish callback (push) semantics between web-services, and PubSubHubbub solves the problem of efficiently delivering real-time notifications from a single publisher (mobile device, in this case) to many subscribers: the phone pushes a single update to the platform provider and the PSHB hub does all the hard work of distributing the individual updates to each subscriber. Distributed architecture, simple protocols, efficient delivery, and it scales well.
Smarter Web via Mobile Sensor Networks
Native apps are great, but why keep the data locked to within a single device? If we could efficiently aggregate activity feeds from thousands of mobile subscribers with rich geo and contextual meta-data (user, or device generated), then imagine all the numerous mash-ups and data-mining applications that could be built on top!
In fact, if the rumours of Facebook looking at building their own mobile device/OS are true (really, not as crazy as it sounds), then I would argue, it is in part because they understand the (commercial and technical) potential of these activity feeds better than anyone else - what seems completely foreign to Apple, RIM and others is completely obvious to the web-natives such as Facebook and Twitter. Question is, who is going to get there first?
Ilya Grigorik is a web ecosystem engineer, author of High Performance Browser Networking (O'Reilly), and Principal Engineer at Shopify — follow on Twitter.