Prevent Installing Locomotion Modules

[ProbablePrime]

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

Im frustrated when random people come into my worlds and randomly install locomotion modules. It generally makes a mess and can break some game related maps.

I just find it rude sometimes.

I'd love to block this node somehow.

Relevant issues

No response

Describe the solution you'd like

Some way to prevent additional locomotion modules from being installed.

Describe alternatives you've considered

I've used the Locomotion Permissions component "Require Tag" option to restrict all locmotion modules to only those that have my defined tag. This works but doesn't prevent the slots from being created or "installed".

I've also used "Slot Children Events" to delete any new modules that might appear in the hierarchy.

But it would be good to stop this at the source.

Additional context

No response

[shiftyscales]

I'm pretty sure this would just fall under the general purview of hard collections wouldn't it? By my understanding- hard permissions #289 would allow you to make such filters, e.g. users can't add these components, but these pre-existing ones are okay. You could use it to filter any arbitrary nodes/components.

Currently Neos features a soft permission system, designed to keep the user experience more in control, but not to fully deal with malicious actors and people looking to actively break the experience.

This will be addressed by a "hard permission system" comprised of several parts, which is going to enable following:

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.

These elements in combination should provide a stricter way of controlling the experience and harden the system against malicious users as the community grows.

As someone that routinely uses the grab world locomotion and installs it on myself (not the world) on a daily basis because it is no longer a default locomotion unfortunately #3141- I understand and sympathize with those that have custom locomotions for comfort, e.g. Veer's three axis fly locomotion which he's used for years in the absence of bed mode #225. This feels like a request that's best dealt with by use of existing self-moderation tooling for now until such point as we add hard permissions.

[ProbablePrime]

Of course, but im not not going to list requests just because collections or hard permissions covers them.

[shiftyscales]

Isn't that the definition of a duplicate issue? If there exists an issue to introduce a mechanism that is flexible enough to solve basically any similar arbitrary requests to this one- why have an issue specifically for something that'd be covered under it? This could just as well have been a comment on the hard permission issue itself explaining your use-case for it.

[ProbablePrime]

In some regards yes, in some regards no.

Hard Permissions is a dependency on many other scenarios.

This feature or tweak would depend on Hard Permissions. In product management, we'd usually log individual feature requests and tie them back to a dependency if one exists. This makes a chain of items that need to be fulfilled before the dependent ones can be.

The reason that this is done is to ensure that we don't forget anything. There exists a possibility where hard permissions could be created but this exact item is not possible for some reason, As such it's relevant to log both.

Of course this is subjective and some items are actual duplicates of Hard Permissions. It depends on individual items.

As a better example, we're not going to close all of these: https://github.com/Neos-Metaverse/NeosPublic/issues?q=is%3Aopen+label%3ACollections+sort%3Aupdated-desc just because collections solves them. We're going to leave them open until collections natively handles them or we added them after collections is created.

Permissions, Security and Accessibility is of particular focus for myself so every time a user asks about a feature in this area I ensure it gets logged. This was logged on behalf of another user who was too anxious to make it. They don't wish to be named, But I want to make sure we don't forget it.