Rules Dialog

[Geenz]

Hey everyone!

We've been considering adding a new rules dialog to sessions that session hosts (and admins, builders, and moderators) can add rules to.

We're posting the product plan for this feature below in an effort to collect some "last mile" feedback from the community prior to proceeding.

Rules Dialog Product Plan

The new rules dialog is enable session hosts to present users with rules of the session prior to joining the session.

Users can setup rules that users must accept in order to join the session, otherwise the user may decline the rules and not be permitted to join.

Terminology

For all intents and purposes, "Session Host" and "Session Admin" are assumed to be equal in standing for adding and modifying rules. Session moderator may be a role we include here, at equal standing to Admin inclusive of Builder per the standard permission set at time of writing. However, only the host may set age requirements for sessions when the session starts. Admin refers to someone who has the ability to change the rules of the session, and host may be used interchangeably in this document. However, areas where only the host has the correct permissions to execute an action will be noted as host-only.

Users are individuals who may connect to the session who are not either a host or admin.

Rules Dialog Features at a Glance

The new rules dialog includes the following features:

• A user editable "rules" dialog box that is presented to users when they attempt to join
• Permissions to edit the rules dialog
• A dialog box that is presented to users any time they attempt to join
• Notifications to users in a session that the rules have changed, prompting acceptance of changed rules
• An age gate that allows users to gate their session based upon prospective users' age

Guideline impact

Guidelines are not expected to change for this feature. Adult content will still be barred from public sessions with this feature. Guidelines may be found in the policies section on the Resonite website.

Rules Dialog Feature Mechanics

This section breaks down the specific mechanics of each feature of this functionality.

User Editable Rules Dialog Box

Session hosts, and admins of sessions, will be able to add rules to their session via the Session Settings item on their dash.

Upon navigating to the Session Settings, they will find a new button called "Rules" that when clicked will open a modal dialog wherein a session host or session admin may enter rules for the session.

Once the host or admin has committed a change to the rules, existing users will be prompted if they agree to the new rules. New users will be presented with the new rules prior to joining.

Connection considerations

If a user was in the process of joining the session while the rules were being changed, they will be re-prompted to accept the latest rules once they're in the session.

Reminder of Guidelines

In the editable session rules dialog, a reminder to users will be provided around the guidelines of the platform. This is to head off users attempting to use features to, for example, host public NSFW sessions which violate our adult content guidelines.

Rules Dialog Permissions

For the intents and purposes of this feature, we assume you have at minimum Session Moderator permissions to modify the rules. This is due to the following:

• Not all worlds allow users to start a session with more than moderator session permissions
• Session moderators (not platform moderators) have the ability to kick people from a session by default

These permissions may be moved around by an admin as needed for the session, for example, restricting the session permission to be Builder and higher.

Rules Dialog Box

Upon attempting to join the session, the user will be presented with a rules dialog box to which they must either accept the rules in order to join the session, or decline where they will be denied access to the session with an error to the effect of:
"Unable to join session: Rules not accepted"

Both actions will be logged in the user and host's logs. Accepting the rules will result in the specific rules that were presented being logged in addition.

Mid-session rule changes

Any time an admin or higher changes the rules mid-session, with users in the session, the users already in the session will be re-prompted. Any user who declines the rules will be immediately kicked from the session. They may rejoin the session if they accept the rules that are prompted upon rejoin.

Logging

Any time a user accepts the rules of a session, that action will be recorded only on the user and host's logs, including the specific rules that the user accepted. This applies to both joining the session, and subsquent updates to the rules that are accepted. Other users will not have this log

User Notifications

Once the host or admin has committed a change to the rules, existing users will be prompted if they agree to the new rules. They must then accept or reject the new rules. Acceptance will ensure continued connection to the session. Rejection will result in the user being kicked from the session

Grace periods

If a user is active, and is not presently set as AFK, they will have an adjustable grace period to review the new rules prior to being ejected from the session. This is to ensure that users are not "stragglers" for the old rules. We would set this minimum grace period to 5 minutes. This resets with every rule change. The rules dialog will not disappear until they make a choice, or leave the session.

Session Age Gates

Another feature that is included with this is the concept of session age gates.

Session age gates are designed to enable session hosts to require a minimum age to join the session.

Session age gates are enabled through the session rules dialog, as they are rules for entry to the session.

Available age gates

We will provide the following gates, with their justifications:

