Opening up cyberspace with Matrix and WebVR!
2017-04-04 — Tech — Matthew Hodgson
TL;DR: here's the demo!Hi everyone,Today is a special day, the sort of day where you take a big step towards an ultimate dream. Starting Matrix and seeing it gaining momentum is already huge for us, a once in a lifetime opportunity. But one of the crazier things which drove us to create Matrix is the dream of creating cyberspace; the legendary promised land of the internet.Whether it's the Matrix of Neuromancer, the Metaverse of Snow Crash or the Other Plane of True Names, an immersive 3D environment where people can meet from around the world to communicate, create and share is the ultimate expression of the Internet's potential as a way to connect: the idea of an open, neutral, decentralised virtual reality within the 'net.This is essentially the software developer equivalent of lying on your back at night, looking up at the stars, and wondering if you'll ever fly among them... and Matrix is not alone in dreaming of this! There have been many walled-garden virtual worlds over the years - Second Life, Habbo Hotel, all of the MMORPGs, Project Sansar etc. And there have been decentralised worlds which lack the graphics but share the vision - whether it's FidoNet, Usenet, IRC servers, XMPP, the blogosphere or Matrix as it's used today. And there are a few ambitious projects like Croquet/OpenCobalt, Open Simulator, JanusVR or High Fidelity which aim for a decentralised cyberspace, albeit without defining an open standard.But despite all this activity, where is the open cyberspace? Where is the universal fabric which could weave these worlds together? Where is the VR equivalent of The Web itself? Where is the neutral communication layer that could connect the galaxies of different apps and users into a coherent reality? How do you bridge between today's traditional web apps and their VR equivalents?Aside from cultural ones, we believe there are three missing ingredients which have been technically holding back the development of an open cyberspace so far:
- The hardware
- Client software support (i.e. apps)
- A universal real-time data layer to store the space
- a virtual lobby, providing a 1:1 WebRTC video call via Matrix through to a ‘guide' user of your choice anywhere else in Matrix (VR or not). From the lobby you can jump into two other apps:
- a video conference, calling between all the participants of a given Matrix room in VR (no interop yet with other Matrix apps)
- a 'virtual tourism' example, featuring a 1:1 WebRTC video call with a guide, superimposed over the top of the user going skiing through 360 degree video footage.
Now, it's important to understand that here we're using Matrix as a standard communications API for VR, but we're not using Matrix to store any VR world data (yet). The demo uses plain A-Frame via aframe-react to render its world: we are not providing an API which exposes the world itself onto the network for folks to interact with and extend. This is because Matrix is currently optimised for storing and synchronising two types of data structure: decentralised timelines of conversation data, and arbitrary decentralised key-value data (e.g. room names, membership, topics).However, the job of storing arbitrary world data requires storing and flexibly querying it as an object graph of some kind - e.g. as a scene graph hierarchy. Doing this efficiently whilst supporting Matrix's decentralised eventual consistency model is tantamount to evolving Matrix into being a generic decentralised object-graph database (whilst upholding the constraints of that virtual world). This is tractable, but it's a bunch more work than just supporting the eventually-consistent timeline & key-value store we have today. It's something we're thinking about though. :)Also, Matrix is currently not super low-latency - on a typical busy Synapse deployment event transmission between clients has a latency of 50-200ms (ignoring network). This is fine for instant messaging and setting up VoIP calls etc, but useless for publishing the realtime state of a virtual world: having to wait 200ms to be told that something happened in an interactive virtual world would be a terrible experience. However, there are various fixes we can do here: Matrix itself is getting faster; Dendrite is expected to be one or two orders of magnitude faster than Synapse. We could also use Matrix simply as a signalling layer in order to negotiate a lower latency realtime protocol to describe world data updates (much as we use Matrix as a signalling layer for setting up RTP streams for VoIP calls or MIDI sessions).Finally, you need somewhere to store the world assets themselves (textures, sounds, Collada or GLTF assets, etc). This is no different to using attachments in Matrix today - this could be as plain HTTP, or via the Matrix decentralised content store (mxc:// URLs), or via something like IPFS.This said, it's only a matter of time before someone starts storing world data itself in Matrix. We have more work to do before it's a tight fit, but this has always been one of the long-term goals of the project and we're going to do everything we can to support it well.So: this is the future we're thinking of. Obviously work on today's Matrix servers, clients, spec & bridges is our focus and priority right now and we lots of work left there - but the longer term plan is critical too. Communication in VR is pretty much a blank canvas right now, and Matrix can be the connecting fabric for it - which is unbelievably exciting. Right now our demo is just a PoC - we'd encourage all devs reading this to have a think about how to extend it, and how we all can build together the new frontier of cyberspace!Finally, if you're interested in chatting more about VR on Matrix, come hang out over at #vr:matrix.org!- Matthew, Amandine & the Matrix team