patrickklaeren/accord

A C# Discord bot with moderation, XP/guild participation and utilities

Hey there, the name's Patrick 👋

accord's Issues

Add reminder functionality

Allow users to send a message at a specified time, which will ping the user to remind them of something.

Commands:
/remind me {timespan} {message}
/remind list
/remind remove {id}

Embed color change

Currently the black embed color in my opinion looks very bad. I propose changing the embed color to the same shade of green as the icon, that would make it fit together well

Allow users to tune out of channels

Discord allows permissions on a per-channel, per-user basis. Allow users to tune out of channels via a command which adds a permission stipulating that person cannot view that channel.

Three commands:
channel hide {channel} - hides channel
channel show {channel} - shows channel
channel hidden - gets all hidden channels for the user

Calculate participation for users on set interval

The XP implementation needs to be removed and a set-interval calculation needs to happen in the background which will baseline every member that has spoken/sent a message since the last calculation to establish participation/rank in the guild.

?? question marks in place of emojis (unicode)

UserReminder is using text column should be changed to nvarchar

Event Organizer Functionality

Introduce a System where Administrators would register Events on the bot.
The ideal management system would be on the WebUI (which hasn't been built yet)

• The Bot will post a message on the #events-bulletin board with the
  Description, Name, Id, of the event, the presenters, and it will tag everybody on a specific role (ServerParticipation i.e)
• Then whoever wants to participate on this event will have the ability to type a slash command /event subscribe event-id [remindTime], Where the event-id will be a friendly name such as reactive-event
• There would be the possibility for a user to define a 'Remind xMinutes before event' timespan for customization, Default being something like '30mins'
• A TimeSpan before the event starts, the bot would create the event-voice-channel and the event event-text-channel

By default users besides The Staff Team and the Presenter should not be able to speak on the voice channels unless they have a question and they request for it.

About the administration side of things on how the staff team would register the event, i would strongly suggest not to use slash commands rather than simple prefixed ones because of the limitations slash commands have with their parameters.

On the WebUI (when it's built) There should be a page with Presenters / Name / Id fields and a Markdown editor to have an alternative on how to create the event.

• [Optional] Accord would monitor the participants on an event and could possibly award them with xp/roles or whatever as a bonus.
• [Optional] The presenter would get a special misc role, just as a "thank you" for his effort.

ModMail implementation

Tracking issue for ModMail implementation.

Conceptually this is called UserReports for Accord.

User join/leave logs need to include username in plaintext

The current implementation encapsulates the username as a clickable ping, but this will not display the actual username if the Discord client has not cached the name for that ID. This effectively makes join/leave logs unsearchable for a particular name. See image for an example.

Codeblocks mess up the /reminder list

When a user types
/remind me 1s ``` something
The formatting of
/reminder list
breaks

Strings needs to be sanitized.

Change status to be configurable

Store as run option and make configurable via command, status set

Refactor StaffSnowflake to be run option

Currently StaffSnowflake is stored as a static member in Constants. This should be a new run option, called AlertRoleIds, which show allow for several roles to be comma separated and for this to be (de)serialized.

Accord is failing to respond on a negative TimeSpan

On the Reminder feature if a user defines an invalid time span or a negative one, bot will not respond.

Allow users to add their own ranked Nitro booster role

When users have ranks above Nitro booster, they are not given the pink colour for boosting. Some prefer this colour. Allow a new command to have users with the Nitro booster role self-assign Ranked Nitro Booster. This is guild specific and should likely be a run option.

Two run options:
AllowRankedNitroBoosterRole
RankedNitroBoosterRoleId

Consider storing image hash in database

We do not store the image hash for a user's avatar in the database. This has the disadvantage of requiring an API call to the Guild endpoint whenever we want to display the avatar of a user.

Storing the hash would have several benefits:

• Reduced API call to Discord just for the hash
• Ability to provide audit logs when users change their avatars, check diff

Add barriers for potential risk users

We're referring to users that pose potential threats, as DM scam/spammers or raiders as "risky users" here on.

We are using the C# community Discord as a sample.

The current heuristics to analyse if a user is a risky user is based on a number of variables, such as account creation, join rate and avatar similarity to a known hash. It is my goal to reduce the number of attacks on genuine users of a Discord server by implementing a new validation barrier for users we deem risky based on account creation.

What we have observed is that the waves of botnet accounts join with common creation dates. The likelyhood is that we are being hit by two independent sources of accounts, whereas previously we had deemed this to be one source. Accounts are created within a range of 15 days of the current date. Once we have identified a range, on a certain date, these accounts tend to remain in that range of 1 to 2 days.

I.e. It is September 29th, an account range will start to become apparent within the prior 15 days. The earliest a batch of accounts will have been created is September 14th. A batch would have been created on September 16th-17th, which makes this a range we scan for.

With this knowledge, it is easy to implement a given validation scenario for new members with an account creation based on the rules observed.

Changes come in the form of gating the C# community, meaning access to the actual guild will be behind a Verified role. Every existing member of the guild will be grandfathered into this role. Every new member, upon join, will be run through a validation process.

Branches for validation will be limited to:

• If the account was created before 15 days from today, we deem the account to be "not at risk", and permit the Verified role automatically
• If the account was created inside of the 15 days from today, we deem the account to be "at risk", and do not permit the Verified role, kicking these users into a new verification channel. It is here where users will need to read and react to a post as an additional barrier to the guild. Reacting to the post with a pre-determined emoji will then grant that user the Verified role and thus gain them entry into the guild.

class AccountRiskRange {
	DateTime RiskDateTime { get; set; }
	DateTime UpperRiskDateTime { get; set; }
	DateTime LowerRiskDateTime { get; set; }
}

We lack sufficient evidence to stipulate if we can remove at risk account ranges, or if these need to persist forever.

It is useful here to note, time is on our side, as the botnet developers cannot work in the past. Anything we adopt today will work, with only future changes being able to further bypass this mechanism. It is my goal to remain as passive as possible, before becoming aggressive with heuristics and gating every single join.

Add documentation for development/contribution