About ten years ago, I came up with that silly (?) idea that people could be identified with URLs. That those URLs could have particular functionality around them by which anybody — with the right permissions — could interact with them. And that, when people walked around with their mobile devices, those devices could broadcast those URLs in the neighborhood so that when you and I meet, our devices could “friend” each other. All without needing a centralized social network.
Shortly after this idea was hatched, it also became clear that it could include things: like, in a use case from that time, that a doctor could walk into a treatment room with their mobile device, and the mobile device would pick up not only the URLs of the people in that room, (and thus, pointers to their medical records,) but also of the medical machinery: the URL of the EKG machine, for example. Which then, when selected, would allow the doctor to operate the machine, or at least read out results, from their device.
We did make LID (“Light-Weight Digital Identity”) work on the web. We never made it work with local radio broadcasts, and that was simply because the technology wasn’t there. (This was a few years before the iPhone.) iPAQs, our device of choice at the time, did speak Bluetooth, but WiFi coverage was spotty, and the APIs and development environments for Bluetooth were simply not able to be coerced into that kind of use case.
So it stayed an idea. But it was clear that idea could have legs. There was a use case that involved waiting at a bus stop, and wondering where the bus was: if the bus stop broadcast a URL, it would be really simple (Coincidentally, the Google guys describe very similar use cases now.) I even pitched it to LinkedIn at the time, on the grounds that it would allow them to assemble a social graph much faster when people with such local-URL-broadcast-enabled devices meet at Meetups, for example, and automatically collected a record of everybody who was there (and, of course, chose to broadcast their URLs).
Well, barely 10 years later, Google comes up with what they call the “Physical Web” proposal. Broadcast URLs via Bluetooth, and go from there. If that doesn’t sound familiar … and so I’m totally in favor of what they are proposing.
Hey Google, here are the next things you want to do:
- Make it bidirectional: My mobile device pics up the URL of my garage door, but also let the garage door pick up my personal URL that is being broadcast by my device. While there are many use cases for the one-directional case, there are also many for the bidirectional case. (You could implement, for Google+, what I mentioned to LinkedIn above! And do wonders for “check-in”s if you ever get into competing with FourSquare.)
- Put identity around it. Let me publish a public key at my URL, and you do, too, and suddenly we can communicate securely and stay in touch with each other, even as our URLs change. (That, of course, would be LID in pure form!) You can bootstrap an entire identity ecosystem for the IoT from this simple scenario.
If I had a penny for every idea that was picked up or re-invented by somebody 10 years later… but it’s good to see what somebody with clout picks up the idea. It’s about time :-)
2 responses to “The Google “Physical Web” Proposal and LID”
The Google “Physical Web” Proposal and LID http://t.co/pDfPQjRP84
The Google “Physical Web” Proposal and LID – http://t.co/31F4q5vVf8