Haiku Reflections: Web Clients and Web Resources
This is part of a series of posts I’m writing to put down my thoughts on the recently retired Mozilla Connected Devices Haiku project. For an overview, see my earlier post.
My understanding of the overarching goal for the Connected Devices group within Mozilla is to have a tangible impact on the evolution of the Internet of Things to maintain the primacy of the user; their right to own their own data and experience, to chose between products and organizations. We want Mozilla to be a guiding light, an example others can follow when developing technology in this new space that respects user privacy, implements good security and promotes open, common standards. In that context, the plan is to develop an IoT platform alongside a few carefully selected consumer products that will exercise and validate that platform and start building the exposure and experience for Mozilla in this space. Over the last few months, the vision for this platform has aligned with the emerging Web of Things which builds on patterns for attaching “Things” to the web.
From one perspective, the web is a just a network of interconnected content nodes. It follows that the scope for standardizing the evolution of the Internet of Things is to define a sensible architecture and build frameworks for incorporating these new devices and their capabilities to maintain interoperability, promote discoverability etc. This maps well onto connected sensors, smart appliances and other physical objects whose attributes we want to query and set over the network. Give these things URLs and a RESTful interface and you get all the rich semantics of the web, addressability, tools, developer talent pool - the list goes on and on and its all for “free”. In one stroke you remove the need for a lot of wheel re-inventions and proprietary-ness and nudge this whole movement in the direction of the interoperable, standardized web. Its a no-brainer.
In this context however, the communication device envisaged by Project Haiku is orthogonal. While you can model it to give URLs to the people/devices and the private communication channel they share, the surface area of the resulting “API” is tiny and has limited value. It is conceptually powerful as it brings along all the normal web best practices for RESTful API design, access control, caching and offline strategies and so-on. Still, the Haiku device would be more web client than web resource and doesn’t fit neatly into this story.
This and the relatively skinny overlap in shared functionality with the proposed Mozilla IoT platform was one of the rocks on which Project Haiku floundered. And I agree that it would make little sense to have teams pulling in different directions and plotting courses that by design would not benefit each other much. But I’m also sad about a missed opportunity here. Its like we enlarged the stage but stopped short of taking the performance outside the theater.
I didn’t set out with a personal ambition to create products from headless, embedded web clients. We asked questions and followed the answers and wound up in a place that seemed to make sense. With the emergence of cheap networking hardware, we can imagine using the web from devices other than the highly horizontal, multi-functional browsers on our desktop and mobile computers. When we could afford only a single computing device, it made sense to make highly flexible software capable of bringing us any experience the web could manage. Our web browser was a viewer for web content - any and all web content. It was left to the users to figure out how to partition out the different ways in which they used the web - the different hats they wore. Now, we can dedicate a device to a single task - and in doing so remove layer upon layer of complexity in the user experience. Instead of toolbars and menus and scrolling and clicks, typing or even speaking to request some part of the web, we can have a single button. Or maybe not even that - its just there as long as the power and network permit. We can give some piece of the web a tangible, physical space in our lives. It could be a screen on the office wall that displays my bug list. I don’t need to context-switch as I switch tabs, instead context changes naturally as I move from one room to another, and the information is in its proper place.
The product Project Haiku proposed follows the same philosophy. Yes, you could use a phone, or a tablet or one of the many new and lovely VoIP devices to facilitate communication between two people. But they are behind an icon, tucked away under some menu - the device sits between you and them and allows you to speak through it. Contrast that to a device whose sole function is to keep a channel open to that one person. You can send a voice or emoji message at any time, and - if they are available and nearby - talk in real time. The device is a proxy for the person, and they are represented by it in real space in your home. In this scenario the internet is just magic geography-defying tubes between one house and another.
I know Mozilla is not walking away from this entirely and I hope we’ll get to circle back and explore this some more. The same ideas have spontaneously emerged in one form or another too many times to not stick at some point. We already saw mobile apps packaging up content where the app is essentially a single-task browser without all the noise. In the app store duopoly, these apps represent gated communities, taking chunks of the web and building walls around them. In IoT we have another opportunity to fix this - to keep the benefits and maintain choice, freedom, privacy and security for the users of the technology rather than its keepers. We should attack it from both ends: the publishing and the requesting of content; both resource and client.