Thoughts on coding custom Discord server entry gateways

Many Discord servers ask new incoming users to agree that they've read and
understand the site rules.  This is often done with a simple check-box role
assignment, handled by a "bot" that watches for people to click a reaction.
The problem is that any rando with an invite can come into the server, click
the box, and then wreak havoc before getting kicked off.  This is often what
happens during "raids", and they can be super-annoying.

For better protection within a user community, a more secure access "gate"
can be built using a custom bot function, and require that the incoming user
have some piece of knowledge that was given to them out-of-band that they
present before being allowed full participation.  For example, a signup token
or string that was emailed to them by an event management staff or the like.
This could be as simple as having a shared entry password that everyone must
type into an accessible channel, or perhaps a freeform sentence indicating
that they accept the rules, or even more complex functions where every user
has a unique token and has to also supply more information about themselves.

Many people already have their own Discord accounts which they would use to
interact with the new server; there is no need or justification for forcing
creation of a new account just for this one purpose.  To aid in tracking down
any problems, a solid mapping between Discord users and who they really are is
desireable, which will usually involve an email address as also present in an
event's registration system.  Requiring that identifying piece to be part of
what gets typed or pasted in allows the mapping to be made.  Server admins
cannot learn the underlying email address of any Discord user, for the obvious
privacy reasons.  But within certain communities where such things are already
known, asking for that same email address to access and correlate their own
Discord setup is harmless enough.

The "incoming" channel should have these attributes:

   @everyone can see it and send messages
   Slow-mode should be enabled, perhaps 10 seconds or so
   It should be the top channel in the server's list
   A permanent, unlimited-uses invite should be matched to the channel
   Visibility should be DENIED to the granted "member" or "participant" role
   A suitable bot must be able to watch and manage it, and grant roles

That way, there is ONE invite to the server, forever, such that participation
info in event websites and literature don't need to be changed thereafter.
The real barrier to random meddling becomes the custom token instead.

There are two options for "view history" message visibility in this channel:

   @everyone can read history: you can leave a message with instructions
   @everyone cannot read: less risk of others' stray attempts being visible

A proper bot function will immediately delete posted messages whether they
are right or wrong, so that there's very little chance of one user seeing
another user's input.

In addition, there should be a hidden channel where the bot-function logs
its activity and the user input, which is where the mappings get recorded.
It is easy to later search for Discord users or emails and whatever else
gets logged if needed.

A bot with good programmed extensibility is desired, such as YAGPDB, which has
a fairly full "templating" language with decent string handling and a rich
regular-expression engine.  A simple example custom command could be written
thusly -- the trigger could be a static "joe sent me" type password, which
is a low security bar but still better than a checkbox.  A tighter but more
"random looking" one could be a variable regex trigger that also looks for
something in the form of a typical email address,  "..*@..*\."  or the like.

   {{deleteTrigger 0}}
   {{$p := (joinStr " " .Message.Content "entered as" .User.String)}}
   {{sendMessageNoEscape "audit" $p}}
   {{addRoleName "Member"}}
   {{sendDM "**Welcome to XxxCon!**  You should be able to see all the event channels now."}}

This bot function logs whatever the user typed in along with their Discord ID,
gives them a suitable "Member" role so they can see the rest of the server,
and sends them a direct message welcoming them to the event.  It gets set up
as part of a group that is only valid in the "gateway" channel, no others.

A second custom-command trigger should be included in the same group, which
matches on anything typed in and simply deletes the message after a short
delay.  This keeps the sign-in channel clear of all the incoming users'
attempts to get in, whether they succeeded or not, as well as random spam.

Obviously this sort of thing could still be spoofed, but consider that the
legitimate incoming users would know that they need to type *something* in a
particular format, and passing randoms would not.  More sophisticated bot
functions can be written for even tighter syntax checking, matching parts
of strings to other parts, etc.  We don't get full cryptographic functions
in bot programming, but there plenty of creative ways to apply more obscurity.
And in cases like this, security through obscurity *is* generally sufficient.

As a simple example, here's the essential "algorithm" of the gateway to a
recent event that I helped with.  Incoming new users would possess a unique
token string, and be instructed to paste it into the first channel they'd see.
The token was in the format

   reg  s0mETh1nG  their-email@domain.net

and the check was a set of regular-expression matches on the first character
of the email address.  The alphabet + digits was broken into six sections, and
each range mapped to a small subset of three specific [and case-sensitive!]
characters in one particular position within the "s0mETh1nG" password.  That
alone yields less than a 1 in 20 chance of getting it right.  One or two other
characters of the password had to match another small set, just as a secondary
check.  That was it.  The rest of the password was random and ignored.  These
tokens were generated by a script on the registration system and emailed out to
the attendees, who would then use them to access the Discord.  Even if someone
knew the general method, they'd still have a very slim chance of guessing
their way in, and trying to compare notes with other attendees would reveal
very little.

You can get far fancier than this, but the sophistication is somewhat limited
by the custom-coding capability of a given public Discord bots and how much
coding/testing one wants to put in.  Developing one's own standalone bot
could go even father and make the sky the limit, but such efforts are not for
everyone, and for the level of stakes usually in play around a Discord server,
not worth the time.

_H*  211027