• All Ages
  • Given the nature of the platform, people can simply join sessions without an account. Sessions default to this for visibility, and to maintain existing existing functionality of the platform. This will be available in the client regardless of a specific universe' required minimum age. It is not an indicator of if we will lower the minimum age in the future.
• 13+
  • Although we do not presently allow anyone under 16 on the platform, this more intended for educational institutions that do allow people under the age of 16 in their private universe. Such as high schools. This will be available in the client regardless of a specific universe' required minimum age. It is not an indicator of if we will lower the minimum age in the future.
• 16+
  • The user must be 16 years of age or older. Although this would apply to our userbase by default, due to the unregistered user problem and the education customers, it makes sense to make this another gate. In addition, this gives us a better regulatory shield for territories, such as Australia, where content such as firearms is not permitted to people under a certain age.
• 18+
  • Enables a user to gate the session based upon their local legal requirements. For example, any gendered nipple exposure per local laws.
• 21+
  • Preferred for sessions where users are indulging in excessive drug or alcohol use, and to enable regulatory compliance with local laws for advertising alcohol and various legal recreational drugs.

When an age gate may be set

Age gates may only be set under one of two conditions:

• When a session is started
• If moderation must step in and change the age gate per guidelines at the time

How age requirements are met

Age requirements are met by the user having a date of birth on file, which they are required to provide upon registration. All session visibility and join checks are based upon the date of birth provided.

Presentation in the rules dialog

The rules dialog will display an automatically injected localized string at the top of the rules list.

Addressing shared headsets

The rules dialog will always note the specific age requirement for the session as a condition to join the session. This will be present on every rule change as well for already present users.

What happens when a user sends an underage user an invite

The user who sent the invite will see a regular invite under all circumstances. This is to protect user privacy around their age.

The receiving user will see one of the following with the specific conditions under which leading in:

• The receiving user meets the age requirement
  • The receiving user will see a normal session invitation
• The receiving user does not meet the age requirement
  • The receiving user will see a session invitation that has no thumbnail, and will simply state in their local language that it is a session that they do not meet the age requirement to join. The join button will not function in this state, as if it were a stale invitation.

This is to place the agency of revealing a user's age on the receiving user. They may inform the sending user that they are not of age, or they may simply decline to join.

Moderation Impact

With this set of features, we will be bolstering moderation tooling. To summarize:

• Moderation will be able to forcibly set a session age gate if necessary based upon the guideliens of the time
• Moderation will be able to set the specific keywords for a session title that may automatically hide the session

These have been deemed necessary for this feature set.

Edit

I have noticed some people on the Discord assuming that this is part of Age Verification. These are not the same things RE: age gates. Copy and pasted reasons why we're not touching age verification for a while at least below:

I have a very long list of laws I've researched here in the US alone that has made age verification as a topic a very legally complex one even though there's a good few copy-cat laws on the books in some state. Then you zoom out to places like the UK and Germany that makes this further complicated.

In some places with laws like that on the books, even here in the US such as Louisiana (which funnily enough has the tamest laws on the books, and also has a full on state sponsored service that takes care of the privacy burden for you - and no, not all states do this that have implemented similar laws such as Virginia), age estimation is another approach where we can make a good faith "guess" at if someone is 18 or older. For example, requiring specifically a post-paid credit card to be on file to go certain places. tl;dr, the laws around that subject is a massive amount of confusing patchwork that in some places could get us into criminal liability if we mess up if we start moving in that direction in the wrong way. So for now, it's not on the table until some dust settles at least.

I will also note that WE ARE NOT providing age gates as a means to defer liability in any way to us for making sure an entered DOB is correct. Y'all are hosting sessions on your own hardware, y'all get to make sure people in the session are 18 or older. You can make it a rule through the age gate, and that will effect its visibility to others depending on their age. But it is not our responsibility to check the accuracy of people's ages. That's yours.

[AmriaLeiah]

As mentioned in Discord, it may be a good idea to have a short timed delay before being able to accept the rules and join proper.
Maybe not that long, or perhaps keep a short record of how long it's been since the last time they joined so users that crash or disconnect unintentionally can rejoin without having to be forced to wait five seconds or longer?

[FlameSoulis]

I know this will sound dumb, but I'd also wager this should be server-enforced. For example, you could 'attempt' a connection to get the rules, then have an idling connection that just says, 'I'm here, just need to wait on the user.' This way, if someone uses a plug-in/mod to 'skip' the line, the server can throwdown and ultimately reject the connection.

