User Validation and User Management - Process Integration starting from Invite

Hello wonderful Discord dev team,

I have a great love of your platform, but there is a technical flaw that is absolutely interrupting my ability to advocate for using it where I work. I really want to overcome this, and Jessie James suggested I head here to upvote or voice my thoughts. 

I found one thread about bans that brushed on my issue. I upvoted it, but realized it didn't really give you the method to do what users were asking. Nor did it fully fix my real issue with all the grace I know is possible, and in a way that leaves Discord's product stronger.

Call it professional pride, but I hate asking for something without at least suggesting a road-map to make it worthwhile to providing it. I know I'm not in your line of work and the proposals I make might not even be as useful as hair on a whale, but I'm not entirely clueless, so here goes.

The Situation

I've got a day job, and then I've got the job I love doing. I've worked with the gaming community on my campus as their official advisor since the community was founded in 2013. We have had roughly 600 members over the past seven years hop on our various discords, official and unofficial. We've spun up multiple official discords in the past, and currently our key discord is for our esports program.

All of our students agree that discord is best in class for their interests, and I've been happy to facilitate that. We've had some wrinkles, though. Students who are pretty toxic and had to be banned. The only issue is that when we ban then, suddenly we black out our discord to entire dorms on our campus.

We missed this issue for a long time, but recently we were able to pinpoint it. Now that we see what the issue is, what to do?

I reached out to Discord support (Jessie James was very helpful) and they funneled me here. I'm taking a stab at using my clumsy, hamfisted skill set to try to get you where I desperately hope is achievable.

Before my student community grows any larger and spin up any more discords over the bans situation.

Seriously. This is getting hard to manage.

The Current Flow (New User to B&)

1. Invite Object is used to join the Guild/Channel.
2. User must pass the moderation check (We currently verify)
3. User_verified is checked
4. User can interact on the guild
5. User jungles when they're supposed to be mid-lane*
6. We ban the user
7. Loss of service to our dorms
8. We unban the user
9. Restored service and one of them turns out to have been the banned user in disguise a few weeks later
10. Rinse, repeat

*We haven't banned anyone for that, even if it is a cardinal sin. The things we do ban for are pretty bad though.

Mind the Gaps

Gap 1: How might we give a more robust mitigation of bad actors?

Situation 1: The server moderation check looks for user variables that the user brings with them to the server. User_verified is tied to the user, a user has it or they don't. Same as user_mfa.

While fooling mfa might be extremely hard, the ultimate goal here is to ensure the right people can access the server and the ones who misbehave get kicked out. What is the alternative design solution?

Proposal 1: Invite Objects are currently very straight forward. Just seven variables, most of which are just pathing. In 90% of use scenarios, that is fine, but what if we picked them up a notch?

Let's add in one more required field for Invite Objects, Invite_Restriction. In the null setting there is none, and an invite performs the exact process it does now. If Invite_Restriction is missing, treat as if it were null. Instant backwards compatibility, nobody has to redo invites and the 90% of discord that doesn't care is unmarred.

But then, let's give the Invite__Restriction='Yes' a twirl. Let's pair that with two more variables, Invite_Restriction_Type='Email' and Invite_Restriction_String='@discordapp.com'.

We've just moved the validation process into the guild(server) invite itself. By telling the user to validate before they even see the guild, we're able to create guilds that are unique to communities. It could be a company, like Discord, or a school, like where I oversee my students. You could even set this up to take a list variable, permitting users validating against any matching email server to join.

Gap 2 (Updated): Checking a user's email and reporting it to a server is breach of security. How to check emails?

Situation 2: None of the user's variables are currently designed to be guild(server) specific until they've joined. A user being linked to a guild simply doesn't exist in the system as it currently is, guilds instead link to users. From the guild_owner_id field all the way to the audit log.

Further, a user can't consent to giving their email to validate against if they haven't already somehow joined a server.

Proposal 2: Provide custom validation on a user. Seems obvious at first blush, but how does this fit in the process while not violating data security?

It still happens after they join the guild, but before they're able to interact with the guild.

We create an in-between status, user_validation_pending. While in that state, they have a button with a discord chosen symbol on it in their sidebar, where the guild would normally be. Clicking it tells them that to join the server, they must go through a server-specific email validation process. This is an opt-in, a consent step, that means their data is only given if they choose to give it.

If they consent, they must then enter a valid email for the validation check. Click, be sent confirmation email, click the generated link sent by email to the email provided. Viola, they're in and validated for the server.

This is essentially borrowing the email validation already in place, but has it performed on the guild's behalf instead of the user's. The guild stores the updated validation variables on the guild itself, referencing the user as it would for any other flags. This is instead of the user object itself, because the information does not carry to any other servers.

Gap 3: They leave before we ban them. Now what?

Situation 3 (Updated):  The ban function pulls IP data to enforce the ban across discord accounts, which isn't what we're after here. There is also no way to punch user_id in unless we build some sort of script and code our way around Discord as designed.

Proposal 3: Enhance the Audit Log to include joins and quits, store the critical variables that bans need within the audit log on user_quit events.

This would be two additional flags under action_type. For the sake of audit logs not becoming spammy, you could apply a server toggle (check box) for whether a server tracks this at all.

In the same way a ban can be removed while a user is no longer on the server, allow a ban to be placed after a user_quit. Use the stored pairing of user information (ID, Verified Email, IP Data) in the user_quit on the audit log to do so.

Where to integrate the option? As a click choice on where someone left in the Audit Log, as the needed user_id and other variables would be stored there. Once accessed, copy to the ban log as normal.

GET /guilds/{guild.id}/audit-logs already returns the user_id, so it is already being stored and server owner accessible. This shouldn't be a new security issue.

Gap 4: This still doesn't fix IP bans.

Situation 4: No, no it doesn't. It does give the information we need to the audit log, but if the IP ban remains linked to user bans, well, biscuits. All that work for nothing.

Proposal 4: When banning a person, have a checkbox toggle of whether to include an IP ban with the user_id ban. For guilds with the custom validation above enabled? Allow that to be a ban toggle as well, since they're expected to be unique.

The Proposed Flow (New User to Still B&)

1. Invite Object is used to join the Guild/Channel.
2. User must pass the moderation check (new invite validation)
3. User_email is checked against guild_invite_restriction_string, user_verified is checked
4. If user fails, user then enters pending state and do guild-linked validation process.
5. User;s successful join and user's validated email are stored in server log
6. User can interact on the guild
7. User jungles when they're supposed to be mid-lane*
8. We ban the user's ID (and verified email) but not IP
9. User rages but can't get back onto the server even if they make a new account
10. Server is peaceful. My blood pressure is reduced.

*Still haven't banned for this but it is looking more valid on second pass

The TL;DR

Halp Halp Students Are Doin' SHENANIGANS ON MAH DISCORD and I can't ban 'em or I ban ALL my students!

If you fix this issue, you'll make me so very happy.

You'll also make it so any company, school, or random group with an email server can setup an internally validated server through discord. Wasn't that Slack's last competitive advantage? 

No more having to use IP bans, either. Unless you want to.

Disclaimer that I'm in BI and Data Science by trade, not a software developer. I accept the rolled up newspaper of justice if I have given bad design advice.

Update 2/2/2020: Thank you to Lillious for feedback and corrections on my post.