"Creator co-presence as key" (CCK) model:
In this model, objects that someone spawns in a room are permanently available, stored remotely, but only exist when that person is in the room. Ownership transfer doesn’t alter who these objects are bound to: it is the creator who matters. Since we don’t have accounts, this means “if I create an object in a room on device X, if I join the room in the future on device X or any device that is connected to device X via linking, those objects become visible again.” It is dependent upon local storage keys for unlocking this state, so if using a private tab or cookies are cleared, access will be lost.
All spawned entities (other than avatar) and uploaded files required to support those entities.
- What are the benefits of persisting that state? What use-cases does it enable? What problems does it solve?
This makes it so as long as I retain at least one copy of my local storage keys, things I create in Hubs won’t be lost. This makes it so if I disconnect incidentally, it won’t go away. I can also lay out some objects in a space by myself, leave, and later share the link to show someone what I’ve done, as long as I join them in the room. It is also a seemingly consistent model that can be applied across various contexts (uploaded files, entity state, etc) and is fairly intuitive and privacy preserving since co-presence in the room is one-to-one with full cognitive awareness that your content is being made available to others.
- What are the use-cases that are not solved by this? What problems does this potentially introduce?
In spaces where there is any kind of collaborative object spawning, full re-creation of that state will require all participants to re-join. In spaces where there is some kind of shared content that should be “room owned” (like a video everyone is watching), it is somewhat problematic that if the creator of that object leaves or drops out the video goes away (however, if they rejoin, it will pick up where it left off.)
It also can be a bit unintuitive in certain cases who is the creator of an object if that object transfers ownership throughout the session. (For example, I may spawn an object for someone else to use, if it’s just easier for me to do the spawning, but in practice that other user is the one who does the actual creative work on the object.)
Finally, this locks this state to a specific room. If I want to re-use creative work I’ve done in room A and bring it to room B, I’m unable to do so. (For example, I want to take an art gallery I’ve put together and make a new room with the same objects, to make it easier to share with a new group of people or to change it for a new purpose.)
(Edit: This point above is actually not true, we could build mechanisms to let you create a copy of a room that you’re in, and all the objects you’ve spawned, obviously.)
- Where is that state stored?
The state would be stored on our servers, encrypted in a way to prevent access unless that person is connected to the system.
- How and when is that state made available to others?
When a person joins a room, all the relevant objects they had created in previous sessions will spawn.
- What level of access do we, the hosting provider, have to that state?
We will only have access to this state when the user is connected, and when those keys are not available in memory to the server they will effective lock out access to the state from everyone but the creator. The keys to decrypt the state will be privately shared with the server while that person is connected.
- How and when is that state removed?
The state will be removed when the user deletes the objects from the space, and potentially will expire on some long TTL.
- How future-proofed is this solution?
Entity state storage will require some formal schema to ensure future proofing. (Perhaps this should be stored as GLTF under our scene schema.)
- How durable is this state? What guarantees around durability can we give users?
This will be highly durable state since it will be server side storage. However, it can be “lost” if the user ends up clearing their cookies from all the relevant devices they’ve used from Hubs.
- What effect does this have on user experience?
The “stakes” factor should remain the same since the user never leaves anything “behind” in the room, it goes with them. However, users will likely start to see Hubs as at least in part a creative tool since they can create and “carry” sets of objects with them across sessions to show others.
- What is the mental model we expect users to have around this state?
“I take the objects I create with me when I leave, and bring them back when I re-join that room.”
- What effect does this have on privacy?
Private information is potentially exposed to other users when the creator is co-present. Beyond that, information is sealed off, provided we do not have any mechanism in our servers or logging which would store the shared key. However, If someone creates and object, but another user imparts some kind of private information onto that object, that private information is under the control of the object creator, not the person who imparted it. (For example, if someone spawns a couple of line drawings and then I re-position them to spell out some private information, that information will be stored with the creator’s key not me.)
- What are potential abuse vectors?
Any vector which tricks a person to impart state an object that was created by someone else could potentially allow the creator to have permanent access to that state.
Since this will result in hosted storage, there are abuse vectors around excessive use of that storage for bad/illegal purposes, like copyrighted file hosting, etc.
- What resource limitations are relevant for storing this state?
We’ll be storing all state so it will require we have some kind of limits or expiration policy. (Or perhaps paid hosting plans.)
- What effect does this have on content rights? (IP, copyright, attribution, etc.)
We’ll have to have DMCA takedown channels and proper attribution for spawned content.