Here’s a picture of the output from a curious little application:
It’s a picture of Firefox poised to subscribe, in Bloglines, to an RSS feed that monitors keystroke and mouse activity on my notebook PC. As indicated by the stats — 281 keystrokes and no clicks — I was busily writing during the 60-second interval captured in that snapshot. I was writing this entry, in fact.
How will Bloglines be able to read this feed, which originates on my PC? One solution would be to push the feed from my PC to some location in the cloud that Bloglines can access.
That’s not what’s happening here. Bloglines is talking to a service in the cloud. But that service is a relay based on the Internet service bus technology discussed in my interview with John Shewchuk. On the other end of the relay is my notebook PC, running a service that listens for incoming requests and, on demand, reports keyboard and mouse activity.
That reporting service is a desktop application that combines BizTalk Services with a systemwide mouse/keyboard monitor. When I launch it, I authenticate — using CardSpace, not username/password credentials — to the cloud-based relay. Then the application listens for feed requests coming in from the relay. Meanwhile, every sixty seconds, it summarizes my mouse and keyboard activity. When a request does come in from the relay, it materializes the feed with a single item containing that summary.
Here are some of the implications of this scenario:
- Although it’s behind a firewall, the application can still respond to inbound requests.
- If my PC is online and running the application, the feed will report my activity for the last minute. Otherwise, it’ll report nothing.
- Even when the application is unavailable, if it was intermittently accessible to Bloglines or another feedreader, snapshots will appear there as frequently as the feedreader was able to contact the PC.
- If I close my PC to travel downtown or cross-country, the feed will stop responding. But when I flip open the PC at a new destination, the feed will resume at its canonical URL.
I don’t think I’ll leave this feed running. The BizTalk Services substrate on which it depends is still a preview; my mouse/keyboard monitor is a tad flaky; the scenario is obviously contrived.
But it’s a powerful reminder of the peer-to-peer experimentation I was doing almost a decade ago. I asked then:
Peer-to-peer Web computing is the future. Why not start exploring the possibilities now?
A couple of years later, that idea became red hot. Then it cooled off again. And while there have been some notable P2P apps — Groove, BitTorrent, Skype — the cloud’s where most of the action is today.
But the pendulum always swings. And when it swings back toward peer-to-peer computing again, those peers will sometimes be service endpoints. The services they provide will be different from the ones running in the cloud, but complementary to them.
For example, my contrived demo suggests a local service that helps you gauge my interruptibility. Keyboard and mouse activity is a rough but not unreasonable proxy for that. If you see a lot of clicks and not much typing, you might conclude that I’m just reading feeds or email, and decide it’s OK to call me or IM me. Conversely if you see that I’m typing furiously, you might decide not to.
What about my privacy? Well, this isn’t an either/or scenario. The desktop and the cloud are in cahoots, connected by a service fabric — in this case, Biztalk Services — that I’ll use to declare who gets access to my activity feed.
That feed can say a lot more about me than my rate of typing and clicking. It could show you that I’m editing a podcast, or doing research, or talking on a VoIP channel. If it were really clever, it would hide the details of these activities but help me categorize and prioritize them, and publish just those categories and priorities.
It’s appropriate for some of this interaction data to live in the cloud. But as desktop, laptop, and handheld devices become capable service endpoints, it will also be appropriate for some of that data, along with the services associated with the data, to live at the edge.
Jon,
Speak to me about the use of this mechanism for delivering real and valuable services, not just fluff. For instance, can my library of owned digital media live on the ‘edge’ for better and faster service? Can internetarchive.org provide you with what they characterize as ‘the intelligence of the world’ from a service on the ‘edge’?
Jim
Well, although my example is admittedly contrived, the idea of better ways to advertise our interruptibility to friends, family, and coworkers isn’t what I’d call fluffy.
The answer to both of your questions is no, of course. But here’s my thinking. Until we get to near-infinite bandwidth, we’ll be operating along a continuum of what you might call intimacy of interaction.
This isn’t an either/or deal. What John Shewchuk says in that interview is spot on. We ought to be able to locate services anywhere along that continuum as appropriate, and slide them back and forth on that continuum as needed.
The more resources we can command, the better, so long as we can figure out how to coordinate them sanely and usefully.
Instant messaging clients are already service endpoints. My IM client reports whether I’m active or idle, and if idle, how long I’ve been idle. I ran an experiment a few years ago where I automatically updated my IM status message with the title of the application that I was currently working on. I stopped it because I didn’t like having to be constantly considering what private information was being unwittingly revealed about me. It was an interesting experiment, but we need more refinement before people will actually use it.
And speaking of interruptibility, researchers have been trying to investigate this issue as well. For example, Avrahami et al have built models of whether people will respond to an IM in a certain amount of time:
http://www.cs.cmu.edu/~nx6/pubs/Avrahami_CHI_06.pdf
“It was an interesting experiment, but we need more refinement before people will actually use it.”
Agreed. I do think it’d be helpful to observe activity systemwide, but then aggregate and summarize. Because you’re right, there’s no way people can make microdecisions about which bits of information may be useful signals, and which may be compromising leaks.
If I have to declare “I am furiously active” vs “I am grazing for information” then, well, I just won’t. But my PC knows, or could infer, these kinds of moods and states.
Of course if I’m willing to go all the way with ambient awareness:
http://blog.jonudell.net/2007/01/15/ambient-video-awareness-and-visible-conversations/
then it’s a whole new ballgame. I’d love to hear, from folks who have done things that way over a long period of time, what worked and didn’t.