Ok so here’s a concrete proposal of a plan. I think based on the feedback in the thread we can pitch the CCK concept, and implement a 2-phased build out of ORO which then leads naturally to an RS model that dovetails with the editor tooling. (Doing it in the opposite order seems hard to wrap my head around.) The net effect on the other side is we have most of the use-cases covered, privacy seems good, and there’s minimal UX complexity.
First, we should just ensure that content created by a user (drawings, etc) does not get lost due to a reconnect. This is basically unrelated to persistence but I think is worth mentioning as something worth verifying and enabling if it doesn’t work.
Milestone 1:
I think the main mechanic we should introduce first is the “pin” concept. Every object in the room is by-default “un-pinned” and will be erased when the owner leaves. However, the creator (and only the creator) has the ability to pin the object. The UX probably looks something like “hit pause, and pinned objects look more ‘permanent’ in the scene, and you have a one-click to pin action you can perform.” A v2 could introduce a “pin lock” concept so all objects created are pinned by default for that session.
Under the hood, pinning will store the state of the object in a durable way (mechanism TBD) and also move uploaded content into permanent storage.
In order to pin something, the person must create an account. This is necessary because we need a way for that person to audit and delete the objects they have stored on our servers. The pin action can be visible at all times but clicking it will pop a sign in/sign up gate.
On the other side of this, users have a mental model that they must opt in to any long term persistence. This model is very privacy preserving since only the creator can pin, and it’s always clear to the creator when their objects are being made permanent. The downside is there may be unintentional loss of work if you forget to pin something important, but if we introduce the “auto-pin” functionality in a nice way, that could close the gap.
Milestone 2
Once pinning is implemented, the next phase will be to allow users to take a room with pinned objects and remix it in various ways. At this point, we can probably align this with our UX and model for scene creators using the Spoke editor. At this point it seems likely that scene creators will have two options for managing their scenes:
- Full export to GLTF, do what you wish and host where you want. Does not require an account.
- Hosted solution, scenes are stored on our servers, with various pages to support their use and discovery. Requires an account.
These two methods would then become available to users in-room as well but the context would be the set of pinned objects in the room.
At any time, users would have the option to export the current scene as a GLTF – that GLTF will include a reference to the scene GLTF and have internal nodes for each of the pinned objects. When that GLTF is used as the scene for a new Hubs room, it should effectively behave as a snapshot: the pinned objects will be in the room, but are dynamic and can be deleted, etc, as they are at export time. This export option will be available without an account, but will only export pinned objects, so those objects will have had to be created by people who have an account.
In addition to that, there will be an option to “Create a Scene” from the current room, which will tie into the same flow that is used in the Spoke editor. This will require an account, and will export and host the scene (which includes the pinned objects) in an identical fashion to the flow in the editor, but would be in game. This new scene would then be available on hubs.mozilla.com for sharing, feedback, etc.
One big downside to this model is that there’s an account gate to enable any form of persistence, since someone needs to pin an object for it to become persistent and exportable. It seems difficult to resolve this without adding at bunch of conceptual complexity: users should control what data can be exported, which implies they should have an opt-in mechanism to allow export/persistence of that data.
If we wanted to avoid the account creation step, we could have two attributes object creators can set (“pin this object” which would require an account, and “allow this object to be exported” which wouldn’t) but that seems super confusing and weird. The model outlined above is pretty natural: an object can be in two states – the initial state is the object is ephemeral and hard to export by others, and once it goes into the “pinned” state, it is permanent and conceptually exposes its data to everyone in the room, both in the form of being exportable but also because the object will always be in that room for them to see even if the creator leaves.
Overall, this seems worth the tradeoff, but if there’s a way to introduce the use case of “a bunch of people can create a room, intentionally create exportable objects, and export it as a GLTF without anyone signing in” I’d support it if it doesn’t result in a bunch of UX complexity or change the “my object are private and temporary by default” mental model users will have if we implement the above.
Also worth mentioning: what is covered here is largely about UX and not fundamental security when it comes to others in the room – since others in the room download your data to see it, of course they have everything they need to copy all of your objects, regardless of if you have pinned them.
Regardless of technical capabilities, encouraging certain behaviors and models for how people should interact with one another in the space is our job as social system designers, and the UX we design is our best way to communicate this. The model above encourages opt-in-to-expose content as the model, but leaves open the possibility for alternatives to be created by 3rd parties. For example, one could imagine a browser plugin that enables “export to GLTF” for all scenes you are in while in Hubs.
With this in mind, we shouldn’t be too fearful around our built-in UX being too restricting if the restrictions are there to foster certain cultural norms and increase user trust. If these are too limiting for certain users the possibility will exist for 3rd parties to help get around them. Much better for us to be adding these kinds of features with care, than potentially making things too open in a way that is hard to reverse – particularly because in most contexts where this is problematic for people, the web makes it possible for them to find a non-sanctioned mechanism to get past any model we’ve burned in. And of course, we’ll learn and potentially can refine these models over time as we determine if any of our decisions were overly cautious.
