[MEGA TRACKER] ModCore v3: features, design, discussion

[Naamloos]

ModCore v3

This issue serves as a big process tracker for ModCore v3. At this moment, v3 is in development as a full rewrite of ModCore, which will get it's own Discord API implementation. As much as I love DSharpPlus, I have opted to write a new API wrapper specifically for ModCore, as DSharpPlus comes with some issues that make it really hard to use in a way that suits my plans for ModCore.

ModCore v3 will be developed in a manner that allows it to serve multiple shards from different processes without compromising useability whatsoever. Shards will operate fully independently, though share their database and cache provider. Because of this, dependency injection also plays a big role in ModCore v3.

Definition of Done

For ModCore v3 to be considered "done" and ready for release, the following things will have to be done:

• [x] Gateway, Rest Client, Rate Limiting, Event Handling
• [ ] Implementation of all events, entities, rest requests
• [ ] Implementation of higher-level internal frameworks for Slash Commands, Event Handling, Interactions API (components, modals).
• [ ] Database and Cache implementations
• [ ] Reimplementation of previously existing features from ModCore v2
• [ ] Implementation of new features.

When this entire list has been ticked off, ModCore v3 can be considered ready for deployment and the first steps towards publicly testing ModCore v3 will be made. At this time ModCore v2 and v3 will co-exist, where ModCore v2 will run on the original ModCore account, and ModCore v3 will exist on the ModCore β account until considered ready for more wide-spread adoption. More on this can be read under the "Transition to v3" header.

Features

Initially development will be focused on bringing back features that were present in ModCore v2. These will be tracked in the following list:

• [ ] Moderation Features (ban, kick, hackban, tempban, isolate, mass ban, offtopic, softban)
• [ ] Message Sniping: Returns last deleted/edited message from cache. Includes unsnipe command to wipe the last snipe data.
• [ ] Tag System: Allow users to create channel or server tags that can be retrieved via a command. Includes features for moderators to manage these.
• [ ] Status command (Gateway Ping, Http Ping, Server Count, Shard Count, Current Shard, Shard Uptime, Gateway Uptime, OS Version, Framework Version, ModCore Version)
• [ ] Reminder System (with some natural language processing)
• [ ] About Command (contains info about ModCore, credits to contributors, donate link, etc)
• [ ] Info commands (user info, guild info, channel info, role info, permissions info, user avatar link)
• [ ] Leveling System
• [ ] Nickname Request + Approval system
• [ ] Community Management Commands (Poll, Raffle, Coinflip)
• [ ] Starboard
• [ ] In-App configuration utility
• [ ] Chat Purge (purge messages by bots, with attachments, with images, by user, by regex, or without parameters)
• [ ] Simple command to make clickable /command
• [ ] Contact command (feedback, bug, feature request, complaint, other)
• [ ] Emoji / Sticker copier
• [ ] Display Pronouns (PronounDB) (TBD, Discord has in-app pronouns now.)
• [ ] Member States (restore nickname, roles on rejoin)
• [ ] Role management (Join role, Role menus, Self Roles)
• [ ] Welcomer (send a customized join / leave message when members join/leave)
• [ ] Configurable Logging features (Basically better audit logs, includes but isn't limited to: join/leave, message edit, message delete, nickname update, invite creation, avatar updates, role updates, moderator actions, audit logs, command execution)

As for new upcoming features, these will be listed below:

• [ ] Command te retrieve emoji or sticker urls
• [ ] Localization
• [ ] Moderation ticket system with in-server message reporting
• [ ] Quick-archive all threads in channel or forum
• [ ] Git issue linking on mention e.g. ##165 (per-channel, per-category, server-wide)
• [ ] Temporary voice channel system (user gets moved to a temp voice channel when joining a lobby)
• [ ] Voteban (can only be triggered by mods)
• [ ] Text highlights (similar to highlight bot)
• [ ] Twitch live notifications
• [ ] Forum auto archiver
• [ ] Image to GIF converter so a user can add images to their gif picker
• [ ] Channel / Server lock system
• [ ] Synchronize server icon with owner's avatar (good for personal servers)

Remember: feature requests for v3 are more than welcome in this thread!

Transition to v3

When v3 is "done" as defined under Definition of Done, v3 will be released as a public beta under the ModCore β account. This bot's database will be a temporary one, which will be wiped when v3 is being transferred to the full ModCore account. While v3 is in beta, v2 will stay in function.

As v3 gets released, it will get an entirely new database. This means server configs will most likely get lost. I will do my best to migrate the ModCore v2 database to the v3 bot, but I can't make any guarantees as the code base will not be compatible.

Discussion, requests, questions

Any questions regarding v3 are welcome in this thread. I will update the original post accordingly when decisions get made.

[InFTord]

Gateway, Rest Client, Rate Limiting, Event Handling

naam are you making a new lib for modcore

[Naamloos]

Gateway, Rest Client, Rate Limiting, Event Handling

naam are you making a new lib for modcore

yes: https://github.com/Naamloos/ModCore/blob/next/master/src/ModCore.Common.Discord.Gateway/Gateway.cs

Plus, quoting from the original post: As much as I love DSharpPlus, I have opted to write a new API wrapper specifically for ModCore, as DSharpPlus comes with some issues that make it really hard to use in a way that suits my plans for ModCore.

[dsezerpy]

by Localization you mean different languages? if so, how will the translation process go?

[Naamloos]

by Localization you mean different languages? if so, how will the translation process go?

Yep, Discord supports different languages for slash commands. We're able to define different names, descriptions, option names, etc for different languages.

The interaction event should contain a "locale" field that we can use to determine what language to respond in.

When no language can be determined, we obviously fall back to English, or whatever language a server admin has configured for their server.

I am not sure yet about the localization process. I'm considering using a service like Crowdin, but I'll most likely just accept language PRs from whoever feels like contributing. Here English and Dutch will be handled by myself.