feature summary

It would be beneficial for IRC channels needing an invite bot for access management to have an on-site mechanism for enabling, retrieving, and resetting/assigning their IRC key to be used in conjunction with a simple invite bot.

on-site implementation

My idea of how this would work is in a very similar way to API/RSS/Pass-keys work. A page that displays whether your IRC Key/Access has been enabled for use (I would advise the default to be that this is a toggle to turn on or off (default)), When a user creates an account, you leave this disabled. When they decide they would like to join IRC, they would go to the same drop-down for Passkey, and choose IRC Key. Toggling to enable will generate a key, randomized should suffice, and write this to the userdb in an IRC key column associated with that user's ID. This key can then be assigned, if the user desires, to something more akin to a password - easier to type and remember.

This key is what will be used for the !invite <username> <irc-key> command sent to the bot.

It may also be prudent to have a sort of fallback method for inviting oneself to the IRC channel, an "Invite" button where you can click on the site, and be invited to the main tracker channel. To accomplish this, perhaps an execution of a script or something that could curl or open an HTTP request in the opposite direction, but this could vary from tracker to tracker in how the fallback would be employed, as some IRC networks may not have services to invoke the invitation on behalf of the user (chanserv/botserv), I'm not sure putting this in unit3d is feasible.

invite bot perspective

A third party bot can easily be set up and deployed anywhere with access to connect to IRC, where upon receiving an !invite command it could query an API endpoint on the tracker - let's call it /api/irc_auth.php - and send authorization via request headers with some form of adequate security TBD by more appropriate parties.

request query with params

/api/irc_auth.php?username=zakary&password=123456

This endpoint could accept some params in the URI, or JSON payload or whatever, containing the username provided by the user as well as the IRC key and determine if a lookup of these two paired produces a result (matching row).

responses from API

success

{
result: 200,
username: username,
user_id: 123456
}

failure for bad password

{
result: 401,
username: username,
user_id: 123456
}

no user found

{
result: 404,
username: undefined | null,
user_id: undefined | null
}

IRC not enabled

{
result: 405,
username: username,
user_id: 123456
}

IRC access revoked by staff

{
result: 410,
username: username,
user_id: 123456
}

These are merely suggestions of responses based on similar HTTP status codes, feel free to change them to whatever works best for you.

These responses should provide ample insight into any malicious usage, errors, and success.

If there is any aspect to this request or the plans for initial implementation in IRC that you have questions about, feel free to let me know.