gfodor
commented
6 years ago Hey @michaltakac, thanks for the post, we'll def check out your projects! We don't have a concrete technical roadmap for this repo ready to share yet, but I can give you a high level overview of what we're working towards. In general, you should expect a fully working example with "batteries included" so that you can run this stuff yourself sometime in Q1 2018. Thank you for your offer to contribute, right now things have a lot of churn so it may be difficult to start cutting PRs, but we'll be working as fast as we can to get to a point where there's a fully working system that anyone can start contributing improvements too.
In general, our strategy in our backend tech stack choices are driven by two things:
-
For the XR applications on the web, it's critical we be able to use the WebRTC networking stack to ensure we can do good VoIP and unreliable message delivery (via SCTP/data channels)
-
It's important we have the ability to have a scalable, low-latency, game networking system that supports durable state, replication, cross-room communication, and distributed state like presence.
In addition, it'd be ideal to also have that backend system be able to act as a great web/API server as well. (This is inspired by the ideals of building a Majestic Monolith for a backend mixed reality application server.) For example, it'd be nice if the web APIs you use to draw the list of users in the room don't have to hop through a bunch of microservices that replicate the data they need, they can just be going to the same machine that is running the actual simulation itself, which already has it, up to date, in RAM.
So, what we're doing is trying to pull the best off-the-shelf solutions (not just in terms of capabilities today, but in terms of traction and community) for solving these problems, and melding them together. What this results in is:
- Using the Janus WebRTC Proxy for connection management, signalling, and WebRTC communication
- Using Erlang/OTP/Elixir/Phoenix for the core of the game networking system, which takes advantage of the 30 years of development that has gone into OTP, as well as the cutting edge work going on in things like Phoenix Presence and Riak Core.
What we are focused on right now at this level of the stack is trying to make these things work together well. Our Janus SFU plugin is a first-pass at turning Janus into a data channel relay to bootstrap our client protocols and APIs, but in general the longer term goal is to migrate our client to use Phoenix Channels, with delivery of messages to the elixir cluster (for routing, persistence, etc) by Janus. Of course, this is all going to be open source software that will be contributions back to the various communities/projects that anyone can use for whatever they see fit. This work is ongoing right now, but still early so nothing to announce yet. Stay tuned :)
Hello, nice to see the elixir is being used for social XR stuff. I've been dubbing with elixir+aframe combination for few months a little while ago but dropped work on it since I've moved to decentralized social WebVR at Decentraland.
I want to ask if there is any roadmap for this API/repo or what features it should have, so if I wanted to contribute, what should I do?
P.S. There are two of my tests with elixir+aframe, very experimental: In first one, one user can see another user's avatar moving around (used incognito for another users), but re-logging to previous session is not implemented so it's kinda funny after while. In second one, there's also an authentication (but WebVR part is unfinished).
The goal in both was to have the ability to drop the scene (any A-Frame scene) and have the entities synced without adding networked-aframe component to each entity manually. Is this something that's also on the roadmap?