MRS: Rough Consensus & Running Code
A fortnight ago I ran the first Mixed Reality Service BOF (birds-of-a-feather) meeting, at Web3D2017. It was well attended — perhaps half the conference delegates found their way to our cozy quarters at QUT’s Garden Point campus — and surprisingly contentious.
Being the first time that I’d fronted a group who had at a solid understanding of the 3D Web, I was expecting some pushback — mostly around technical points. But the pushback was more around the philosophical aims of MRS, rather than any particular technical goal.
In short: people don’t like rules. Developers especially don’t like rules, and insofar as MRS has been touted (largely by me) as a way of providing guidance to AR apps like Pokémon Go, so that they’re only playable in the appropriate spaces; or to keep walls from being the target of hate speech — all of these seem quite restrictive to a generation of developers who are just beginning to explore the possibilities of mixed realities.
When MRS is framed in highly formal terms — with canonical ‘registrars’ mapping onto various aspects of legal and traditional ownership — that’s where the folks at Web3D2017 had the most questions, and the most misgivings.
On the other hand, the idea of mapping URIs to coordinates broadly seemed to be accepted as a good thing — as long as it doesn’t come encumbered with too many rules and restrictions.
Although the analogy with DNS is imprecise, it’s as though folks want the benefits of running their own local nameservers, without worrying about the canonical DNS servers.
That harkens back to a very early Internet of the 1970s and 80s — before DNS — when every systems administrator managed their own hosts file by hand. Rolling-your-own meant you could have any namespace mappings you desired, and they’d work out fine for anyone using your nameserver.
Gradually, that grew impossible to maintain, and people accepted the canonical nature of DNS as an acceptable trade-off for a namespace that could grow effectively without limit (and which continues to grow today).
Over the course of the BOF it became clear that MRS needs a change of direction, reorienting toward the needs of the people who want to use it — but don’t want to be restricted in their use of it while they have a play.
There’s nothing unusual about that; new technologies often need a ‘magic circle’ where folks can play and explore and learn without the fear of failure — or too many rules. It’s in this play that the necessary scope of rules are discovered.
All of that calls for a change in course.
The whole history of the Internet — from email to DNS and on to the Web and pretty much everything else built atop it — has followed one rule of thumb: “rough consensus and running code”. Rough consensus means folks should agree what needs to be done — though not necessarily in detail, and running code implements that consensus.
The rough consensus for MRS in June 2017 isn’t anything grand or global, just something useful enough to empower a generation of mixed reality applications on the Web. A simple, local version of Mixed Reality Service, so people can develop their own apps, using MRS to support their ideas.
Glitch makes it super easy to create Node.js web apps, so over last weekend I ported the Python 2.7 implementation of the MRS server to Node.js, running on Glitch. Have a play.
Better yet, Glitch is all about code sharing, so follow this link to the project, which you can clone and use to run your own MRS server.
Everyone can now have a play with MRS. This play will teach us what we really want to use MRS for.