EDIT: By server enforced, I don't mean that the server can bypass it or anything, or let the session host enter in 'til the heatdeath of the universe' to something. I just mean revalidation on the session host's side that the user MUST have read it and waited the correct time.

[AmriaLeiah]

It may also be beneficial to have a message on the user's side at the top of the rules dialog something along the lines of "These Session rules do NOT replace or supersede the Guidelines. Please follow the Guidelines at all times." With perhaps a hyperlink to the guidelines?

[NukiRaccoon]

Coming off a bit on the Discord...

I think this all should primarily be something set at the world-level, rather than session, as worlds can have or cater to content that is 18+ or should have a Content Warning. (And as someone who moderates on Fediverse, I think Content Warnings are an under-considered use of these "rules", as that's how we handle a lot of our content restriction)

To give examples of cases this system will be useful in...

Serenity has a bunch of rules about "energetic" behavior, which aren't shown until one loads enough of the world that the popup can appear. It might help them to have this sort of thing, especially so that people can know before they even join that this is a "relaxation" world.

I am working on a nightclub that will have an 18+ version and a 16+ version, though I don't plan to cater to anything that pushes beyond the limit of a public world. It would help to have the 18+ version default to 18+, and the 16+ version default to 16+, on top of the rules having content warnings.

A while back, there was drama over content in public worlds (you know what I'm talking about), and people began adding content warnings to them via popups when people entered, at least one of which would turn into a middle-finger if declined. This would've been way more effective if there was a built in system to prompt the user before they joined, which was part of why I made a feature request suggesting something like this back then.

[Geenz]

Why not all of the above?

Worlds can set minimum age requirements, sure. And that world could be just that - the minimum as intended by the author.

The session host can set anything above that. Because their requirements may also be different from the author.

Does that sound reasonable?

[Geenz]

Additionally this is intended to show up well before you join the world, and if you're already in the world you will be presented the rules dialog should the rules change during the session you are a part of. You do not get to join a world if you have not accepted the rules of that session with this mechanism, as outlined in the product plan posted above.

[NukiRaccoon]

I also think it should be possible to change the age-gating in the middle of a session, if for no other reason than because people will open sessions with it set incorrectly, as happens with the access-level of worlds. I'm also thinking of the times when a conversation has started that led to the host making the session private or contacts-only, because of things being said or images/items being shown, or making it public again after words were no longer being said and content was put away.

I'm not sure I see the issue with it being set on the fly though, so maybe you can elaborate on why it's only planned to be settable at session-creation?

[Geenz]

For version one, we will not support changing of age requirements mid-session. The reason is entirely for privacy of users who may not meet that age requirement.

Imagine that someone is trying to figure out if a user is 21 or not. If you'd like to do this by setting the age requirement mid-session, we'd need to kick anyone under the age of 21 from the session. Now let's say you wanted to be much more narrow with this - say under the age of 18. Set an All Ages or 16+ session, let people join, and when you have a sufficient amount of people (or someone you suspect to be of a certain age) just switch the age gate to something higher.

With the model proposed, it puts the agency on the user who does not meet a given age requirement to reveal their age. That's the point of how we have structured this. It reduces the capacity of targeting users for their age by trying to find out what their age is in a brute force method such as what I've described.

[epicEaston197]

Although this does make sense this completely kills a major feature that most people used the practice of switching the session to private then asking everyone if they're 18 without needing to restart the session is really a nice feature this will effectively kill it outright...

[TisFoolish]

I didn't see anywhere this being mentioned and the line "A dialog box that is presented to users any time they attempt to join" makes me think this hasn't been considered yet, I'd like to request the feature that the host and admins can enable a "Remember Me" setting, that way users don't have to agree to the same rules every single time they join. If there has been no changes to the rules since the last time they agreed it'd get very annoying very quickly.

[Geenz]

My point here is to err more on the side of caution. You may find it annoying, as may other users. But it generally ensures that the user has the ability to review (or re-review) rules they are agreeing to to enter a session. At some point I could see us maybe doing a "the rules have changed since you agreed to them" prompt at some point, but for version 1 this is not something we're going to ship.

[LeoCatsune]

Okay. Let's play this game then.

The host remembers what I agreed to. But my machine does not.

Say I'm a Jetsetter (which I am from time to time) or I just use multiple machines for a variety of reasons (which I do).

My machine may not remember what the rules are.

Wat do

If there's any sort of mismatch between the host rules and the cached rules, show the rules again.

As for your question of what if you don't remember accepting the rules, you could handle it like logins - remember up until (X) days since last visiting a session (per-machine!), and/or maybe have a short prompt saying "you've already agreed to these rules on [date/time], would you like to review them?" Without showing the whole dialogue. Additionally, have an way to review the current rules inside the session.

There are plenty of options that could be considered, from what I'm seeing here, and this is definitely an intriguing chain of conversation.

[Geenz]

We're still erring on the side of caution here. You'll be presented the rules on every session join for a myriad of reasons. One of which is ensuring a user always knows what they're getting into, and another being a paper trail of the rules that's always fresh. This part of the to be shipped functionality is not changing at this time for the sake of convenience.

[Amunak]

You should definitely make it very clear when joining a session that has changed its rules since the last time you accepted them. I know this means remembering the rules, but people will otherwise learn to click "accept" on everything especially for sessions they are familiar with and miss potentially critical changes.

I also feel like re-joining the same session withing a timeframe like 12 hours or so should not re-prompt unless the rules changed either. And I really hope you can review the current rules whenever on the session tab.

[FlameSoulis]

Given Geenz's explaination prior, I'm not sure that will be fully doable. That isn't to say it cannot be done (comparing hashes of accepted rules to current ones, observing date differences, etc.), but the other is that sessions always change unless it is headless that is running ad Infinium.
For rejoining a session, why the session is being rejoined could be many reasons, and some of which could be an attempt to skirt at acknowledging the rules. For example, if a user joins a session and is booted out but not banned, it could be due to rule-breaking. At that point, the user should still need to re-accept the rules. Likewise, if a user is kicked via network rules, this could have been done as a more advanced version of the kick.
It'll ultimately be a 'show it all the time' or rely on the system to always do its job and remember when a user confirms something. Given the beta nature of the system, the latter is prone to exploitation and errors, and so the former would be the safer choice until things are ironed out.

[shininghero]

Ideas for future iterations:

• Recap button: clicking this will will reopen the rules dialog to allow a user to double check things.
  • Possible locations:
    • Home screen? (Easy access, but may conflict with user added facets)
    • Session subscreen? (Somewhat nested, but would allow potentially checking rules without triggering a join request)
    • Non-menu in-world component? (Good for redundancy)

[shininghero]

• Matrix/table style form option?
  • Gives a visual style variant to contrast the usual checklist.
  • Could allow simple yes/no/limited listings on content types.

[Geenz]

What we may do for this "recap" is to make the rules button generally available for anyone in the session, but modifying the rules of the session will simply be disabled - this way you can check the rules at any time by going to the session tab, under settings clicking "Rules", and see the rules of the session there.

[epicEaston197]

Can I just mention there was no notification made for this discussion at all and I was completely unaware that this discussion even existed until I wanted to find the discussion on the settings rework would be nice if there was more publicity about this discussion so everyone can have their voices heard

[VirgilCore]

Easton there was a very clear announcemnt when this started.

[epicEaston197]

uhhhh
no...

[shiftyscales]

It wasn't presented in an announcement channel (it probably should have been)- but the announcement post can be seen here:

https://discord.com/channels/1040316820650991766/1154514007479287942/1214385958766514286

[shiftyscales]

It may be desirable if a user could in some form specify their session rules in multiple languages. Or at the least to add a 'copy' button to the rules dialogue to copy the rule text to the clipboard so it could be used with an external translation service to get an approximate understanding of the rules they are agreeing to before joining.

Otherwise this feature will likely implicitly region/language-lock some sessions, @Geenz.

[Banane9]

Hmmm - perhaps it could also be an option to have other "preset" rules such as the age-gating, which have built-in translations, to cover common points 🤔

Of course this would only be in addition to the free form text.

[Geenz]

@shiftyscales We do not presently have the ability to do this. This should be another feature.

[Chundelac]

I have a list of questions and edge cases, I will be thankful for a response to these:

1. Will sessions that are rules gated or age gated be highlighted in the session browser?
   a. If yes will the age gate be visible before rules are, or will they be visible at the same time.
   b. If the host is informed about the user declining rules, I think it is fair for the user to know there are rules beforehand to let them decide if they wish to be logged in case of declining.
2. What content will be allowed in the rules dialog box? (Formatting, colors, clickable URLs)
3. Are there limitations on the length of the rules?
   • If there is no length limitation combined with no "remember me option" and no highlighted changes it will make it possible for new rules to be easily hidden.
4. What will be logged in case of lost connection after rules are presented but before declining/accepting?
5. Will unregistered users or users under age gate be able to set an age limit?
   a. Can users under 18 set a session as 18+?
   b. Can an unregistered user set a session as 18+?
6. If moderation steps in and changes age gating:
   a. Will this action be logged on the host, admins and users?
   b. Will there be a reason included or a moderator who did the change?
   c. Will users get some sort of notification of this change?
   d. Will users who are under the age limit get kicked? This could reveal their age.
   e. Can moderation do such without being present in the session?
   f. Can moderation change age gating for private sessions?
7. "Moderation will be able to set the specific keywords for a session title that may automatically hide the session"
   • Will this be transparent to the session host? This sounds like shadowbanning if this is not transparent. Both the keyword and the reason for it.
8. How will this flow work for when session joining is initiated with flux?
   • If the rules are shown right away the users will be forced to either accept or decline, both generating a log on the host. This could be used to detect the age range of a user.
9. Will there be components/flux to detect if the session has rules or/and is age gated?
10. Will there be flux/components to get rules/age gate of the current sessions?
11. If rules are changed, will there be a log about who was the one changing rules? Will it be host only, admin only or users as well?
12. Is breaking rules in the rules dialog looked at differently from the point of view of moderation than a custom in world implemented rules?
13. Is there a way to provide different users with a different set of rules or exempt users from the rules?
14. Will there be options to provide localized rules?
15. With any of the actions that are logged, if they are logged on the host and client is there any way to verify their authenticity?
16. Will it be possible to restrict admins from modifying the rules? (only leaving the host the ability to modify them)
17. If a user is invited into a private session with rules, will declining the rules expire the invitation or is the user able to reunite using the same invite and accept the rules the second time.
18. Will dedicated servers have the ability to interact with this system:
    a. Set age limit on session startup
    b. Set rules on startup
    c. Modify rules of the session during runtime
19. How will this system interact with a custom join verifier?
    • Will it be required to accept the rules first before being introduced to the custom join verifier?
20. Will moderation/team members be able to bypass/interact with the rules in any way that other users are not able to?

[Geenz]

1. No.
2. Rich text
3. Version 1 will not have a way to get a delta of the rules. We do not have a limit on the length. You will be expected to read and understand the rules on every session join.
4. We always log acceptance of the rules prior to join. If you're unable to join after due to connection issues, it will still be logged where you accepted the rules - regardless of if you were able to successfully connect. Your connection to the host is also logged due to how connecting works.
5. You may set an age gate if you are registered up to the age on file. We cannot make any assumption about an unregistered user's age, so they will not be able to make use of this feature.
6. This is more a moderation policy question. Moderation sets the policy around notification of a session's age gate being adjusted manually as needed, and when to do it. Additionally, they set the policy around informing when a specific moderator has taken an action.
7. Moderation will set the policy around this. At present we do filter two keywords from session titles - 18+ and NSFW. This is for sessions set to public only.
8. Same deal. You always get a dialog presenting you with rules before the connection ever starts. If you are below the age required, you'll just be told that you do not meet the session or world's required age. No one else will be notified if you decline the rules to really tell (and this includes a failed age gate check) - it's on the user who was denied access to inform others or not.
9. No.
10. Not in Version 1.
11. We can add this to Version 1 along side of the standard rules logging.
12. This is a moderation policy question. You should ask moderation about this.
13. No. As a session host it's up to you to decide if you'd like to provide exemptions and under what terms.
14. Not in Version 1. This would require a more robust localization feature set than we presently have. We're not adding that with this feature due to the scope required.
15. We could add a sort of rule fingerprint to the rules that can be compared.
16. We could - however that would mean in the case of headlesses you'd have to be careful about setting up your rules in advance. Instead - consider using the built-in session permissions system (which rule setting will be a permission)
17. They can reattempt connection as many times as they like. We leave the session host to decide if they want to revoke an invitation or not for private sessions.
18. That's the idea.
19. You never connect to the session unless you accept the rules. Join verifiers won't have enough information to make a determination if someone is allowed on the session or not.
20. No. We do not have the ability to bypass session settings today, nor do we intend to introduce such functionality beyond the bare minimum that is needed for moderation of the platform as a whole such as bumping the sessions age gate, hiding the session, or setting specific keywords that sessions cannot be listed under. You can send inquiries to moderation via https://moderation.resonite.com/