Why?
With Trans Haven having grown beyond 5,000 members, the staff have identified that the rate of trolls joining the server has grown exponentially. To help mitigate the issue, we have decided to implement a verification system.
Goals
- Keep the verification time below 5 minutes.
- Keep verification super simple and straightforward.
- Provide questions that are easy for a member of the LGBTQIA+ community (+ allies) and questioning individuals to answer, but difficult for trolls.
- Reduce incoming troll rate by 75%
Design
When a user initially joins the server, they will see a single channel with a message similar to the Contact Staff channel. This message will introduce the server in a short message, and provide a button to start verification.
Upon clicking this button, the user will be prompted with an ephemeral (i.e. only visible to them) interaction from Instar. The general flow will go in order with:
- A general introduction to the verification system, how to operate it, and prompt for language and accessibility preferences (future addition?)
- Question of relation to the transgender community
- A dedicated page indicating that the server is SFW, contains minors, and any NSFW content will be result in an immediate ban, and any messages of a sexual nature sent to minors will be reported to the NCMEC.
- A message indicating that the Q&A section is next. Should contain 5 questions, and the user must answer each question in under 60 seconds.
- Each question will be presented to the user, generally a random question out of 5 distinct categories. These categories will be designed to filter out people that shouldn't be on the server.
Observability
All verification attempts are logged in Cloudwatch for analytics and error root causing. Every verification workflow has a UUID associated with it. When a user is kicked or banned due to verification faults, they are given a report link that contains the UUID. This allows us to directly trace the user's report back to their verification attempt to see what failed and why.
Key Analytics
- % of individuals starting verification
- % of individuals who join and leave within 300 seconds (assumption is that they saw verification and left)
- % individuals who pass vs. fail
- Correct/incorrect rate per question (to identify ambiguous questions)
- The point in the verification that users leave
Questions
What happens if a user fails verification?
Two things are possible.
- If the user disagrees to the NSFW condition, they will be immediately banned.
- If a user fails to answer a question correctly, they will be kicked. Although they may return, the system will not allow them to restart verification until 15 minutes has elapsed. If the user fails verification 3 times in a row, they will be banned.
What happens if there is a problem with verification?
The user has the opportunity to report a faulty question or failed verification. Every kick/ban will contain a report link that contains a unique attempt ID. This ID is unique to each verification attempt and is used to trace data back to Cloudwatch for analysis. All verification workflows are logged to Cloudwatch.
What will happen to the current New Member/Member system?
This system will stay, as it is still possible for trolls to access the server despite this verification. However, we will relax some requirements as needed.
What will happen to existing Members and New Members?
Existing users already on the server will be grandfathered into the system, and will not have to verify. All new joins to the server will be required to verify.
Why?
With Trans Haven having grown beyond 5,000 members, the staff have identified that the rate of trolls joining the server has grown exponentially. To help mitigate the issue, we have decided to implement a verification system.
Goals
Design
When a user initially joins the server, they will see a single channel with a message similar to the Contact Staff channel. This message will introduce the server in a short message, and provide a button to start verification.
Upon clicking this button, the user will be prompted with an ephemeral (i.e. only visible to them) interaction from Instar. The general flow will go in order with:
Observability
All verification attempts are logged in Cloudwatch for analytics and error root causing. Every verification workflow has a UUID associated with it. When a user is kicked or banned due to verification faults, they are given a report link that contains the UUID. This allows us to directly trace the user's report back to their verification attempt to see what failed and why.
Key Analytics
Questions
What happens if a user fails verification?
Two things are possible.
What happens if there is a problem with verification?
The user has the opportunity to report a faulty question or failed verification. Every kick/ban will contain a report link that contains a unique attempt ID. This ID is unique to each verification attempt and is used to trace data back to Cloudwatch for analysis. All verification workflows are logged to Cloudwatch.
What will happen to the current New Member/Member system?
This system will stay, as it is still possible for trolls to access the server despite this verification. However, we will relax some requirements as needed.
What will happen to existing Members and New Members?
Existing users already on the server will be grandfathered into the system, and will not have to verify. All new joins to the server will be required to verify.