Offline Extension Development for Flock

I had an interesting discussion with Freeman Murray at SHDH last night about offline apps for use in remote areas where network latency can sometimes stretch from days into weeks for access to a “network”.

In such circumstances, you’ll have folks driving around on mopeds or busses with wifi antennae, USB drives or CD-ROMs delivering email and providing a means to getting “online”, admittedly asynchronously. Thought 28.8 was slow? Try email by bike messenger. It’s only one step above message delivery a la Paul Revere.

But in some cases, this is the best they’ve got and you can’t expect Google to trot around the world setting up mesh wifi networks for these folks (not in the near future anyway). And while some folks are working on this project and it is getting better, nevertheless, we must constantly be aware of and design for a rich offline experience.

This is especially close to me, considering I’m writing this on BART without connectivity as I head to the airport. Yes, even in industrialized areas connectivity is still not guaranteed (let alone free).

So an idea I’ve been playing with for some time is how Flock can support offline browsing and interaction, beyond pulling simple content from your cache or downloaded feeds. In the old model of the static web, the permalink model made sense and was perfectly useful — indeed, it’s still nice to be able to pull up that bar’s website when you’re wandering around Paris at 9pm, an hour late for the meetup that you helped coordinate and you’ve got no idea where it is except for the micromap saved in your browser’s cache.

But the problem is that we’ve divorced the data from the interaction layer. It’s like having your Halo saved games without having the game engine to play them. Boy, that’s a whole truckload of fun.

So anyway, Freeman and I were discussing how Flock could help with this problem. One idea that has some legs, I think, combines data delivery in microformatted XHTML pages (you’re caching it already, might as well make the data semantic and thus useful) and then allow basic interactivity with that data through extensions that are designed for both online and offline use. Thus, in the event that you’re offline, well, instead of pulling unsuccessfully from the server, it would pull from your local cache and allow you to do certain basic things, queueing your actions to be performed when you have connectivity again.

Indeed you could even use a P2P architecture for this, sharing encrypted offline action-scripts across a mesh network. When any one of those nodes reconnects, it could upload those instructions to the final destination where they’d be executed in batch. This would have the added benefit of spreading the need for connectivity across many nodes, instead of just one (like a USB drive which could get lost, stolen, confiscated or otherwise compromised). Should the actions have already been performed when the “message in a bottle” arrives, the commands would be simply ignored. There are technical details in here that are beyond my comprehension, but be that as it may, the idea is promising.

So back to offline extensions development… Freeman proposed an architecture in which Flock would ask the web app for a locally-run “servlet” that would provide similar offline interactivity when not connected. Autodiscovery would happen in the way that sites provide favicons or perhaps through a rel=”offline” link. The question though, is whether the user would need to take explicit action to install the servlet extension outright, or if, by visiting a web app (like Gmail or Basecamp), you’re implicitly expressing your interest in using the functionality of the app, whether on or offline.

I think the latter reflects a reality that I want. Installing apps on the desktop doesn’t make sense anymore, what with all my data being hosted in the cloud. So being to access and manipulate my data when I’m offline is going to become a requirement that the browser can tackle. I mean, this is the problem with solar power. You need to use your car whether it’s sunny or not, and so we’ve got rechargeable batteries, right?

Well, I think you get the point. Here’s the high-level description of the proposed solution (which I may or may not have communicated effectively):

11 thoughts on “Offline Extension Development for Flock”

It sounds like a great idea. I would really like to see it happen as an extension for flock, or to have it included with installation. For many people this could be a HUGE tool, and would take away some stress/hassle.

I’m interested in this idea. I’m assuming we’re talking about much more than off-line web pages that can be browsed? We’re talking about taking a web application off-line with you, right? So you can read or write emails using the “gmail” servlet that was installed locally on your machine when you last connected to the gmail site?

I’ve worked with Lotus Notes for years now, which allows for this kind of online/offline combination for applications. The biggest problem we have when user’s are disconnected is, what happens in the event of data collision (what Notes calls “Replication/Save Conflicts”)? This would occur when two people modify the same piece of data over the same time period. Don’t know how this might apply to your vision (I don’t do much web development and can only *barely* grasp what you were explaining above). Maybe this is a problems that is separate from the concept you are describing, and therefore something that application designers have to workout for themselves?

Keil, you’re right, data collisions would be difficult to mitigate, but when you’re dealing with one person’s personal data, there are a number of aspects that you can look at to determine the outcome. And as I said, much of the technical design parts are beyond me as well, all I know is that I can use my desktop apps with local data when I’m offline — I should be able to do the same thing with my web apps. That an app is “web-based” should not imply that you can only use it when you’re offline.

This is a serious problem but one that we must address if we’re going to democratize access to technology to remote places currently underserved by internet providers. I mean, we need this in modern cities just as well; I’m proposing that we begin thinking about this now and start coming up with solutions that we can get into the browser today.

Obviously I see Flock as a vehicle for having this discussion and I’m eager to see if other people are already or are interested in tackling it!

@Intersezioni: I don’t see why not. In fact, the architecture/design is totally up in the air. I think if you could deliver a good chunk of workable data in that single page, then absolutely. I mean, wouldn’t it also be cool if you could have a smart browser with basic tools embedded that could download a simple microformatted page and give you enough built in UI so that you could work with that data and then sync later?

For example, I download a microformatted page from upcoming.org that contains 1) all my events 2) all my friend’s events and 3) a list of available commands to create new microformatted content that just gets appended to the original page. I can manipulate that content with my Event Dohickey extension and then when I go back online, that page will be synced up with Upcoming. Seems pretty basic and simple to me. Ignoring the issues around merging (the real hairy issues) this could be the one page app you speak of!

I passed this along to Amir – head of unitedvillages.com (connecting the next 2 billion people). he said:

Thanks Freeman, this is along the lines we have been thinking for server that emulates real-time interactions with the Web using caches generated by offline clients/shells. We’d be interested in working with others who are working on it.