BEFORE_MESSAGE_SHOW & BEFORE_GUILD_MEMBER_REMOVE events

[AngeloCore]

BEFORE_MESSAGE_SHOW

This event emits when a message is sent but is still not visible for the client (aka user)
So the bot can check if contains bad words/mentions someone or other things, and cancel the message

BEFORE_GUILD_MEMBER_REMOVE

This event emits before GUILD_MEMBER_REMOVE, so the bot still has mutal servers and can send leave message to the user

[VelvetToroyashi]

Even if this was remotely feasible to implement on a backend, and had more tangible use-cases, I'm not sure it's a great idea.

BEFORE_MESSAGE_SHOW

So probably the most obvious issue with this is the fact that it could and likely would induce some amount of latency for most users, given that the same message event has to be reserialized twice per every message. As well as having to double the payloads sent, you're now receiving double the payloads per message, which can absolutely destroy bandwidth at scale for little benefit. Gateway intents would alleviate this issue for basically anything that isn't a mod bot, but it's really just added complexity for a somewhat niche idea.

Furthermore, there's the issue of pitching this seemingly only for censorship. I personally can't see many practical use-cases for this.

BEFORE_GUILD_MEMBER_REMOVE

This one is also troublesome, imo. With every good bot on Discord, there's at least 3 others that people despise.

Especially when it comes to large and ubiquitous bots that shan't be named, there's already the issue of being absolutely bombarded with annoying join messages by 200 bots as soon as you even think about clicking the join button. GUILD_MEMBER_REMOVE does a fine enough job of telling a bot when a user leaves, and fwiw, this is essentially a repeat of the above issue; duplicating payloads for no real benefit.

If someone leaves, and you absolutely insist on annoying them, just chuck a message at the API and see if it fails. If this even is sent before GUILD_MEMBER_REMOVE, by the time you:

• Receive the payload
• Process the payload
• Act on the payload

The user is probably long gone, as far as the API is concerned. Furthermore, this even is (afaik) sent after the DELETE request is made from the user, so if that was the only server you shared, you're gonna be pretty SoL anyway, especially when you take into account API latency.

If a user wants to leave a server, they typically don't want to be contacted by some/most/all the people on that server, and especially not a bot. "We're sorry to see you go" messages aren't something I would wager many people want when they click "Leave Server".

Just throwing my two cents here; feel free to dog on me if you feel like I'm a babbling idiot I guess.