Extensibility

[robertlong]

I just completed a first draft at refactoring some of the Matrix-related code and in the process I thought a little about how we might start structuring extensibility for Third Room.

I think Third Room should be opinionated about quite a few things including:

• The player rig
• ECS / Rendering / Physics Libraries
• A standard network protocol based on WebRTC datachannels and media streams
• glTF components
• Data formats for user profiles, rooms, etc.

I don't think it should be opinionated about:

• WebRTC signalling
• Authentication methods
• Backend technologies in general

I think you should be able to swap out:

• The backend stack for WebRTC signalling, profiles, etc.
• The UI library and just use the 3D framework

I think that we should decouple logical components from presentational components for the UI. This means splitting matrix-specific code into hooks or hooks that deal with rendering the 3D scene, avatar previews, etc. I think the 2D UI extensibility should come from installing Third Room as a library of React components and hooks that you can compose however you see fit. There will be sensible defaults, but you can override most things. We won't use super opinionated methods of styling or storing state. We'll use CSS modules and support passing className and style props to most components. For state stores, we'll probably stick to the built-in hooks like useState and useContext. Maybe we'll pull in something like Zustand for a global state store, but I'd really like to keep it lightweight.

For the 3D code I think we should take care to define core libraries that don't make assumptions about the UI or backend. Instead we should expose APIs that can interface with these external dependencies. I think we need a plugin API that has three layers:

1. The highest layer will be the Plugin interface which will work around Third Room specific concepts. It'll have lifecycle hooks for loading/unloading rooms, switching scenes, or changing avatars. This is where you can do Third Room specific things and really tie into the UI layer.
2. The middle layer will be bitECS systems/components or our wrapper around bitECS and Three.js. This will be where you write custom behaviors that don't need to deal so much with Third Room specific things. You can query for our specifc components, but ideally most of these systems/components will be portable to other projects.
3. The lowest layer will be Three.js specific code. It won't deal with bitECS or our ECS wrapper. This code should be highly portable to other apps. It also means you can bring in third party Three.js libraries pretty easily.

I'm still not exactly sure what the Plugin interface looks like or what our final ECS framework will look like. If you have ideas on these concepts or examples you'd like to point to I'd love to hear them!