Visual protections against unwanted content

[Teramanbr]

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

Currently, people can join any worlds with any avatar, and some avatars may have unwanted content, NSFW content or cause epilepsy inadvertedly.

Describe the solution you'd like

I suggest something like the VRChat Trust and Safety System.

Describe alternatives you've considered

Something like #1564 to tag content, maybe both at the same time. Or giving users an item or option to disable visibility of unknown people's avatars, and by using that item, adding a tag on top of your name, just like the Linux users' tag.

Additional Context

This was discussed a bit in the Resonite Moderation Office hours.

Requesters

Teraman_br

[Frooxius]

If people have NSFW content in public worlds, this will likely go against our guidelines.

However more generally, I don't fully understand how is this different from #1564? This would provide mechanisms to filter out unwanted content.

Additionally you can already block people's avatars with in-game functionality - find the user on Contacts tab (you don't need to add them as a contact) and select "Block Avatar".

[Teramanbr]

To sum it up: Completely blocking stuff coming from untrusted users and without a tag would (in my opinion) be good too. I think a setting to just straight up completely block items and avatars that don't come from friends or "trusted people" would be nice. Or being able to choose what things you wouldn't specifically want to see from untrusted users, like audios, videos, 3d objects, protoflux and stuff, the "keeping one on, turning the rest off" kinda thing.

[Geenz]

To be clear, #1564 is not intended as part of a trust system, just a way for users to manage what content they wish to be exposed to. It also has a certain presumption of users tagging their content appropriately, which moderation may do for users if the need arises (for example, if someone suddenly decides to make a flashbang grenade and neglects to tag it as "photosensitive" - either maliciously or mistakenly).

Trust systems are tricky to build and very easy to game. All you need is time, and enough accounts you can friend. What's likely the better route is something like #1564 wherein a user can opt-in or out of specific content, with our guidelines generally filling in the rest here with moderation taking action against users who actively break our guidelines. Maybe have a setting to only view content from friends or people within a given session.

[Frooxius]

What defines an "untrusted" user? Is it just who is your contact or not?

Are you asking for users who are not contacts to have their avatars blocked by default? For what reason? If it's to block photosensitive/NSFW stuff, then the #1564 system would play role there, but I don't see how that has anything to do with trust.

Blocking items is also something that's harder to define - what exactly do you want to block? The item visual? Where does it get separated? Sometimes it's not clear where an item ends and the "rest" of stuff starts. What if trusted users interact with untrusted items? What if untrusted items interact with trusted users? This gets complicated pretty quick, so it might be important to define what we actually want to do here and what problems we want to solve.

Some of the unwanted interactions will be covered by hard permissions: https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1103

My main goal here is to identify what kind of problems are you asking to be solved exactly, because we have a number of existing issues that cover some of them.

[JackTheFoxOtter]

I would like to heavily emphasize that I don't think VRChat's "trust" system would be a good fit for Resonite. Just because a user is new or doesn't have many friends should not automatically determine them as "untrusted". One of the best meta-features of Resonite is that from the moment you start the game for the first time, you're a part of the community just like anyone else. There are no different "tiers" of users. I believe this could quickly lead to a worse first user experience. If a user acts up and is being reported, that's a different story. But we shouldn't by default assume users are "untrusted" until they prove themselves - it should be the other way around.

[Frooxius]

I agree there. Resonite has different philosophy in how we approach community and the tools we provide and it has a number of technical differences too.

For that reason, I would never want to just take a feature from another platform and blindly apply it to us, because it might not be a good fit.

It's one of the reasons I'm more interested in the underlying problems that this is trying to solve - if we understand those better, we can engineer solutions more suited for Resonite and its community.

[AmasterAmaster]

I can see a case where if they are new, then only put small restrictions on them (maybe for like 24 in-platform hours). For example, they are handed a blinding/seizure gun and running around with it. Since they are new, it wont be as "blinding" to other users for at least that limited amount of time.

Other than that, I do agree that anything harsher than that, would be a tad too much. New users should not be restricted on features here, only the intensity of disruptive actions.

[JackTheFoxOtter]

