Domain "Trusted" Content / Accounts / Marketplace


#1

Something that came to mind while working on my new avatar:

Since we now have an avatar and clothing/ clothing system that works across multiple 3D suites, I started thinking of the consequences of Having general social content mixing in with educational content spaces, especially if word starts getting out further.

One of the things that come to mind is individuals with unsavory attachments or avatars running into educational spaces. There should be an away for domain holders hosting educational spaces to limit avatars and their attachments only display approved content (from domain spaces).

Separately, if an account is “trusted” by the domain they should be able to display what ever they have on, regardless of the trusted asset sources.

Avatars linked from an untrusted source will not be transmitted to others, so that the domain defines them as the default that is set in the domain.

While all untrusted attachments simply aren´t transmitted by the domain to others. Animations are allowed to load as is.

They will locally however see what they are wearing, but everyone else sees the default (if they are a trusted user, or if they have avatars from other sources) unless in a domain that allows such.

Similarly, if the object was from the marketplace, theyd be automatically trusted objects (that is as long as general rating).

This could be expanded on with an ability to block avatars from rendering in public spaces that trust every asset, and scripts (to disallow mass teleport examples, Script wise editing of objects (You can override edit to edit anything regardless of domain permisisons) etc).


#2

Now i understand some logic of project sansar, because that is technical a bit the same what you say.

Some domains only let you choice from a premae list of avatars you choice from and replace your avatar. Other domains you can visit with every type of avatar. For schools this setup is indeed not bad and the only way to secure it.

One things is for sure, soem content will always sneak intom places where you not want it. But then admin can remove it easy.

You want to day that admins can flag content on the marketplace as trusted for there domain ? Because rating can be abused, and also can be blocked like LL doing now to sometimes with wrong ratings.

Blocking untrusted attachments, that means hud’s people need to use get blocked too ? that would be bad.


#3

No,

I meant that domain them selves can whitelist/blacklist and do the decision of what content can be used within the domain: By default this could be objects from the marketplace and ones from the ATP. The domain owner / moderator can switch this off if they so want, or add specific accounts to a trusted rating that allows for them to rez/use what ever script or avatar or attachment they want.

It should be domain owner right to allow for specific content if they so wish. Similar functionality should be available in client. If turned on, By default, domains would have all the marketplace items and ATP ones whitelisted, but the list can be modified:

It wouldn’t also replace your avatar, instead it would just change what others perceive your avatar and hiding attachments that are not approved, unless the objects in question are from trusted sources of the domains choosing:
You will still see your self as is, but others do not. That is unless you are trusted by that domain (Whitelisted).

Since entity and client scripts are always locally loaded, It would not effect you: This means HUDs and the sort would always be visible to you, as you are the one loading them within the client.

Generally speaking, this would mitigate the damage done in the following situations:

  • Griefer going into a K13 Domain as a talking penis with balls for legs. Or similar.
  • User with Permission to Edit has a malware script that spawns an entity with a new malware script. Users that load this script will run the script locally. The script creates a new instance of the script. When they go to another domain that they have edit rights in, the cycle begins again.
  • User with Permission to edit loads a custom script that spawn an entity with a script that attaches another script to another client. When the client loads that script, it will be a local script, User can control the other Users avatar via the Messaging system (Force teleport, force play animation, force move, etc, etc You get the drift).
  • User cannot load modified scripts of entities they have attached (weaponry, etc)

#4

I may not be getting HF entirely, but from my view, the more domain-level control the better. From perspective of HF, think it would promote a wider range of possible domain implementations and thus accelerate adoption.