Big list of tech debt stuff

[netpro2k]

In no particular order, and being on this list doesn't mean we should fix it but just providing a place to quickly jot down high level issues similar to our performance improvements list, we can then pull things we want to work on into actual issues

Existing issues:

• Deploy or ditch big sign-in refactoring https://github.com/mozilla/hubs/issues/2230
• Apply VRDisplay pose data to the camera at the beginning of the frame https://github.com/mozilla/hubs/issues/2229
• Check if we are handling data-urls the way we expect https://github.com/mozilla/hubs/issues/2197
• Refactor user input bindings https://github.com/mozilla/hubs/issues/802

Some more from me:

• refactor/replace networked aframe. Particularly, the transport is pretty bloated and should be able to be trimmed down quite a bit. Also the way messages are handled out-of-frame is potentially a source of bugs, confusion, and frame drops. Ideally this also can be something not aframe specific as networked-aframe (and its templates) are one of the biggest things still tying us to aframe. This can probably be broken into a few independent parts (in no particular order):
  1. Decoupling the voice and game networking. Right now all of the voip/janus stuff is tied in with networked-aframe. This is largely due to legacy reasons of webrtc being the main transport layer for the game networking messages as well. This is no longer the case (and likely will remain this way, though if it wont we may want to rethink this). It would be nice to split off the voice stuff into its own indendant connection flow and library (or possibly use en existing battle tested webrtc library, maybe there exists one with the video-room plugin). This would help us get rid of the class of bugs like ghost avatars, which result from webrtc state being generally less reliable than the phoenix presence state, which we should probably be relying on for this instead.
  2. improving how networked object templates are defined (likely we may want to move this into gltfs, especially as our blender tooling around this improves)
  3. Improving the wire protocol. This could be anywhere from just trimming down how much json we send to a much more optimized binary representation (depending on if there is any path to dealing with the later in pheonix).
  4. Improving sending/receiving logic. A bit open ended, but this could be anywhere from just improving the ability to send partial component updates (right now the granularity is full component) to having individual networked entities do their own custom serialization/de-serialization (ala photon).
• take control of startup and raf loop. Right now aframe owns this and it makes certain thing pretty unpredictable, and makes adding certain kinds of features harder than they need to be. It seems fairly tractable that we can rip this out of aframe such that we have control over actually initializing the WebGLRenderer ourselves and setting up and running the raf loop when we are ready to do so. This should make cleaning up the initial application loading experience easier to improve, and also give us better confidence on the order of events when initializing the scene and when ticking systems/components behaviors each frame
• remove aframe as an unnecessarily layer of abstraction. We have been naturally widdling down the usage of aframe and are likely not to be able to (or have the need to) pull in future updates that come down the pipe. It seems possible to continue to pull things out of our aframe branch over time until not very much remains, and then begin to replace components individually over time. Biggest blockers right now on this are networked-aframe because of the templates (also one of our bigger source of confusing bugs), and lack of an existing good pattern to structure our code without using aframe components.

┆Issue is synchronized with this Jira Task

[robertlong]

I'll add one:

• Get Hubs and Spoke on the same page for component implementation. It'd be great if we only had to write these features once and could preview them in Spoke. If we moved off of AFrame for components or came up with some sort of wrapper to ease the transition, we could share that code between the two projects.