VR

This article is a stub. You can help the IndieWeb wiki by expanding it.

VR is Virtual Reality, usually this means blocking your sight for true reality and showing something different, like a cartoonish artificial reality and coarse 3D self-presentations known as avatars, visible to anyone in the same space.

Social VR usually involves multiple people in a shared space with the ability to interact via voice, basic physical interactions, and playing games collaboratively. There are many silo providers, such as VRChat, AltspaceVR, ChilloutVR, NeosVR, JanusXR, and so on. There is great opportunity for an IndieWeb-based effort as well.

Open Source

There are some existing open source social VR efforts:

Mozilla Hubs
- instance: https://hubs.mozilla.com/ (requires JS)
- source: https://github.com/mozilla/hubs
Vircadia

Brainstorming

Client

There could be a browser-like client, which can be implemented natively, or can be built using three.js and WebXR or the like. The client would be able to visit an instance and provide identity information, and then relay whatever realtime interaction is supported by the instance.

Avatars

Add an h-card field, u-vr-avatar, which links to an avatar descriptor. VRM would be a very good starting point.

Ideally, avatars will provide animation data that allows the clients to map the users' positional tracking data into IK-based animations to provide full-body animation with whatever degree of fidelity is available. This will also be by far the most difficult part of avatar rendering.

Avatar-to-avatar interactions can also be facilitated by extending VRM with information about physics colliders and attached scripts which are triggered by them.

Rooms

A room is simply a collection of geometry and scripts. It can likely be provided as a common interchange format such as glTF or something else that's easily parsed by renderers. There would also be script attachments that attach to objects in the room and the room itself; these would likely be implemented in Javascript using DOM-type access methods. There would need to be descriptors for things like physics, users/avatars, and so on.

Instance/session

An "instance" (to use the VRChat terminology) would be a session that provides a room and multi-user real-time interaction. When an instance is created, it would typically start out by copying some statically-hosted room data, and then would maintain the current DOM based on whatever interactions have taken place during the lifetime of the instance (so that when new users join the instance, they see the current state of things).

The instance would be where IndieAuth is consumed for the sake of adding users/avatars into the session, and would provide access control as appropriate for user scripts to modify the DOM. This would also be what coordinates the WebRTC sessions for player-to-player interactions (voice and text chat, positional/interaction data, and so forth).

One common protocol feature of an instance would be the ability for users to drop an instance portal (basically a temporary hyperlink to another instance); this would facilitate exploration between instances. It would be up to the individual users' browsers to manage their instance links, as essentially "bookmarks" or with a micropub-like protocol to speak to their personal instance server to instantiate a new instance.

Public spaces could be provided as room data that is statically-hosted, which an instance server would be able to copy when creating an instance of that room. This would allow arbitrarily many private instances of public rooms to exist without requiring any central hosting of the instance servers themselves, and would also facilitate access control for public vs. private spaces.

Objects

The ability for an instance to carry objects around between instances would be quite intriguing, and would likely require the ability to do (access-controlled) object instantiation from some sort of template kept online, such as an object descriptor that includes a glTF bundle for the visual representation and an agreed-to standard for physics interactions.

Part of the interaction model for objects should also be the ability for an avatar to attach an object to one of its animation bones (for example, attaching a coffee cup to one's hand).

Access control

There are a few access control issues which need to be considered.

Instance servers need to be able to block/allow identities; it would be up to the instance server to manage this mechanism
It should be possible to somehow restrict a room from having instances made by unauthorized people; this could be managed by an IndieAuth flow where an authorized IndieAuth token is required to retrieve the initial resources for downloading into the instance
Avatars can also be extremely personal (almost by definition) and there should be a means of restricting avatars to be only usable by authorized identity URLs; this would essentially require some sort of DRM scheme (or at least a widely agreed-to standard). While it wouldn't be vital to the creation of this platform it would definitely be a barrier for acceptance among a large segment of the VR-using population. However, as an analog, anyone can use whatever u-photo they like on their h-card.

Minimal path forward

A proof of concept could be initiated thusly:

1. Create a self-contained web-based VR experience using WebXR and some common renderer library (e.g. three.js) 2. Add WebRTC functionality to allow multiple users to share the same "room," and use it to stream their voices and positional data to the other participants 3. Allow users to specify an avatar for how they are displayed to the others in the room; ideally this would be provided via IndieAuth and an avatar URL stored in the h-card

From here it becomes much more feasible to start considering things like having an online editor for spaces and avatars (which could then be uploaded to spaces via micropub), and breaking these elements out into reusable libraries that can be used as reference implementations or to simplify the development of the self-contained experiences.