I don't see a reason for that. The first 24 hours ARE generally the peak new user experience, and there wouldn't be any benefit from making it different / worse for them. I fundamentally disagree with putting restrictions on a user just on the basis of "they are new so we don't know if we should trust them yet".

Also, on a technical level, "intensity of disruptive actions" is pretty vague and I don't really see how that could be defined, if at all.

[AmasterAmaster]

@JackTheFoxOtter I am just being a "devil's advocate" here, as there are many ways this could be handled, and I only gave one case that I foresee. The number itself is arbitrary, could be the first 5 hours, could be the first week, does not matter.

On top of that, it could be a specialized experience for the new user, like they get out of the tutorial, fresh and ready to get into Resonite. But now (new scenario) the roles are swapped, the world is pure chaos and it overwhelms them as there are no protections currently. A system like this (since they don't have friends right now) would now make all the "intense or disruptive actions" be slightly lesser so the new user does not have a negative experience.

The "intensity of disruptive actions" I define are as follows:

• Intense bright lights
• Color/seizure effects
• Loud or obnoxious noises
• Sudden applied forces that send users to floating point
• etc...

[JackTheFoxOtter]

Protections against those sort of disruptive / dangerous effects shouldn't be related to the "trust" of a user at all, they should be options that are available to everyone. There is #554 for example, which would provide a local option to disable fasts motions in experiences. In the same way there could be modes that reduce bright flashing colors or loud sound effects by filtering them out. But neither of these would be exclusive or even impacted by wether or not a user is "trusted".

[AmasterAmaster]

Yea, I don't think there should be a "trusted" system at all (as time spent in Resonite can be seen from experience socially with others). But back to OP's post, protections would be nice. And like froox said, hard permissions may help a lot with this. And tagging should help as well. This whole issue could be multiple problems summed up into one, so it is not easy to explain nor to solve in one go.

[RyeTheGooSnep]

Yea, I don't think there should be a "trusted" system at all (as time spent in Resonite can be seen from experience socially with others). But back to OP's post, protections would be nice. And like froox said, hard permissions may help a lot with this. And tagging should help as well. This whole issue could be multiple problems summed up into one, so it is not easy to explain nor to solve in one go.

From personal experience, rank systems are nothing but problems and will cause a divide in a community due to them becoming a status symbol and a means to disassociate themselves from new users and treat them as lesser beings, something that you do NOT want in any scenario. The best option is to have the tools for people to view or hide content they do not wish to see, and default to fallbacks if possible so they can still interact and socialize, instead of being outright removed or ignored.

[Teramanbr]

True, I get how "trust ranking" stuff may be a problem too. Then, getting users to be able to turn off certain features for unknown or unfriended users? I think being able to turn item audio or item video or item shaders off would be a good idea, just like portrayed in my example with VRChat. Of course, Resonite isn't VRChat and shouldn't be treated as such, nor should copy every feature, but I think basing off something that already exists is okay. TLDR: Trust ranking might not be okay, but on/off switches for certain stuff "not-friend" users can or can't do is definitely good. In VRChat's case, they used a trust ranking system, but I think even without a ranking, that feature might be useful. So my suggestion changes from the first example (with the whole image, including the trust stuff) to just this: Of course, it'd need more buttons, like one to block protoflux from "not-friend" users, but I think that's enough to convey the idea.

[JackTheFoxOtter]

If a system like this were to be implemented, relying on the relation between you and other users (eg. contacts, contacts+, non-contacts, like the session permissions currently already distinguish) would probably be the only fair way to go about it, and fit in better with the existing approaches.

That said, I still believe there are better solutions for many of those issues. You mention shaders for example (which right now is meaningless anyway due to the lack of custom shaders to begin with), but I think having a system that automatically detects heavy or potentially dangerous shaders and filters them out globally makes more sense than just blocking all custom shaders of unknown users, even those that wouldn't be a performance or safety concern.

In the same way there could be systems that filters out loud sound effect, flashing screen effects and so on. Those systems would allow more fine grained control, and be more reliable, because if you concern is for example photosensitivity, you would want all potentially flashing things to be muted, not just those of users you don't know.

A lot of those issues are more fine grained if you break them down, and having dedicated systems for each can lead to a better user experience, while minimizing potential overblocking. To approach those, it might be better to look at each problem in isolation, instead of grouping them all together as "unwanted content" in a single issue.

For the time being, keep in mind that you already have self moderation tools and the ability to block other users and / or their avatars should they be disruptive to your experience (but please still report them if they are breaking platform guidelines).

[Frooxius]

The problem here is trying applying some of the concepts to Resonite - it doesn't really map 1:1, so without knowing what kinds of problems you're encountering, it makes it difficult to figure out something actionable here.

Like I mentioned above, you can already turn someone's avatar off, that functionality exists. That implicitly turns a number of other things, but also not other stuff.

You mention turning off ProtoFlux, but this is one of the cases where it's unclear what does that actually mean? What end result do you expect to happen as part of "turning it off"? In a lot of cases, ProtoFlux isn't running on you at all, so turning it off will not do much.

There's a lot of potential ways to interpret "Turning off ProtoFlux", each one potentially solving a different problem - but because you have not outlined what problem you're trying to solve, I don't know which one should we even discuss here.

I'd really appreciate if we could focus on that instead as I requested in my post above, otherwise this issue won't be actionable in any way.

[Geenz]

In addition, I'm going to note a few things about shaders.

Measuring shader performance isn't particularly intuitive, and it will vary wildly from system to system. We could have some mechanisms locally to measure some shader throughput but this all comes at a cost.

Even if we have some AVS-side stuff to fuzz and measure shaders, this would only be a relative measure for performance to "whatever GPU" we have installed in the machines that would handle this.

Then there's the issue of fallbacks. We would have to assume that for someone's shader there's some kind of "sane" fallback path just in case the shader doesn't hit a specific performance criteria that the user is shooting for. The alternative is you don't see the user or content at all or we have a fallback in lieu of one specified by the content creator which likely won't be pretty.

[Frooxius]

Let's focus on figuring out the problem we're trying to solve with this first please.

Right now I don't know why do they want to block shaders in the first place. Could be for performance. Could be that they have unpleasant visual effects or perhaps even ones that could trigger epilepsy. Could be something else entirely.

Each of those problems has a different solution. But right now, it's unclear to me what the problem is, which makes the discussion frankly frustrating, because I don't know if it's even relevant or not and without knowing what problem it's trying to solve, it's hard to suggest possible courses of action.

[kulzae]

Each of those problems has a different solution. But right now, it's unclear to me what the problem is, which makes the discussion frankly frustrating, because I don't know if it's even relevant or not and without knowing what problem it's trying to solve, it's hard to suggest possible courses of action.

I think they might be referring to the tendency to "curate" your experience in VRC

What this means is instead of moving instances people tend to use the tools to remove anything they dont like.

They are asking for settings to be able to do this. someone playing loud sounds? turn off sounds. people spamming particles. turn those off as well. Some users will keep everything off unless they selectively want to see the person and tends to be the normal operation when playing on quest standalone.

Obviously resonite does not operate on the assumption that users are basically just decoration so not all of the functionality would apply

Some ideas from this could be:

Tag blacklisting and tagged content (already mentioned) https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1564

Asset blacklisting so particular sounds would not play for you or particular textures would not load based on UUID

low motion mode (already mentioned) https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/554

[Teramanbr]

In this case, I was referring to the unpleasant visual effects and that could trigger epilepsy part. The suggestion I'm trying to make is adding some setting to make users able to turn on or off certain features about the way certain items or avatars appear when spawned or used by an "unknown user", someone who's not a friend of the user.

About the protoflux part, I can't really explain myself too much further because I'm not really familiarized with it, but I mean it in a way that would more closely resemble to the "unallow javascripts" setting in a browser (please forgive me if that's not even close to how it works, I'm a bit of a newbie and thought that could help because of my very basic knowledge of other languages). I see how this could go wrong now that I checked a bit harder onto how Resonite works, so please, disregard that part if it makes no sense at all.