Hard Permission System

[shiftyscales]

Is your feature request related to a problem? Please describe.

Resonite's existing permission system allows for some amount of control over the user experience, but has some pretty significant limitations.

• Most of the existing permissions are binary- either enabling, or disabling functionality outright, e.g. object, and avatar spawning
• World permissions only exist on a per-world basis, and there is no way to easily ensure a consistent experience across worlds the user hosts (particularly for ones they are not the original creator of)
• User-made tooling spawned into sessions can disrupt/break consent of users, and be used in harassing ways, e.g. anchoring the user, applying force to the user, etc.

Describe the solution you'd like

A hard permission system which among other things would need:

• Low level write/modify validations of the data model, locking down parts of it from being modified by users (even in case of malicious client which bypasses the restrictions on user's end)
• Throttling system - limiting how many objects, components and assets can be spawned/modified per unit of time, preventing people from spamming
• Type filtering - will limit which datatypes can be introduced into the model for loaded/spawned objects. This will allow filtering out certain components/nodes from avatars, objects, so they can still be brought in, but with restricted functionality. It'll also allow users to spawn certain items, but not others.

This functionality would ideally come with UI so users, and world hosts can set, and establish preferences/defaults for the sorts of experiences they wish to have grouped into various categories, e.g. preventing force from being applied, being anchored, etc.

These permissions would need a few layers of control, e.g. a world creator with a world that has built-in anchors would need to be separated, and distinguished from objects that are added into the world during a session. Users that are entering hosted sessions that do not match their desired comfort level would ideally be warned prior to joining the session that the world contains types of content they have opted out from.

Preferences should be able to be set under certain criteria as well, e.g. having more permissive permissions for contacts, compared to non-contacts. Whenever we further rework the contacts UI, this could also integrate deeper, e.g. assigning permissions to a group of users, or on a per-user basis rather than just broad 'roles' that are controlled solely by the hosted world.

Describe alternatives you've considered

Currently there is no alternative- users that want to ensure a controlled and restricted experience need to tune the existing permission system to meet their needs as best they are able on every single session/world they wish to host.

Additional Context

There are several issues, e.g. #28, #337, #815, #1100, and possibly others which all broadly would be resolved, or significantly improved by the addition of this feature.

This feature would also help ensure additional user control in choosing the types of experiences they are comfortable with across all of the sessions they host/visit.

[989onan]

What would be nice if the client can block things happening to them, rather than a world blocking them for everyone
I find an issue can arise where a group of users wants to shoot each other or have fun in a hidden location not bothering anyone, but the world says no.

Those users would move somewhere else, or further schism the community into more specialized worlds
What would be nice is if the data model can prevent things from working that users can opt out of themselves, without ruining the experience for everyone (as you mentioned, "preventing force from being applied, being anchored, etc.")

I have made mods to prevent knock back, and in game systems already exist to prevent knock back tools and anchoring from working. It would be preferable to allow users to choose what happens to them, rather than the host choosing for them in such cases.

But case in point, the host should be able to decide what can be done to the world in a more granular way as you mentioned, but I think it should still allow users to decide to filter the content that only concerns themselves without host intervention

[Frooxius]

The goal of this system would be to provide ability for both. More control on what happens to you and your avatar and more control to the host on what happens in their world.

This will allow host to allow that kind of behavior, but individual users still preventing it if they want to.

However we also want to allow the host to block certain things completely if they wish to do so - that might be necessary for certain types of sessions (e.g. game worlds or chill social sessions).

[JackTheFoxOtter]

Will the world also be able to "enforce" something to be enabled? For example, a game world that requires knockback wouldn't work for users that disabled knockback affecting them.

[989onan]

Will the world also be able to "enforce" something to be enabled? For example, a game world that requires knockback wouldn't work for users that disabled knockback affecting them.

would be good to notify users as such, and that certain features may not work and make sure they know that it can very easily break stuff in said world

[shiftyscales]

That was what Frooxius was getting at, @JackTheFoxOtter.

As I mentioned- I would want there to be several layers here, e.g. world-level permissions, session-level permissions, individual permissions, etc.

E.g. say you want only contacts to be able to interact with your dynamic bones, or a specific user(s), etc.

Or say you've made a game world that needs to have knockback enabled.

Separately, distinction from things that are 'part of the world' compared to things users spawn in to the world, e.g. the world could have knockback functionality, but users in the session couldn't bring knockback items.

[gentlecolts]

I think one of my personal takeaways from the discussion in #337 was that it might be good to look to web browsers or systems such as iOS/Android for inspiration on handling granular permissions.

For example, at the world level, a world may want to say "This world needs xyz permissions", which would require users accepting (either through global settings or on a per "app" basis), before joining/creating sessions.

It may also be necessary for there to be some sense of "loaded or spawned by the world" and separating that from content spawned by users. One elegant solution here may be through recursive permissions on slots, where existing workspace managers could have sandboxing restrictions set on their slots, and all user roots under them would be subject to those restrictions. Content spawned within, therefore, could be made to not be able to even see further out than their own user workspace. This brings some challenges as colliders or raycasting potentially allowing content to break free from that sandbox, but could still be a very worthwhile avenue for exploration.

But there's also several different perspectives to think about here too:

• a world, for example, could be treated many different ways, but its permissions are likely to be thought of as "things i need to be able to function properly", some of which may be required, some of which may be optional
• a session, of which the session's host may have preferences on what should/shouldn't be allowed in the session they're running
• the user themselves, who may dislike exposure to certain kinds of content, or have a need to restrict some types of content for accessibility reasons, all of which may not necessarily be reasons to prevent them from entering a world/session if it's acceptable for that kind of content to simply be disabled client-side

Another item for consideration is that permissions and discussion around it may have overlap with content performance and content age ratings, and it may be a good idea to draw a clear line about where those subjects overlap

[EmergencyTemporalShift]

Something that comes to mind is that, for example if you had a session where knockback was required to participate in the game, spectators would not need to allow knockback on themselves. (Also if you had some sort of unequal team game, where knockback is allowed one way but not the other (think 1 v 3 Mario party games) or a no knockback mode on a game. Would there still be a warning before entering the game world or just before joining a game with those things enabled. Would it be more difficult to enable or disable pre join warnings via flux or components automatically?

[gentlecolts]

Would there still be a warning before entering the game world

Better to ask ahead of time if the user "might" be exposed to a feature by being present in a session than to disrupt experience mid-session to make a request just-in-time, my two cents.

[shiftyscales]

My hope/vision for the feature would be that we'd have a mechanism to warn users if a world/session's settings do not match the preferences they've established- and from there they could choose whether to join anyway, or cancel.

This world may contain the following experience(s) that you've opted out of:

• [x]
• [Y]

Join anyway?
[Join] [Cancel]

[charlie-sans]

from what i'm reading in this issue, the hard perm system is simalar to something like linux and it's kernel rings where the low level parts are rings 1 and 0 and everything else is userspace/ring3?