Recently I've been getting unexpected 429s when executing webhooks at the limit, following the headers appropriately. When these happen, the previous header contains information that causes my application to expect it still has requests left (e.g. X-RateLimit-Remaining: 2), and then the very next request will return an error 429 with Retry-After: 43323 or some similar value typically between 4

While the lib doesn't currently support voice, it would still be proper to handle voice state updates. The logic to do so should be here, and the docs for it are here.

The voice server update event should also probably be implemented. A

I'm not sure how you would like to handle this, but there should be some way to use message purging without it leaking from private channels to public.

📢 Suggestion proposed by Profxy (246708789930229761)

What is the title of your suggestion?
what our costumers say

Explain your suggestion more accurately (It's best to give as much information as possible, so that we can implement the suggestion better)
the section "what our costumers say" on the first page of the homepage shouldn't be translated. It's better if they stay in the origin

Client.edit_channel/2 does not document permission_overwrites as an accepted argument, even though it works as expected. It might also be beneficial to add some validation to this argument, since failing to provide all attributes of an %OverWrite{} appears to cause Discord to ignore the request.

Sometimes there can be multiple ducks around at one moment. Right now they queue for being affected by fired shots, which generally works well. But the exception should be the fleeing behavior.

Enhancement Suggestion

Description

We should make it so the $help and $commands is one command instead of two.

• Rewrite help command
• Add $commands and $cmds as an alias to $help
• Sort commands by category, ie. $help moderation => show moderation commands
• Continue to support inline documentati