Consider enabling more authoritiative restrictions on avatar styles at a room / server level

[djay]

Is your feature request related to a problem? Please describe. If you are running a more formal even where you want users interact and discuss things, it's distracting if people choose to be a crocodile or another less human like avatar.

Describe the solution you'd like In an ideal world a room owner could switch on a "real avatar mode" for a room and could force a custom avatar based on the users face and body/cloths selections like comes out of readyplayer.me. This is similar to how spatial.io works. Obviously this requires a lot technology to be integrated.

Describe alternatives you've considered

• Perhaps some mode where an owner can limit avatar selection to more human forms, or certain categories of avatars.
• maybe a way to force the use of readyplayer.me?

Additional context Based on feedback received in running a meetup in hubs https://github.com/mozilla/hubs/discussions/3718

┆Issue is synchronized with this Jira Task

[misslivirose]

The question of whether or not we should allow something like this through Hubs is an interesting one. I would actually posit that this is something that should be decided by the platform owner (e.g. hubs.mozilla.com, or an owner of a Hubs Cloud instance). Right now, the way that this can be accomplished is via the content import on Hubs Cloud, but it's not a completely authoritative approach.

There are a lot of implications around "forcing" an avatar style on someone, which is actually a pattern we've chosen to not take for Hubs. While, yes, it is a bit odd to have a carrot running around your triage meeting (guilty), it's also an intentional design choice of hubs.mozilla.com to allow that. We probably will not ever implement a system where someone is forced to upload a photo to generate an avatar, for privacy reasons on hubs.mozilla.com, though as an option I think that it can be helpful and we've thought about sprite/2D/gif avatars in the past with Hubs. (Though this is different than the suggestion of generating 3D avatars from a photo, admittedly)

I see two things off the top of my head that I'd point out while also noting that any kind of identity-focused changes like this would require a significant design pass:

1) We make it easier for Hubs Cloud admins to authoritatively "lock in" avatars or avatar editors for their own use. This feature would be one that ties into managing a larger range of customization options on the "platform" owner side.

2) We potentially consider a feature set where room owners could have some kind of guard on the types of avatars that they want to allow in a room. I think that this is likely outside the realm of what we'd do on hubs.mozilla.com but there may be some sort of future in-between offering between hubs.mozilla.com and Hubs Cloud where we could introduce this type of feature. The challenges here include things like: possibly needing to integrate with external services, the stage in the room entry flow that visitors would be asked to choose a new avatar from their existing ones, any kind of enforcement of "permitted" avatars, etc.

Additionally, putting this as a responsibility of the room owner offloads the responsibility of surfacing a diverse range of avatars to the room owner. A pattern we'd want to avoid is someone having an avatar that they generally use on hubs.mozilla.com, then going to a room and being asked to pick a new one and not finding one that they felt represented them. This is reduced if we're actually prompting users to create an avatar in a specific style, but that adds time to the room entry flow.

FWIW, I worked on a previous project that had an option like this available to server owners. Server owners were able to set a list of URLS of supported avatars, and when you arrived to that server, you'd be automatically changed into one. It was not highly utilized because in that particular community, people were very attached to their avatars and changing them automatically was felt as a bit of a 'faux pas'. IMO, I think this is significantly different for Hubs Cloud deployments, where this works because generally, you understand that you are on a different website, but for individual rooms, it seems like a pattern that could (I don't know if it would, necessarily) result in a negative experience on hubs.mozilla.com.

Lastly, I'll add that something I've observed works in a 3D space is having the room owner set out a gallery of preferred avatars near the room entry points. While this again, is not an authoritative approach to forcing avatar styles, it does seem to have promise as a prosocial behavioral pattern where the vibe of the room tends to be one where people want to fit in with what others are "wearing".

[jywarren]

I want to voice support for this or a similar feature for regular (non cloud) rooms and to highlight another use case. I have been hosting visits to a virtual reconstruction of a Chinese American neighborhood which was destroyed, and the visits serve as a kind of memorial to the people and stories of the place. So I have gently encouraged people to use a "minimal" avatar -- but I also acknowledge that this is a subjective idea (someone dressed as a flower or a bird might do so in a heartfelt sense of respect). In fact one of the avatars I suggest is a robin. Another is a stone.

This suggests a few things to me -

• one role of a featured set of avatars might be to "set a tone", even if people could still click a button like "see more options"
• the choice of restricting avatars might not be the same, but I do see a possibility of "minimal" avatars, something in muted colors or something
• many visitors I've hosted are confused by the tone of the "choose an avatar" step, which presents them with options that seem inappropriate
• many visitors I've hosted are not very familiar with the UI and having to choose an avatar is not familiar, even a barrier to entry
• I could imagine a strong default, even auto-assigning a default with no choice screen, but letting people choose their own without limits afterwards, which might be an interesting middle ground to not limiting choice but addressing some of the issues here

Thank you!