#github-notifications

1 messages · Page 22 of 1

chilly siloBOT
#

@msciotti we might want to talk about this :'D

  • For the time being, the API is definitely going to support both JSON int and strings, since we just cast it to a number internally.
  • Nevertheless, our official clients will only ever send strings.
  • It is entirely up to you whether or not we want to publicly deprecate ints here.

My 2 cents is maybe keep ints here and deprecate in the future if we have to? /shrug Or say that we prefer strings here?

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Trust me, I'm familar with the discord api and the (API) ToS.
Wasn't ever implying that you weren't, so apologies if I gave that impression, I realise I probably worded that awfully, sorry about that!

Probably worth making a new issue like Sinister said though. The best solution for now if logging is just the issue (and not the concern of the 403 hard limit) would be to just handle that exception as an edge case until a better solution can be agreed if possible :)

chilly siloBOT
chilly siloBOT
#

Fixed several bits of broken formatting, a bunch of NBSP characters
that are not used elsewhere, and fixed a few broken code examples
(missing semi-colons, et cetera).

Added a table describing the example of the Rich Presence activity
example, since it is not clear to users who have impaired sight as to
how this may look.

This is added in response to
https://github.com/discord/discord-api-docs/pull/2097#discussion_r495313517
on PR #2097 by Mason.

Put this up to go into the feat...

chilly siloBOT
#

Ses kanallarına girerken, hoparlör sürekli açılıp kapandıktan bir süre sonra hoparlör kapanıyor gibi görünüyor. Ancak kullanıcının hoparlörü açık olduğu için odadaki sesleri duyabilir. Başka bir odaya geçen ve özel odaya bir böcekle giren kişiler özel konuşmaları duyabilir. Bu çözülmesi gereken bir sorundur.

bug

chilly siloBOT
#

^^ v7 too.

Technically v7 isn't released as they have said. The whole point of it was for it to be a development preview, so I don't know if there is any expectation that they will provide a deprecation period for undocumented behavior.

They'll probably do what they do with v6, but there isn't technically any reason to be using v7 other than for testing (so not in a production environment). I think there is just the unfortunate issue that a number of libraries made the choic...

chilly siloBOT
#

Many libraries use REST v7 but Gateway v6, I don't know any library that uses Gateway v7.

One thing I've noticed, however, is that MessageCreate events seem to be missing for DMs.

The library is probably dropping it because the channel is not cached because CHANNEL_CREATE didn't fire, you would have to update it to not require the channel to be cached

I can confirm this, I don't have an issue with DMs being missed.

chilly siloBOT
#

I'm not a fan of this PR for a few reasons.

  1. This adds another link to maintain that can potentially die.
  2. Project READMEs will already maintain their support invites and won't have to wait for Discord to accept a PR (look at how many PRs have gotten accepted over the last 90 days here -- it'll take forever).
  3. There's already a link to DAPI which encompasses most of these libraries anyway.
#

I second @Rapptz's statement. Repositories are linked, and most of them display an invite link at the top of the repository. Failing that, users can go to or through Discord API server.

The docs already had instances of falling out of sync with reality for this particular subject (dead libraries being still listed) in the past, which means this change has potential to cause confusion in the future.

#

It's easier for people to find the link to any library's support server/channel if they're all listed here in the official library list, instead of going around to library GitHub readmes and websites trying to find a badge or link which may not even be there.

Also, IMO it's better for people to go to the library's official server than a DAPI channel for it, as they have multiple channels and probably have more people with knowledge about the library, and many libraries don't even have DAPI...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description

CHANNEL_LIST_UPDATE would contain either an array or object mapping channel IDs to their corresponding position when channels are moved in the list, depending on how the Discord client currently holds channel information.

Why This is Needed

Currently, if you move a channel in a big guild, the gateway spams CHANNEL_UPDATE events for all channels in-between channel with position 0 and the channel position of the channel being moved. This doesn't sound like an issu...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

hello discord, I am a user and I noticed two bugs in the call by cell phone, starting with a bug that when you are in a call and changes the other call is going in and out, but it can happen without you being connected, to another bug tbm it is after a while on the call you don't hear anything and you need to get in and out, the same thing with the old bug that was having the robotic voice ... anyway these bugs don't happen so often, but it still irritates me a lot and to my friends who play ...

chilly siloBOT
chilly siloBOT
#

Description

  • Endpoint to fetch a user by Name#Tag (no presence data included)
  • Endpoint to search a user by name, nickname, name#tag when sharing a guild.

Why This is Needed

Currently searching a user which share a server with an user is unnecessary hard. You need to fetch all users in order to convert User#Name -> ID. Especially with the new restrictions and intents it become harder.

Alternatives Considered

I couldn't find an alternative way to solve this problem.

**Addi...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Hi guys, i try to make autorization by discrord, buy i have trouble with toket.
I not recieved token.

[code]
$chB = curl_init();
$post_opts = array(
'client_id' => '760412233565077514',
'client_secret' => 'FdZK5nVnvL0AOD1RZ58LOZSK0DwcCpjF',
'code' => $_GET['code'],
'redirect_uri' => 'http://127.0.0.1/',
'grant_type' => 'authorization_code',
);

$c_opts = array(
	CURLOPT_URL     =>  $token_url,
	CURLOPT_POST    =>  true,
	CURLOPT_RETURNTRA...
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

It seems that suppressing embeds on a message that contains a mention does ping in certain circumstances.

We have managed to reproduce the ping with these steps:

  • Person A using Android has their app open and is not looking at channel X in server Y (they are instead looking at another channel in another server)
  • Person B using desktop posts a message that contains "@​everyone" and a link to image such as "@​everyone (sorry for the ping) https://i.imgur.com/ECaZgF2.png" to channel X o...
chilly siloBOT
#

Hi, since this is not an issue with the docs nor the API, and it is not a feature request either, this is the wrong place to ask such question, instead try asking in DAPI, or reading the docs. This place is to make suggestions/issues about the Discord docs, not asking random questions.

Also make sure to not leak your secrets the next time you ask!

Good luck.

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

This is regarding the bug where the wrong port is sent on voice endpoints, leading to users who do not realise the documentation and API give the wrong details to receive confusing errors.

Original issue this was mentioned in was closed, and I can't seem to find anything else referring to this with updates available, so was wondering if this is likely to be fixed, and if so, when.

Also would like to know what impact this will have on any consumers currently having to use string manipul...

chilly siloBOT
chilly siloBOT
#

API support for inline replies! Be mindful of the different types between v6 and v8. We did this so as to not make breaking changes in v6.

While a new type is generally not a breaking change, in this case, not handling the new type would mean missing out on a lot of messages in chat for things like moderation bots, and we didn't want to break that.

v8 is still new and not default yet, so we felt comfortable using a new type there.

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

What does a reply look like on v6? Are the fields just missing or does it use the old Replying to x from y / Replying to y format?

The v6 equivalent of inline-reply is afaik the quote. From what I gathered is the inline-reply just a new and fancy version of the "Quote message" feature Discord offers.
So the v6 equivalent would be

> User Message
@UserMention
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

We have begun getting a event on the following form, is this an event that will be documented?

{
  "t": "INTEGRATION_UPDATE",
  "s": 16435,
  "op": 0,
  "d": {
    "user": {
      "username": "Foo Bar",
      "public_flags": 0,
      "id": "1234",
      "discriminator": "1337",
      "avatar": "somehash"
    },
    "type": "youtube",
    "syncing": false,
    "synced_at": "2020-10-02T22:08:19.042000+00:00",
    "subscriber_count": 3,
    "role_id": "2341",
    "revo...
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Is it necessary to say that referenced_message is not guaranteed on MESSAGE_UPDATE and MESSAGE_DELETE? They both already make no guarantees except for id and channel_id.

Clearly defining what is provided on those events would be nice, purely because it is pointless if you don't have any behavioural guarantee of when they will or will not appear, especially if that differs to what you would expect. It probably matters more to library devs than to people just using the API for ...

chilly siloBOT
#

Is this expected to be used as part of a work around for the fact that the results of the get guild integrations endpoint are potentially completely arbitrary, incomplete and unpredictable if more than 50 integrations are present?

This was brought up in https://github.com/discord/discord-api-docs/issues/1990 but the issue was marked as too heated and closed without any helpful solution.

Reason I ask is I want to make sure there isn't any "surprising" behaviour that should be expected o...

chilly siloBOT
#

We have just discovered that the role create endpoint now has a bucketed rate limit of two days.

image

It would be sensible to document that these rate limits can be of the magnitude of several days in some case so that it is clear to the developer that they may need to account for these cases. This will prevent developers spending ages wondering why their bots using library X someti...

chilly siloBOT
#

Hello, I've recently discovered the undocumented encryption option aead_aes256_gcm besides xsalsa20_poly1305_lite, xsalsa20_poly1305_suffix, xsalsa20_poly1305. Since my library language has managed support of it I would like to use aead_aes256_gcm for voice encryption as it removes a dependency (libsodium) from my library.

Is the encryption aead_aes256_gcm considered for usage of bots, since it is not documented by the API docs?
And if so, how long would it be supported? And ho...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description
For non-pinging mentions such as mentions in embeds and mentions suppressed with allowed_mentions, they are rendered properly when the user is cached, but otherwise the client just shows the `` format or @invalid-user. This is because non-pinging mentions do not include the user data in the mentions array for the message. On the Android app, it seems to always show @invalid-user for mentions suppressed with allowed_mentions, not even attempting to resolve from cache...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

This isn't needed. Just look at all members with the boost role. It's harder but it's doable.

Even though the role tag exists to determine "boosting or not", it's already possible as part of the user json (premium_since) as @msciotti said - determining the exact number of boosts from a given user still isn't possible, but it should be - that's the point of this issue.

chilly siloBOT
#

Because this PR does not seem warranted/necessary, was opened without discussion of its worthiness nor even a proper pull request description, and may be spam related to Hacktoberfest. We intentionally added this as a small joke to the documentation, and everyone already had the ability to comment on that prior PR before its merge. Copy like this also fits in as a "playful and fun brand that doesn't take ourselves too seriously."

#

I agree that this documentation isn't overly clear. It would be better to be informative and provide something of benefit rather than being jokey and ambiguous as a result.

As a side note, since I've noticed this a lot recently in various places: it would be nice for PRs to be given reasons before being closed without warning. Just out of courtesy for the fact the person who made the PR gave up their free time to try and improve your documentation. Even if it is the worst idea out...

#

I don't think someone who has previously contributed to this repository should be seen as a spammer. This PR is completely reasonable and just closing it without any comment is, quite honestly, pretty unprofessional behavior. The current way v7 is documented is completely incomprehensible in my opinion and doesn't seem like a joke to anyone reading this as a novice.

everyone already had the ability to comment on that prior PR before its merge.

I didn't even look at the PR since I was ...

#

Copy like this also fits in as a "playful and fun brand that doesn't take ourselves too seriously."

There's our problem, we need a balance between "haha funny brand for the kiddies" and "we need documentation for our users". You can look playful without sacrificing professionalism.

everyone already had the ability to comment on that prior PR before its merge.
Hadn't heard of the PR until after the merge. (yes, i've lived under a rock)

chilly siloBOT
#

I figured "Doesn't look like anything to me" would possibly confuse people when they see it in the docs, and that giving an actual reason as the status would make them realise "oh they skipped from 6 to 8" rather than "hmmm whats this secret v7 api... time to use it to be 1337 hacker".

We obviously care if there exists confusion, but from what I can gather there is no such confusion being reported with the current copy thus far outside of "what happened to v7." It is also clear from the ...

#

Labeling it "skipped" would not fix the user confusion in my eyes. Since we skipped v7 there will always exist a subset of people who will ask "what happened to v7?" This confusion will live on until v6 is decommissioned along with v7 sometime next year.

I will stick by my viewpoint that it is quite unprofessional & unhelpful leaving an inside joke in the place of core documentation. Other than saying that, I will argue no more, as it wouldn't lead to anything productive anyways.

chilly siloBOT
#

We obviously care if there exists confusion, but from what I can gather there is no such confusion being reported with the current copy thus far outside of "what happened to v7."

I mean, the fact that this PR exists means that someone must of been confused... Or that someone thought the chance of confusion was high. Either way, plenty of other playful and fun text still exists within the documentation -- so I really don't see why the removal of one instance is a problem.

Labeling ...

chilly siloBOT
#

sorry i didnt know this is the whole message in console.

04.10 21:28:43 [Server] ERROR ==============================================================
04.10 21:28:43 [Server] ERROR Your DiscordSRV bot does not have the Server Members Intent!
04.10 21:28:43 [Server] ERROR DiscordSRV and its API hooks require these intents to function. Instructions:
04.10 21:28:43 [Server] ERROR 1. Go to https://discord.com/developers/applications
04.10 21:28:43 [Server] ERROR 2. Click on the DiscordSRV...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

@night it is probably worth noting that since you know the codebase and internal design, it is understandable that you have a greater understanding of the state of things.

For people like us on the outside, we do not have access to the same information you will, so I feel that having a developer of a service being the one to dictate whether they think the documentation they wrote is confusing to other users or not is somewhat biased.

Not meaning to tread on anyones feet or anything, but it ...

chilly siloBOT
chilly siloBOT
#

The fact that every other comment here seems to be in support of this should make that clear :)

IMO there is nothing wrong with the current wording as it is clear and unambiguous. It clearly documents that the end-user should be using v8, which is all this section will ever show. What the current version is.

The current wording suggests to me that it doesn't exist.

Which then is counteracted by the fact several of the largest libraries use it.

If the intent is only to document tha...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

First of all, do you know how to use discord srv? It is a Minecraft plugin that integrates with the discord api to send messages across both MC Server and a discord guild
With that being said, you should have created a bot already in https://discord.com/developers/applications and linked it for the plugin to be working
What you need to do is go to the bot you're using, and check off "SERVER MEMBERS INTENT" under the "bots" section

This fixed it for me

chilly siloBOT
#

Description
Make guild.features a bit integer instead of an array of strings for version 8.

Why This is Needed
An array of strings is wasteful and since server boosting was added, guild.features is more likely to be filled with that data. It's also more flexible to use integers instead of string constants from my experience at least.

Alternatives Considered
I do have something implemented into my library which turns it into an integer. This is what I have ...

chilly siloBOT
#

Description
Right now do I face random errors with my bot which may look something like this (ID was replaced with 0s):

[ 06.10.2020 22:20:59 WARN  ] [JDA [25 / 27] RateLimit-Worker 4] [RateLimiter] - Encountered 429 on route PATCH/channels/{channel_id}/messages/{message_id} with bucket 80c17d2f203122d936070c88c8d10f33:guild_id:000000000000000000:webhook_id Retry-After: 920 ms

The above error basically tells that the library/bot received a 429 from Discord for the Channel...

#

There is a channel rate limit which affects the message CRUD routes, but other than that shared limit there is not another rate limit you should be hitting on this route.

So what could be a possible issue here then? Like this confuses me for quite some time now as to why my bot gets those warning seemingly random while I use the recommended methods of the Library to avoid such warnings in the first place.

chilly siloBOT
#

On the topic of this and the linked issue, I noticed that the delete message bucket now alternates between itself (3 / 1 sec), and 80c17d2f203122d936070c88c8d10f33 (5 / 5 sec), which is shared with the post message and edit message endpoints. Since I read somewhere that the delete message bucket is separate and faster to accommodate moderation bots, I was wondering whether this is intentional.

chilly siloBOT
#

Regarding this pr and crossposting, will replies be unable to be crossposted? Or (what would be pretty neat) is if the reply's would get auto attached to crossposts through the same methods editing a crossposted message.
Also couldn't help but think since maybe there should be different property naming, there would now be message_reference and referenced_message, which could be pretty confusing.

#

I think the concept is that you can inline-reply to any message maybe? Like looking at the comment below showing how it looks client side, it doesn't seem to be replying directly to the message, rather creating a separate message mentioning that message. Maybe not in the client (just cuz it seems kinda impractical), but in the API, might be able to send reply's to a message in a different channel than that of which that message is from.

chilly siloBOT
chilly siloBOT
#

v8 ship has sailed, and these are strings because we have many guild features, we'd run out of bits.

Are you implying that it isn't possible to use the same workaround as you did with permission bits? Discord definitely has the capability to use string-serialized numbers to overcome the bit integer limitation.

This will suffer from the same problem that permissions suffered from as Discord adds and removes features, which is quite often.

I'm only aware of 13 guild features—the ...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Regarding the comments, the one below is a screenshot of the feature in action, and the one above is incorrect. Quoting will be replaced (not markdown removed however), but it's not nearly the same thing. When replying to a message it auto fills into a "@user ", it's pretty much the same content field as sending a normal message. So if I had to make an educated guess some sort of message content will likely be required, while yes quoting doesn't require it, that's because the quote itself cou...

#

Well this is both true and not. In DMs yes, however being able to reply to something in a different channel in the server the message is in, doesn't come off as unworldly. It'd be neat to see, maybe even for like logging purposes? Being able to reply to the message in a log channel per say to keep track of it. Or replying to like an announcement in a general chat for users. It doesn't seem like something that shouldn't happen, but still might not.

#

And I'm struggling to comprehend the fact that message_reference is now both in POST and message object and meaning completely different things and I'm looking at the PR explaining it all.

Could you elaborate? They should mean and represent the same thing. A message_reference is comprised of guild, channel, and message ID fields.

If the referenced message gets deleted, will the reply be removed? Or will it do something similar to crosspost like replace it with "[Original message...

#

Could you elaborate? They should mean and represent the same thing. A message_reference is comprised of guild, channel, and message ID fields.

A referenced message is not mutually exclusive to the message_reference field. They're separately documented, and properties could be renamed without changing how the documentation/functionality of the object works.
The issue that is coming up for me is that crossposted messages & replying messages use the same properties, and this could be v...

chilly siloBOT
chilly siloBOT
#

There is quite a few internal ones too.

Bit-shifting aren't going to be affected by internal ones. They can skip some shifts as they did with INLINE_REPLY (15, ..., 19, etc).

There seems to be no benefit to moving from an array to a string at the cost of duplicating the information being sent. I can see why this would be nice to have but adding a features_new field seems wasteful and redundant. Would be nice for v9 though I suppose.

I'm not sure where you got the idea that th...

chilly siloBOT
#

Description
Bots that are on fewer than 100 guilds, but have ever been on more than 100 guilds, are unable to enable privileged intents.

Steps to Reproduce

  1. Run a bot for 5 years
  2. Experience slow natural growth
  3. Manually have bot leave all but 99 servers
  4. Attempt to enable privileged intents

Expected Behavior
It was expected to be able to enable privileged intents once the bot was on fewer than 100 guilds

Current Behavior
The boxed for privileged intent...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description

As of late, discord has started forcing the notion of stateless bots. This however doesn't really work well when the API is literally designed to update state (the client). Currently, events only provide the new state of the updated entities. It would make it a lot easier for bots to be stateless and not require loading members if discord would provide the old state, or at least provide some way of identifying what changed.

Why This is Needed

Many mode...

chilly siloBOT
#

Frankly, this information would have been nice to know as soon as the verification system was announced, so that people could have pre-pruned their bots to below the threshold so as to not render the bots useless now. Lots of "hobby-project" bots (that are likely not qualified to be verified) were previously public for ease of adding for friends, but if they happened to hit 100 guilds, they will be permanently broken as of today.

chilly siloBOT
#

As an addendum, there are several reasons why someone might intend to keep a bot unverified:

  • They want to be able to change the bot's username
  • The bot is not kept online consistently enough to merit verification
  • They intentionally want a hard limit on the number of guilds a bot is in (ie keep hosting costs minimal)
  • Their bot's feature-set changes or is inconsistent (hobby-project bot)

**If a bot that is intentionally unverified, or not eligible for verification, happened to hit...

#

Description

This feature would allow bot owners/developers to set a hard limit on the number of guilds to which the bot can be added during the regular bot oauth flow. If the limit is reached, users cannot add the bot to any more guilds.

Why This is Needed

Some bot developers choose to not verify their bots and may wish to keep their bots in less than 100 guilds to continue operating fully (see #2134). Without a hard limit, your bot's privileges may be in the hands of the use...

chilly siloBOT
#

The issue that is coming up for me is that crossposted messages & replying messages use the same properties, and this could be very confusing for people, example if someone ctrl+f's to find what message_reference means they could get two completely different meanings, it's just asking for trouble.

Most of my confusion stems from how message_reference here is being used exactly by its name: we're referencing another message. #2053 documents that this is how it's used — including for t...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description
The Modify Guild Member API endpoint, documented here: https://discord.com/developers/docs/resources/guild#modify-guild-member, fails with the following error when trying to modify the nickname of the owner of the target server/guild:

{ ["message"]=> string(19) "Missing Permissions" ["code"]=> int(50013) } 

Steps to Reproduce

Send the following payload: {"nick":"New Nickname"} as a PATCH request to the endpoint: ``https://discord.com/api/v8/guilds/SER...

#

Then there should be more links to this section because I never came across to it (and I expect most people implementing something don't read the doc from A to Z before doing anything you find the relevant information first). And it is frustrating to figure out what went wrong until someone told me about this potential restriction.

I was aware of the role management constraint but a bot can still grant a role to the owner of the server.

Or Discord could introduce a new JSON API erro...

chilly siloBOT
#

This could be extended to also provide the full message payload when a message is being deleted, so that we actually can know what got deleted in the first place.

This would fall in line with moderation of message edits. The current message delete format is pretty useless in terms of the information it gives you (no content, no idea who sent the message, no idea if it had embeds, no idea if it mentioned everyone (e.g. ghostpinging), no idea if it was pinned, etc)

chilly siloBOT
chilly siloBOT
#

Description

Hello, then doing a request to GET /users/{user.id}, we can't tell if a user is deleted or the username is
'Deleted User XXXXX", so i would like a way to know if an account is deleted (kinda like bots) with a value of deleted:true then an account is deleted.

Why This is Needed

As you may know, there's a law called GDRP, and i support this law, so i would like a way (as projects owner) to delete data from deleted users.

Alternatives Considered

The...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

This is both a migration issue and an abuse issue. On our end, applications are in one of four states when it comes to verification

- Ineligible (have not met the 76 guild requirement)
- Unsubmitted (you, at some point, crossed that threshold)
- Submitted (you have an active application submission)
- Approved

Right now, the code is checking if you are in an ineligible state to be able to flip those toggles. Otherwise, you cannot.

If we were to make it check for unsubmitt...

chilly siloBOT
#

This is all a long way of saying that before we go spend a bunch of time changing the system and dealing with the abuse cases that will occur, for how many people is this a problem? I know that your bots are in a unique case. Perhaps we can see if we can just handle this manually, as it won't be an issue for new bots going forward?

There are a more people waiting on the outcome of this situation. They don't want to verify their "large" bots, but they don't want to lose member/presence fu...

chilly siloBOT
#

Considering that bots with privileged intents cannot be added to 100+ guilds if it isn't verified

This is actually not the full picture. Any bot--regardless of intent requirement--cannot be added to over 100 guilds. That's why I'm not sure I understand the use case of this feature suggestion? You do effectively have this limit already, it is 100 servers. A bot that is currently in under 100 servers cannot join a 101st without getting verified.

The only other thing that currently trigg...

#

They don't want to verify their "large" bots, but they don't want to lose member/presence functionality, so they are considering pruning down to below 75/100 guilds...maybe you could handle the amount manually, but remember that one of the premises for the introduction of intents/verification was that the bot count was small enough to handle, yet you guys were overwhelmed by the response

Yeah, this is what I mean by a "migration" issue. Whenever you have a restriction occur on a date, th...

chilly siloBOT
#

I see. So if I can parrot this back to make sure that I understand it:

For new bots, they can enter the unsubmitted state. This causes them to no longer be able to join more guilds (that's fine), but also disallows them from toggling privileged intents.

So, if for example you decided in the future that you need Presence data for some new feature of the bot, you can't turn it on.

The problem is not entering the state, but that toggle ability.


Understood. This is a complex ...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description
When trying to create a server template when it already has one, it returns error 30016 with a message about invites.

Steps to Reproduce

  1. make sure a server has a server template
  2. POST /guilds/:id/templates with a body including name

Expected Behavior
an error that mentions templates; either just edit the message of 30016 or make a new error code

Current Behavior

{
    "message": "Maximum number of invites to this server reached.",
...
chilly siloBOT
#

Since this is the direction the industry wants to go, then I'll raise the alarm on "black magic". Ref: https://discord.com/developers/docs/topics/community-resources#embed-visualizer

Since the narrative is that "black" and "white" are now always going to be associated with race because we can't see that referring to two groups of people with words that are polar opposites in almost every other context is fighting an impossible battle (and that there are many, many other contexts that preda...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Previously the docs didn't specify if, or how, some array entries are sorted, so you'd have to figure it out yourself by requesting an endpoint and inspecting the response.
For example, it might not be immediately clear that the Get Reactions endpoint sorts users by ID instead of in the order they reacted in. Additionally, while most endpoints use ascending ID ordering, some other endpoints such as Get Channel Messages sort items in reverse.

This PR aims to document that behavior and the ...

chilly siloBOT
#
Returns the messages for a channel. If operating on a guild channel, this endpoint requires the `VIEW_CHANNEL` permission to be present on the current user. If the current user is missing the 'READ_MESSAGE_HISTORY' permission in the channel then this will return no messages (since they cannot read the message history). Returns an array of [message](#DOCS_RESOURCES_CHANNEL/message-object) objects on success, sorted by their id in descending order.
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description

Webhooks for my action runs started receiving 400s starting around 6:55PM PST. The 400 responses have a response body of {"check_run": ["check_suite"]}. I'm currently getting about 3/16 webhook messages successfully delivered.

Steps to Reproduce

  • Create an action on a repo
  • Set up a Discord webhook
  • Run the action somehow
  • Observe the lack of a message

Expected Behavior

A webhook message is sent

Current Behavior

No message is sent

chilly siloBOT
#

Regarding the serialized_source_guild property, it's relatively unclear without looking at the returned JSON which properties may or may not be present (and that continues down into roles and channels of that object as well). Perhaps it's worth documenting those three separately from the main guild object? Another motivation for that would be that the main guild object contains a number of fields that would be completely irrelevant for a template, such as the owner ID and the permissions of...

chilly siloBOT
#

This is an attempt at continuing #2127's discussion.

To summarize the discussion of that PR: The current wording of the status of v7 API and Gateway, "Doesn't look like anything to me", is potentially confusing. The PR was made to change the wording, so that it was more clear for beginners of the API that v7 is discontinued, skipped, whatever -- that you shouldn't use v7 because v8 (a better version) is already released.

The PR was closed by night for a variety of reasons, including bei...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

I wrote a lot of this as I was doing research, but I need to start with:

I. Am. Mad. I read that 2018 journal that everyone is in a tizzy about (second link in @Fyko's post). I actually read it. I am angry that this garbage is what people consider remotely good enough to upheave an industry on. I am furious that people read this and think that it's okay to shove that bloke's utter garbage down the throats of hard-working engineers ...

#

I just want to make a quick note for all those struggling on iOS (like myself)
Discord seems to have problems with custom schemes (read: anything not http/s). When working with redirect URIs using libraries like OAuthSwift, it's better to have a custom domain redirect that sends the client back to your app. Even though Discord's online OAuth settings accept a custom scheme like myapp://authorize, you will get this same 'invalid redirect_uri' error.

Instead, the solution I ende...

chilly siloBOT
chilly siloBOT
#

@mr-tech Please publish that as an article somewhere so more places can see it, I feel like this is something the entire industry needs to educate themselves on before it's consumed by some woke agenda. We've already seen other industries be consumed by a woke agenda, and it's most visible in the entertainments industry... just look at TV Boxsets made within the last 3 years and compare it to boxsets from 10, 15 years ago (if they haven't been removed because users on Twitter pressured compan...

chilly siloBOT
#

I don't see how this is more more inclusive. Am I missing something? I don't see how whitelist includes less items then allowlist. If you mean inclusive as in more people, that makes less sense to me. Like does words like white space deny anyone of anything? I don't see how anyone is considering the words whitelist or blacklist limiting someone's ability to read the API docs or use the API. If anything, I feel that it'll cause more confusion as they aren't the usual terms used and say...

chilly siloBOT
#

Before Discord starts deleting these comments, I'd like to chip in myself.

Unfortunately these types of issues have been spreading recently, some of you might of seen the changes in other places.

I've found that the people who suggest these changes usually only come armed with the four same "articles" who's scientific base, is well, dubious. As made by @mr-tech's superb points. Surely if this was such a big issue there would be thousands of articles and actual scientific research done on i...

chilly siloBOT
#

...honestly I kinda forgot that there was more I needed to document lol.
I've had a quick look and found all these additional endpoints to return an array:

  • Get Guild Audit Log
  • Get Pinned Messages
  • List Guild Emojis
  • Get Guild Channels
  • Get Guild Bans
  • Get Guild Roles
  • Get Guild Voice Regions
  • Get Guild Invites
  • Get Guild Integrations
  • Get User Connections
  • List Voice Regions
  • Get Channel Webhooks
  • Get Guild Webhooks

I know not all of them are/can be sorted, b...

chilly siloBOT
#

Modify Guild Role Positions and Channel Positions are depending on YOU to provide the positions, the API doesn't return it explicitly afaik

Modify Guild Channel Positions only returns 204, not the set of channels. Not sure why. Modify Guild Role Positions returns all roles, not just the ones you sorted. They appear to be in snowflake order.

a note on how the client does sorting would be appreciated at some point

I agree. I've asked about it in #881 and #1277 and did not receive a...

chilly siloBOT
#

Alright, I've added some more endpoints. Some takeaways:

  • Voice Regions don't seem to have any sorting, and even if it wouldn't make much sense.
  • I couldn't find any ordering for Get Guild Integrations; it's neither by id nor application ID apparently.
  • TIL invites are sorted by their code in alphabetical order. The client UI sorts them by author name.
  • User connections are sorted alphabetically by connection type ("github" - "spotify" - "youtube" etc); I can't test how they're sort...
chilly siloBOT
#

Jake talked about it in DAPI

I just want to say that I was there -- and Jake refused to even have the discussion in the first place. I could understand if Jake believed that the change was unwanted, but Jake outright refused to have discussion on the matter.

Since it's clear to me that even attempting to have a discussion is unwanted (even though that was one of night's reasons for closing the PR), I cannot see myself continuing my part of the discussion. Unless someone on the team wa...

chilly siloBOT
chilly siloBOT
#

Please get involved and support actual meaningful change in the world rather than useless slacktivism. Look into your local political organizations to see if you can volunteer (current pandemic permitting) or donate to the NAACP or similar.

Changes like this don't accomplish anything. At worst they alienate apolitical people by associating real political activists with what some would deem "snowflakes".

Instead of trying to make yourself feel...

chilly siloBOT
chilly siloBOT
#

Playing devil's advocate for Discord here, if you see "Doesn't look like anything to me" and instead of, I'm not sure, asking a question and instead you just literally give up reading documentation. That seems like more of a problem with how you feel about a joke than anything about the actual text. It would take 30 seconds to make an issue or ask in the DAPI/ddevs server.

fwiw I think the wording isn't great either. Just pointing out that last comment is absurd.

chilly siloBOT
#

Jake talked about it in DAPI

I just want to say that I was there -- and Jake refused to even have the discussion in the first place. I could understand if Jake believed that the change was unwanted, but Jake outright refused to have discussion on the matter.

I don't believe it is a topic worth discussing. It's not confusing that you are expected to use v8. Often times open source repos have issues and pull requests like this which aren't important and just end up locked for bein...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Well, there are a number of ways to respond to what this PR has turned into. I will keep it simple.

Someone went through the effort to suggest these changes and open a PR with said changes knowing that it would be poorly received. We have people internally at Discord who are happy to see these changes. So, I would state that factually, people do indeed care about this.

While replies to this topic have been opinionated, I do not think they are intended to be disrespectful (though strong ...

chilly siloBOT
#

@msciotti Agreed, people do care about this. My essay proves that I care a lot (more than I'm comfortable caring about it. I wish I couldn't care tbh).

Discord's decision is Discord's decision. I said my piece on the topic and will let it go.

Moving forward, I think it is important to define under what understanding of "inclusion" these changes are being made so that people can properly evaluate the rest of the documentation for similar changes that must be made under Discord decision. ...

chilly siloBOT
chilly siloBOT
#

Repository maintainers should really give a second consideration to locking discussion on this PR from non-involved parties, this PR has been posted on several 4chan related community centers and it's going to get flooded with armchair sociologists who will completely miss the point of this PR in order to concern troll.

I support this PR, it's a good change with the exception of one nitpick;

Would authorized/deauthorized be a better replacement than allowlist/delimited?

It'd ...

#

maybe rewrite the entire paragraph to

If you specify an `intent` value in your `IDENTIFY` payload that is *disallowed*, the socket will close with a [`4014` close code](#DOCS_TOPICS_OPCODES_AND_STATUS_CODES/gateway-gateway-close-event-codes). A disallowed intent is a privileged intent that has not been activated for this bot. Bots in under 100 guilds can enable these intents in the bot tab of the developer dashboard, verified bots have to request discord to activate these for the bot ...
chilly siloBOT
chilly siloBOT
#

The hook property in GET /oauth2/applications/@me is not properly documented in the documentation site.
Also what does the hook property mean anyway since it's not documentated on any libraries nor on the documentation site for it?

Example App from Page

What I gotten:

{
  id: '531613242473054229',
  name: 'Nino',
  icon: 'a822e90063fd0359d15fdf6ad3af64de',
  description: 'Discord moderation bot',
  summary: 'Discord moderati...
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Ridiculous PR that was done for nothing more than virtue signaling, you would literally accomplish more by donating 5$ to some charity than changing most instances of a word
In all fairness, at least it's not as bad as Github's own "replacing slave/master with something more inclusive" change prompted by some american movement protesting a black man's death, which ironically turned out to be racist because it implied only black people would be slaves and not, you know, literally anyone for m...

#

allowlist/denylist just sounds unnatural, like someone just ran sed on the repo and called it a day

grantlist/blocklist keeps the same number of syllables and characters as whitelist/blacklist. allowlist and denylist just do not sound "smooth" or "good."

I propose avoiding Xlist and Ylist since that will only invite more confusion being terms that don't actually exist and aren't any more descriptive than whitelist and blacklist. I'm in preference of "list o...

chilly siloBOT
#

I'm in preference of "list of X" as that will universally be the most descriptive

a role that is on the list of allowed roles is much more verbose than a grantlisted role (>3x words, >2x syllables). While the latter might initially be more confusing for someone who is looking at it for the first time, the context makes it clear what the phrase means. Grantlist/blocklist are more descriptive than whitelist/blacklist (grant-list = a list of things that are granted access, block-list = ...

#

I'm in preference of "list of X" as that will universally be the most descriptive

a role that is on the list of allowed roles is much more verbose than a grantlisted role (>3x words, >2x syllables). While the latter might initially be more confusing for someone who is looking at it for the first time, the context makes it clear what the phrase means. Grantlist/blocklist are more descriptive than whitelist/blacklist (grant-list = a list of things that are granted access, block-l...

chilly siloBOT
chilly siloBOT
#

Nihlus details a good concern, and unfortunately I have no good solution here.

In general for this set of APIs, the serialized_source_guild property is very messy. Internally, it is inherited from the base Guild object, and Discord clients parse it like a Guild (with the exception of icon/icon_hash) so I don't think that documenting it completely separately is a good idea. If the base Guild ever had a new non-optional field, serialized_source_guild would likely come with it as we...

chilly siloBOT
chilly siloBOT
#

words as grantlisted are just bad, while you typically can figure them out by looking at context, the parts that make the word and some thinking. it doesn't just require a lot more effort to do, it raises the bar enormously for non native english speakers, and especially for developers with limited knowledge of english.

When trying to use a translator to translate it to my native language, it translates to "listed at the stock market" in my native language. even when used in a sentenc...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

I'm assuming X and Y here are placeholders, X-Listed / Y-Listed conveys literally nothing. I haven't had a chance to read the 3000+ words in this PR conversation to figure out what's going on. Allowlists and Denylists are probably the best bet you're going to get here, they're already used in some places and convey enough meaning (ie you're either allowed or not allowed). People yelling it doesn't sound "natural" are just yelling it because it's different, given enough time you'll get used to...

#

Allowlists and Denylists are probably the best bet you're going to get here, they're already used in some places and convey enough meaning (ie you're either allowed or not allowed).

I don't think adopting neologisms makes for a very accessible documentation, I prefer the current approach of rephrasing instead of just s/whitelist/allowlist/g. As was mentioned previously, translators will have a hard time translating it properly. Words such as these can be adopted when they are widely in u...

#

I don't think adopting neologisms makes for a very accessible documentation, I prefer the current approach of rephrasing instead of just s/whitelist/allowlist/g. As was mentioned previously, translators will have a hard time translating it properly. Words such as these can be adopted when they are widely in use, but not right now, especially in documentation where clarity is important.

If we're going the route of having things that are widely adopted/in use why are we rushing into maki...

chilly siloBOT
#

Then why are we rushing into doing this?
Because it has been stated that this will get merged, so might aswell make the best out of it now. To be frank with you I am opposed to the original changes, tho the documentation could use some rephrasing here and there.

And for allowlist/denylist, I agree there are places where it can act as a drop-in replacement, but for a lot of those cases a simple rephrasing, which simultaneously can also aid clarity, will also do the job, so I really don't...

#

Description

When doing breaking changes like requiring whitelisting for people that have the server member intent already enabled, consider warning bot owners that have that option enabled but are not whitelisted

Why This is Needed

When the intent system became available, I enabled the server member intent as soon as possible because I need the server members for my bot.

The intent toggle had been explained as follows:

This toggle will temporarily not have...

chilly siloBOT
chilly siloBOT
#

It was not mentioned in the emails before or after verification for me. I get that it was mentioned in a later blog post and help article, but I really do think the communication could have been better.

Also I understand that I'm partly at fault here, but I'm far from the only developer not understanding this properly.

My feedback is really this:

  • Show a big red warning in your verification screen that says 'Your bot is currently in a broken state' when it is

and/or

  • Send an ...
#

The format of serialized_source_guild is exactly the same as what the create guild endpoint accepts: https://discord.com/developers/docs/resources/guild#create-guild

It's a template, it's purpose is ... creating guilds, so the data format is just exactly what we need in order to re-create that guild. So the same rules/restrictions/conventions that the create-guild endpoint has apply here too (for example the first role is always for @-everyone, etc)

icon/icon_hash are the one exception...

#

Nihlus details a good concern, and unfortunately I have no good solution here.

In general for this set of APIs, the serialized_source_guild property is very messy. Internally, it is inherited from the base Guild object, and Discord clients parse it like a Guild (with the exception of icon/icon_hash) so I don't think that documenting it completely separately is a good idea. If the base Guild ever had a new non-optional field, serialized_source_guild would likely come with it...

#

Agreed with the suggestion to show a warning in the UI that the bot is currently in a broken state. Here's what I mean:

I can read "You must apply for whitelisting if you turn on any of the Privileged Intents" and still not realize I need to do anything if I believe that I have already applied. When looking at the enable/disable toggle in the bot settings, and I don't see any red or warnings or anything, that bolsters my belief that I am in a good state when I am not.

Taking out the "if...

chilly siloBOT
#

And it is true that whitelist/blacklist relies on cultural presumptions

There is no such presumptions. The problem with the 2018 journal and with what people are doing with allowlist, grantlist, etc. is that they're abusing their grasp of the language by breaking the words down into their parts, saying "I understand these parts in isolation", and then gluing them together again. Saying that "white list" is hard to understand is applicable to "fire wall", "gate way", "guide line", "under ...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

How about we stick to the topic of the PR for now, because it does not require a PhD in linguistics to understand the intent of the author's changes.

And--as someone who studied English language and literature--as much as I love a good debate about philology, I think we're all well aware that that is not the intent of these changes, or the discussion that has sprouted from them.

chilly siloBOT
#

@Nihlus

Would you like me to open an issue and elaborate a bit more?

I think this is a good idea. I expect this concern to come up again and it definitely looks like a much bigger scope than this PR.

But to set some expectations I'm going to avoid personally making any decisions around this area. I'm honestly not too familiar with the API, and so I'm definitely going to defer to the longstanding API doc maintainers (i.e. night and mason). But they are very busy right now so nothin...

chilly siloBOT
#

Description

Upon restarting a bot, users who have previously triggered the event on_reaction_remove can no longer trigger the event. This can be fixed by restarting the users discord client.

Steps to Reproduce

To reproduce the issue, create the event, on_reaction_remove and have a user remove a reaction triggering the event. Then restart the bot, and have the user try to trigger the event by removing a reaction again. The event will not trigger.

*Expected Behavior...

chilly siloBOT
#

Description

This issue continues on from a discussion that started in #2144, in regards to a lack of clarity in the definition or implementation of the Guild object.

In the new Template API, there exists a property called serialized_source_guild which, ostensibly, contains a Guild object. However, the data in the property never contains an id property, nor a significant number of other properties. Furtherm...

chilly siloBOT
chilly siloBOT
#

looks like bots can also access /sticker-packs/directory/:layoutid:

  • client uses the layout id 758482250722574376
  • error 10033 Unknown Store Directory Layout
  • query params with_store_listings boolean and country_code

and when bots try to send stickers in a message by including sticker_ids, it returns error 50081 Cannot use this sticker; will bot be able to send stickers in the future?

chilly siloBOT
#

looks like bots can also access /sticker-packs/directory/:layoutid:

  • client uses the layout id 758482250722574376
  • error 10033 Unknown Store Directory Layout
  • query params with_store_listings boolean and country_code

and when bots try to send stickers in a message by including sticker_ids, it returns error 50081 Cannot use this sticker; will bot be able to send stickers in the future?

Bots don't need to access the directory layout so we can leave it undocum...

chilly siloBOT
#

Description

It would be useful if bots could create webhooks where only the account that created the webhook could access its token / use the webhook.

Why This is Needed

A few large bots on the platform (namely, PluralKit, Tupperbox, NQN, and possibly more) use webhooks to send, or "proxy", messages sent by users.
Editing webhook messages was recently added. This creates the issue where a server admin, or other user with Manage Webhooks permissions, could edit a different u...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

@puddi Let's instead just say that the URL for fetching them is private

@advaith1 It's possible, but we don't want to yet document it. There's lots of undocumented but technically available things within our API. In this case, where we host stuff could be subject to change (since we have two URLs that resolve there right now, lol) and we don't want everyone scraping stickers yet outside of our experiment

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

I'm running into an issue with SetLogHook where it doesn't seem to display any debug messages. I'm trying to catch the NotRunning error when discord quits while the game is running, but I'm not sure 100% that my implementation is correct. NotRunning does in fact show up if I quit discord while the game is running, but I expected the callback function to fire, but nadda. Any ideas?
image
...

chilly siloBOT
chilly siloBOT
#

Understood, but then I have to ask. The use case for this seems to be related to server moderation (that server admins can edit a webhook's message), so why would it matter if the ability to customize the avatar and username was lost? If there's a need to prevent server admins from editing messages like these, I fail to see why a loss of customization would be a big issue.

#

No, the use case for webhooks as presented here is for proxying a message as a user, but modified in some small way. The intent here is that server administrators shouldn't be able to edit a message that was legitimately proxied as a user as server admins don't have that permission for regular user messages.

NQN is the only bot of the three given above that I can give a complete explanation for so apologies for the lack of generality, but it allows people for example to include message URL...

chilly siloBOT
chilly siloBOT
#

This PR adds a note that setting guild_subscriptions in v8 does not have any effect on whether typing and presence events are sent, or not.

Tested combinations:

Gateway version Intents guild_subscriptions Result
v6 None true Receives TYPING_START and PRESENCE_UPDATE event
v6 None false No TYPING_START and PRESENCE_UPDATE event
v6 GUILD_MESSAGE_TYPING/GUILD_PRESENCES false Receives TYPING_START and...
chilly siloBOT
#

TBH I don't feel message editing is anywhere near as an important concern for this feature. This seems like 100% necessary for security.

What happens if i want to damage the credibility of a bot? I could fetch all webhooks created by any bot for whatever purpose and then start sending nsfw or anything abusive. and send pretending to be X bot with it's name & avatar

chilly siloBOT
#

Hello! I can't speak for NQN, but both PluralKit and Tupperbox have a feature where you can react to a proxied message with a question mark and the bot will reply with the original user who sent the message.
If someone manually grabs the webhook and sends messages with it (whether they're replacing someone else's message or just something abusive), the bot's database will have no knowledge of the message and will reply that the message was not proxied through that bot.

#

What happens if i want to damage the credibility of a bot? I could fetch all webhooks created by any bot for whatever purpose and then start sending nsfw or anything abusive with it's name & avatar
Even if the bot's webhooks were restricted to only the bot being able to use it, you could just as easily create your own webhook and do the same malicious things. I have seen this happen numerous times already with bots webhooks created both by the bot and by those who have permission.

chilly siloBOT
chilly siloBOT
#

In the gateway documentation, there is an example URI where the version and encoding are set explicitly in the URI. The version is set to 6, but I think it should say 8 as the majority of the documentation applies to gateway version 8, and for newcomers, this would lead to confusion.

With the resulting payload, you can now open a websocket connection to the "url" (or endpoint) specified. Generally, it is a good idea to explicitly pass the gateway version and encoding. For example, we may...

chilly siloBOT
#

Description

Now we're able to edit and delete webhook messages, could we make it so we can do it for any webhook message in a channel we have manage webhooks in?

This could be implemented by allowing the PATCH and DELETE methods for the /channels/{channel.id}/messages/{message.id} endpoint to work for any message with a webhook id set to be modified/deleted if the current user has manage webhooks in that channel.

Why This is Needed

To edit/delete a message by id, assumin...

chilly siloBOT
#

Global Rate Limit errors and increases, CloudFlare bans, and Large Bot Sharding are not documented super well, leaving many developers to assume they have to contact us when their bot gets large. While we certainly love chatting with new devs at scale, I felt it might be good to more clearly document just exactly what these systems do, how the errors can manifest, and what these programs solve.

That is to say, they are not a magic solve for all problems, but may help you in a specific ...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

I think this might be relevant to the convo (2 paragraphs lower):

This is not true for all bots above 250,000 guilds, but if you have a large bot and find yourself having these issues, please file a support-ticket to get moved to Large Bot Sharding. You can contact the discord support using https://dis.gd/contact.

So it seems 250k != Large Bot Sharding, and therefore you don't automatically get 2k IDENTIFYs when you have a big bot.

chilly siloBOT
chilly siloBOT
#

@A5rocks I understood that, and I wasn't trying to say that 250k means it's a Very Large Bot.

However, when a bot gets Large Bot Sharding enabled, you then get an increase in IDENTIFY calls, as well as the ability to start more shard concurrently. As it stands, the documentation does not mention either of these points (and, in fact, seems to imply the opposite on both) -- so I was suggesting that msciotti document both points.

chilly siloBOT
#

I suggested this in one of my issues here, to implement a separate way of receiving the members on startup (if the bot has the members intent) so that it has it easier to handle member updates later on.

The API as it is right now is extremely counter-productive towards a majority of existing bots, as they either have to chunk members or retrieve them when a command or similar is executed, which both takes (a lot) of time and consumes additional requests.

Having Discord send the updated info...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

I found the following field in the app configuration:

INTERACTIONS ENDPOINT URL

You can optionally configure an interactions endpoint to receive interactions via HTTP POSTs rather than over Gateway with a bot user.

However, I haven't found a single place where this is documented, so I don't know where to start. I could set up an endpoint to check what I receive, but I don't really understand how to do it without a bot user. I'm not even sure if the text means that I don't ne...

chilly siloBOT
#

Description

A new property that bots can send in messages that can be checked by TnS team whether a message from a bot contains user-generated content.

Why This is Needed

A malicious user decided to make bots say "bad"(doxing) things using certain features on the bots and then mass reporting it.

5 bots were reported and 4 of them were banned. The 5th wasn't banned because most likely it was one of the largest bots on Discord and would cause a nightmare having tha...

chilly siloBOT
chilly siloBOT
#

Why can't you just report the message like normal?

"A malicious user decided to make bots say "bad"(doxing) things using certain features on the bots and then mass reporting it."
Literally any user-generated content that is possibly breaking ToS can be reported, reporting a mesage like normal is not possible because it is the malicious users reporting, not you.

a "containsUserContent" property would be useful to prevent a bot from being insta banned for having malicious users report ...

#

I can't help but see this suggestion as more of a band-aid.

There's far too many bots for T&S to reasonably have a list of where UGC could be and where it couldn't be. Even if you have a property that tells T&S that a message has UGC in it, they would still have to figure out what part of the message is UGC, and what part is your bot's doing -- something that isn't always that easy.

It's easy for T&S to know that a role name shown through <@&ROLE_ID>, or something like a nickname on y...

chilly siloBOT
#

your suggestion of approving UGC is actually a very good one, but i will tack on the idea of providing a notice that the UGC in question is subject to approval by the bot's developers and that the bot cannot be held responsible for said UGC until it has been approved. in the event the UGC is disapproved then simply clear said UGC and inform the guild owner in question that the UGC was not satisfactory.

I am also of the opinion that the containsUserProperty solution is a band-aid on a large...

chilly siloBOT
#

This is not something we're going to pursue for a variety of reasons, one main one being that people would just simply set this flag to true by default, or not understand the nuance.

The problem is not with the API, but with the enforcement of ToS - and this is something our T&S team is continuously improving. No, your bot should not get banned if someone uses it to do something bad and mass reports it. That problem is on us, not you.

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Thank you for the feedback. We understand this was a breaking change, and therefore had a 6-month migration period and did our best to communicate this impending change via blog posts, DMs and emails, in the Dev Portal UI, etc.

But, we are certainly not perfect! It would probably be good to add some validation when submitting your verification request if you have those intents turned on but did not apply.

#

It may be beneficial to start documenting these rate limits on an endpoint-by-endpoint basis, since it appears this is how they are now being implemented.

This is not a great solution because it will encourage people to hard-code backoffs instead of programmatically handling them via headers.

As for your original question, I'm not sure what you believe the proper solution would be. Adding a note that says "These resets can sometimes be a number of days?" when that is really only true ...

#

I started thinking about this a week ago. I think another good solution is for libraries to avoid blocking and return a rate limit error, if the time-to-wait would be above a certain amount (say, 10 seconds) -- or if it's below that amount, it would block and automatically try again once the timer is up.

However, we should at least have a note on the Rate Limits page -- so that anyone making their own library won't run under the same assumption that all rate limits are short.

#

It's an interesting idea, but ultimately not something we'd want to display like this. For scheduled downtimes, I think a number of people here have commented on ways to either avoid it or proactively message it.

For unscheduled downtime...well, such is the way of the internet I suppose. Support servers with reactive messaging, or even some sort of backup message send script you can run locally, are probably simpler ideas.

Others are also right in that tying something to status wouldn't...

chilly siloBOT
#

Description
This new intent would allow bots to specify to report a message to T&S when deleted.

Why This is Needed
On most big servers, bots handle antiraid, instantly mass deleting messages from those involved in raids. Sadly, when messages are deleted by bots, they are completely removed from Discord's database, making it hard or impossible to report the users. This could also apply for message filtering for bad words or copypastas, so bots could log what was deleted, an...

chilly siloBOT
chilly siloBOT
#

On the topic of this and the linked issue, I noticed that the delete message bucket now alternates between itself (3 / 1 sec), and 80c17d2f203122d936070c88c8d10f33 (5 / 5 sec), which is shared with the post message and edit message endpoints. Since I read somewhere that the delete message bucket is separate and faster to accommodate moderation bots, I was wondering whether this is intentional.

That definitely sounds like a problem and could be the cause of this. The bucket for delete m...

chilly siloBOT
#

<!--

Before opening a new issue, please search existing issues: https://github.com/discord/discord-api-docs/issues

-->

Description

This new intent would allow bots to specify to report a message to T&S when deleted, or just have the option to store the message in Discord's DB even after deletion.

<!--

Provide a clear and concise description of what the feature request is.

-->

Why This is Needed

On most big servers, bots h...

chilly siloBOT
chilly siloBOT
#

On the topic of this and the linked issue, I noticed that the delete message bucket now alternates between itself (3 / 1 sec), and 80c17d2f203122d936070c88c8d10f33 (5 / 5 sec), which is shared with the post message and edit message endpoints. Since I read somewhere that the delete message bucket is separate and faster to accommodate moderation bots, I was wondering whether this is intentional.

That definitely sounds like a problem and could be the cause of this. The bucket for de...

chilly siloBOT
#

Description

We all want to make our bots look beautiful, detailed and well made. Custom emotes help with this. This exclusivity of emotes for bots would actually be a tab for us to be able to add custom emotes for bots to use.
An easier way to use emotes without having to use any server for that.

(it is very annoying to have to take this in every emote).

Why This is Needed

This is a little necessary for those who are new to creating bots, and to facilitate the work of ...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

The way max_concurrency works is that the identify limit is per bucket. The order at which these buckets execute is not relevant as they are concurrent and have their own limits. Small bots have a max_concurrency of 1 which means they only have one bucket, while bigger bots have 16 buckets each with a 5s identify rate limit. You could start shard 0-14 and shard 63 (because 63 % 16 = 15) at the same time.

For example, a bot with max_concurrency 1 can start the shards in random order. The ...

chilly siloBOT
chilly siloBOT
#

Steps to Reproduce

Setup a new bot that uses the Guilds intent, listen for GUILD_CREATE, nothing happens when a bot joins a guild / or starts up when a member of one or more guilds.

Expected Behavior

Discord should send GUILD_CREATE events regardless of privileged intent activation.

Current Behavior

Without the privileged intent activated, no GUILD_CREATE events are sent from Discord.

Client and System Information

Testing on https://github.com/an...

#

Unable to reproduce using...

  1. a new bot without any privileged intents activated with GUILDS intent specified and joining a new guild:
[Client] Received payload from gateway 'Hello'.
[Client] Sending payload 'Identify' to gateway.
[Client] Initialized heartbeat: 41.25 sec.
[Client] Received event 'READY' from gateway.
Waiting for guilds to arrive...

--- Adding the bot to a guild

[Client] Received event 'GUILD_CREATE' from gateway.
[Client] Received event 'GUILD_MEMBE...
#

@andersfylling

Edit: the intent value sent on identify is 2047

If you use an intent value of 2047, your bot has the following intents:

Guilds | GuildMembers | GuildBans | GuildEmojis | GuildIntegrations | GuildWebhooks | GuildInvites | GuildVoiceStates | GuildPresences | GuildMessages | GuildMessageReactions

Your bot should not be able to connect to the gateway without having the privileged intent enabled.

#

Can't reproduce with discord.js using {ws: {version: 8, intents: ['GUILDS']}}; it does receive the GUILD_CREATE events on connect.

The presence intent switch was on in the dev portal, I turned it off and there was no change. However, when I turned it off, there was a red "500 Internal Server Error" box in the dev portal. After reloading, the switch is still off.

ss

chilly siloBOT
chilly siloBOT
#
To specify these intents in your `IDENTIFY` payload, you must visit your application page in the Developer Portal and enable the toggle for each Privileged Intent that you wish to use. If your bot qualifies for [verification](https://dis.gd/bot-verification, you must verify your bot and turn on the checkboxes for the intents you want in the form. If your bot is already verified and you need to request additional privileged intents, [contact support](https://dis.gd/support).
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

With yesterday's change to intents, providing previous states is a necessity.

With the tools currently available, having every member in cache is necessary for many bots. Many moderation, logging, and utility bots need to know a user's previous username, nickname, avatar, etc when they get updated, and the only way to get that information is to have the old values cached.

A bot that previously took a few minutes to load this cache now takes several hours, which is an unreasonable amoun...

chilly siloBOT
chilly siloBOT
#

All bots with the members intent should be able to get a full member cache within 10 minutes of startup assuming ~1000 guilds/shard. There's no reason on Discord's end it should take any longer than this.
I'm not saying 10 minutes isn't a long time, but it is vastly shorter than several hours.

Sounds nice in theory, but the practice is often the exact oposite.
10 minutes is a pretty low number. Especially for bots with large numbers of shards is this quite unrealistic as not every guild ...

chilly siloBOT
chilly siloBOT
#

To clarify a few things. The hours of time for startup are caused by the usage of old chunking features which no longer work on v6 and v8. The reason it takes so long to load is that the requests for 50 guilds will only return the members of 1 guild. The other 49 guilds then timeout and retry the request after 10 seconds (in JDA).

So the time for startup can be calculated:

2500 * 10 seconds = 25000 seconds = 7 hours

I have updated JDA to no longer use this old chunking even when inte...

#

Assume a bot on 25 thousand servers that can see roughly 20 million unique users (approximate numbers from one of my own bots). Each chunk can contain up to 1000 users, and chunks can be requested 120 times per minute. Therefore, in the ideal case where there are no users with more than one mutual server with the bot, it would take approximately 20000000 / 1000 / 120 = 166.67 minutes to fill the cache, which is nearly 3 hours. If my math is correct, this seems unreasonably long for a bot to r...

#

@jagrosh your math is not correct tough, you can request them for up to 115 guilds per minute (to leave headroom for heartbeats), and you will get multiple chunks back per guild as needed. your need to calculate it based on servers and not member counts.

also multiple shards are independant so you can requests guilds on multiple shards at the same time

so to calculate the time it would be <number of guilds> / (115 * <num shards>)

chilly siloBOT
#

Description

Occasionally voice channels cannot be deleted without the "Connect" permission - but not always. In 2 guilds with identical permissions, one may require the "Connect" permission, and one may not.

Steps to Reproduce

God knows - all I know is that it is reproducible since someone else ran into the same issue ~2 years ago.

Expected Behavior

Voice channels should be deletable with just the "manage channels" permission, since only the manage channels per...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description
Gateway v6 has a bug with Opcode 8 requests, where it only accepts the first guild in the guild_id array of that payload. The bot has been whitelisted for both guild members and guild presences intent.

Steps to Reproduce

  1. Connect to the gateway on v6
  2. Wait for all the guild_creates to finish.
  3. Send a opcode 8 requesting members for all the guilds that are bigger than the large_threshold.

Expected Behavior
I would get member chunks for every sin...

chilly siloBOT
#

Adding to this, could we allow querying by role ID(s)? With the recent gateway changes and upcoming changes to similar HTTP endpoints, most bots won't have a local cache to query and finding members with a specific role will be fairly difficult without either storing all member -> role mappings locally or fetching the entire member list, both of which aren't desirable, and scales poorly as servers grow larger and larger. Expected use cases might include finding moderators on a server or manag...

chilly siloBOT
#

Description

When sending non-numeric IDs/Snowflakes for gateway opcode 8 (Request Guild Members), the gateway hangs for a few seconds after which opcode 9 (Invalid Session) is returned. I believe the gateway should be able to recover gracefully.

Steps to Reproduce

  1. Send opcode 8 with non-numeric user_ids. For example:
{
  op: 8,
  d: {
    guild_id: '[REDACTED]',
    presences: false,
    user_ids: [ 'a' ],
    query: null,
    nonce: '1756ebb1e21',
    li...
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

this is the error log :

 config: {
    url: 'https://discord.com/api/oauth2/token',
    method: 'post',
    data: 'client_id=00000000000&client_secret=secret-0-0-0-&grant_type=authorization_code&code=mycode&redirect_uri=https%3A%2F%myredirect-uri.com%2Foauth2%2Fendpoint',
    headers: {
      Accept: 'application/json, text/plain, */*',
      'Content-Type': 'application/x-www-form-urlencoded',
      'User-Agent': 'axios/0.21.0',
      'Content-Length': 236
    }

...
chilly siloBOT
#

As an alternative, I would consider having the bot create a guild (or creating one yourself and inviting the bot) and uploading emojis there

Just to mention there are drawbacks to doing that, such as the 100 server limit for users, bots can't create servers if they are in more than 10 servers and if you are planning to get verified for intents it can be seen as suspicious or inorganic growth since the bot will need to be in several servers owned by the same user to allow using th...

chilly siloBOT
#

it can be seen as suspicious or inorganic growth since the bot will need to be in several servers owned by the same user

I would say this isn't something to be concerned about -- it's expected that the bot will be in a one or two (maybe even three) servers owned by the bot's creator, as there can be legitimate purposes to doing so. It's only when the bot starts being in dozens of servers owned by the bot owner that it might become suspicious -- and even then, there may be legitimate reas...

chilly siloBOT
#

@BannerBomb Yes, if you want to play a card game with your bot, and want to use emotes, you will have to create more than one server to use all emotes.

What I want with this emote scheme, is that you can make an API request, and return all available emotes to the bot. This would make using emotes much easier.
Having this form of <emote: id> to use emotes, makes messages very polluted, and you also can't remember that,
every time you have to get a reference to use the emotes.

#

However, if you find yourself needing that many emoji, I would recommend finding another solution. For example, with Blackjack, you might consider using the ♠️ ♣️ ♥️ ♦️ emoji that Discord includes by default, plus a number next to it. So for a One of Hearts, you might put ♥️1. Alternatively, make the symbols and the card number separate emoji -- that would still be a decent amount of emoji (18 including Joker, by my count), but it would be far less than you needed before (and would be e...

chilly siloBOT
#

@Cristian-Sknz I mean... you're using Discord's bandwidth. You're asking them to let you store your assets on their servers, and they're letting you, up to a point. Discord is paying for the bandwidth and storage your bot's emoji use, so the least you could do is be considerate and limit how much you're using -- or help cover some of the costs by purchasing boosts, which get you extra emoji slots as a bonus. I really don't think "It's only for bots to use" is a good reason to say otherwise.

#

Some updates (that I will edit into the original comment as well):

  • channel_id is now optional on a message reference, meaning the only mandatory field is message_id
  • You can still only reply to a message within the same guild and channel
  • If you send channel_id, we will validate it (@meishuu why would anyone do this 🤔 )

Additionally, replies by default mention the user being replied to. There are some additions to the allowed_mentions object to change this behavior:

  • `...
#

I would say this isn't something to be concerned about. It's expected that the bot will be in a one or two (maybe even three) servers owned by the bot's creator, as there can be legitimate purposes to doing so. It's only when the bot starts being in dozens of servers owned by the bot owner that it might become suspicious -- and even then, there may be legitimate reasons for that being the case. That's why there's the ability for Discord to do a manual review -- because a human can understan...

#

@LikeLakers2 staff can't bypass the growth flags, and someone actually ran into the growth flag because of emoji servers for their bot (they kicked the bot from the servers and made it send messages through webhooks as a workaround)

Something similar happened with the bot Loritta, had to increase the rate limit for this bot, because it was taking the global rate limit almost every day, and it wasn't the bot's fault, the reason was because the bot ...

#

Are there any plans on making it able to reply to out of channel stuff? It seems very yes and very no at the same time, it'd be nice to know what's going on (like are you still discussing it etc.)?

No, a reply can only be sent as a reply to a message in that same channel.

I can see how that was confused when channel_id was required, but it no longer is, which should help clear it up as well.

#

I feel like that happened to my bot also tbh but we are only using like 3 servers for emotes, most of the rest are all from unique owners 🤷 . But you can't use webhooks for everything like again for games. You can't edit a webhook message to update the results to keep the chat clean instead of sending separate message for each result of the game afaik and each webhook is locked to a single channel unless you update the webhook to use another channel. I would hate to use webhooks to send mess...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Hi. For several days now, my bot has been growing with many problems that are definitely not on my side.

  • the bot cannot see that the user has joined any server. As if Discod's API didn't pass all the data to my bot (guildMemberAdd). Meanwhile, 0 errors in the console. Script:
    client.on("guildMemberAdd", async (member) => { // ... });
  • sometimes the bot has a problem finding users / channels
  • Occasionally I see the following errors on my console
    a) Response: Internal Server ...
chilly siloBOT
#

Hi, from October 27, after 4 months my bot stopped working as it should, because it started to display error in the console:

„ TypeError: Cannot read property 'hasPermission' of null”.

The bot code has not been changed for weeks, and the bot itself does not respond to commands that require permissions. I did not find any help on the internet that would work, what should I do?

#

On October 7, Discord started enforcing bot verification and some intents restrictions. It seems that the remaining restrictions are now enforced. Despite our best efforts to streamline this transition for you, some of these changes are not negotiable and require individual action. Please read the discord gateway update FAQ

what should I do in this situation, if I don't want to change the bot code, wait?

chilly siloBOT
#

Description

A few days ago, discord has enforced the intents limitations on v6. This means that the old request guild members functionality, of passing more than 1 guild per request is no longer supported.

Instead of ignoring the other guilds I see 2 better alternatives:

  1. Send chunks for all of the guilds, but slower (this would result in the same but without breaking existing libs)
  2. Close the socket with an invalid payload OP code 4001 (this would not be a silent ...
chilly siloBOT
#
  • channel_id is now optional on a message reference, meaning the only mandatory field is message_id

This... is tricky. As far as the backend model is concerned, all message references have channel_id required, as was previously documented.

However, when provided for message creation, we enforce a different structure in which message_id is required instead of optional, and channel_id is optional instead of required. It technically has the same fields, just different optiona...

chilly siloBOT
chilly siloBOT
#

I am not sure what do you mean under library, but I am using nodejs and here is my package.json:
`{
"name": "dcbot",
"version": "1.0.0",
"description": "",
"main": "Discord.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"body-parser": "^1.19.0",
"discord.js": "^11.5.1",
"express": "^4.17.1",
"form-data": "^2.5.0",
"mysql": "^2.17.1",
"node-fetch": "^2.6....

chilly siloBOT
#

Hello, I just updated to version 12 but when I am trying to add or remove role with new command message.member.roles.remove('1231654414654446'); I am getting this warning and role is unable to be added or removed:
(node:23184) UnhandledPromiseRejectionWarning: TypeError [INVALID_TYPE]: Supplied roles is not a Role, Snowflake or Array or Collection of Roles or Snowflakes.
Can you please help me? Thanks

chilly siloBOT
#

The original contract that was communicated to us was that one guild per request would only be enforced if we passed in the intent key. Everyone who develops a library also states that this was what was communicated to us.

Breaking our libraries that don't pass the intents key was not communicated to us in any capacity. I think this change should be reverted if you don't pass the intents key so it can work just like it used to without breaking every old client out there.

chilly siloBOT
#

Description
When browsing to a URL that doesn't exist under https://discord.com/developers/docs/, such as , the page will appear to load to the normal dark background, and show the loading circle that normally appears on the right half, but will stay at this point indefinitely. No page will load, not even a 404 page -- but importantly, nothing will appear on the left panel usually used for navigation either.

A wrong URL is usually the result of user error when typing in the URL ...

chilly siloBOT
#

i get this error when i run node ./src/bot.js and i dont found my answer on the all issues
UnhandledPromiseRejectionWarning: FetchError: request to https://discord.com/api/v7/gateway/bot failed, reason: connect ETIMEDOUT 10.10.34.35:443
at RequestHandler.execute (D:\MyDiscordBot\node_modules\discord.js\src\rest\RequestHandler.js:93:15)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async RequestHandler.push (D:\MyDiscordBot\node_modules\discord.js\src\r...

chilly siloBOT
#

Description

As it currently stands, Channel Updates have 4 (or 3?) distinct criteria for hitting a rate limit. For those who are unaware, the main one to note is that channel name / topic changes now fall under a 2 requests every 10 minutes. Attached is the announcement made by Mason, and link is: #api-announcements message

![image](https://user-images.githubusercontent.com/17960496/97713343-62e6b400-1ac8-11...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

User activity is null

When I call "username".activities I get a list of activities I had, but 1 week ago my bot without any actions from my side
just broke.

Expected Behavior

To get a list of user activities
Some time before I updated discord packages when tranfer bot on server, and I caught the same bug, then downgrade to the old version using my work PC.

In addition. Now I write the bot by recommendadation on java "JDK" and the bug even there.

What I think. There...

chilly siloBOT
#

It would be nice to be able to specify reactions in the message create payload for bots that incorporate a lot of reaction based controls. Currently, it takes many API requests and a few seconds to add a few reactions to a message: Allowing them to be provided in the message create payload would reduce this to a single request and also enable users to start controlling the bot faster after issuing s command.

chilly siloBOT
#

Hi, these are two different small changes that I figured should both be made under the same PR.

The first change is that RFC 7009, "OAuth 2.0 Token Revocation", is mentioned next to the Revocation URL. I did this because RFC 6749 is linked just above, for those implementing OAuth2 from scratch -- so knowing how to implement token revocation would be good for them to know too.

The second change is more of a nitpick. It mentions how you should use Basic authentication when using the Clien...

#

Something to this effect was already rejected here: https://github.com/discord/discord-api-docs/issues/182#issuecomment-262388833 and here: https://github.com/discord/discord-api-docs/issues/1301 and is also a bit pointless to add at this point as there will be a future API update for proper buttons, inputs, etc. See this blog post: https://blog.discord.com/the-future-of-bots-on-discord-4e6e050ab52e

chilly siloBOT
#

Description

Just 2 weeks ago, the code below worked. That is, I write "!my_command 0000000000000000" to the chat, and then the bot returns its nickname and tag to the console in the format "user_name#0000".

Now, when I run the same code, i can specify any id but, the bot always returns None to the console. At the same time, nothing has changed at all, users did not change their nickname (although the id does not depend on this), and even more so did not delete their acco...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

I used discord regularly and from 1 day to another it would not start and came up with the message i have attached as a file...

Is there anyone who have experienced this issue? and how do i overcome it, so i can have the discord available for my pc again.
(i tried uninstalling it, and install it again to see if it helped but did not).
discord error

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Added aegis.cpp's server invite, and invites to DAPI channels for libs without support servers.
Maybe we should put different text for dapi links? idk

| [aegis.cpp](https://github.com/zeroxs/aegis.cpp)             | C++        | [Invite](https://discord.gg/w7Y3Bb8)          |
| [discordcr](https://github.com/discordcr/discordcr)          | Crystal    | [Invite](https://discord.gg/puaxPkK)          |
| [Discord.Net](https://github.com/RogueException/Discord.Net) | C#      ...
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Because of the recent update of Discord in v8, my Discord Bot no longer works properly.
I'm trying to retrieve the number of users having a specific role

    const memberCount = guild.memberCount; // Still works
    const membersFromGryffindor = guild.roles.cache.get(metadata.gryffindor.role_id).members.size; // No longer works (got 0 but no error)

Does someone knows how to fix it ? I couldn't find anything on official documentation...
Thanks in advance

chilly siloBOT
#

I'm currently writing a bot and I've run into an issue when trying to run it. It is telling me that it cannot connect to the host (discord.com:443). It says that it is a certificate error, which it is, but I have no idea how to fix it. I've gone on multiple forums that have said to go to https://crt.sh/?id=1 and download the certificate, but I'm not going to trust something straight of the internet like that, plus, I'm not well versed in cybersecurity. Any help is greatly appreciated

T...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

This partial deployment limbo is quite a headache.

Unless I'm missing something here this is still not documented (which already halts the implementation for us as we choose to not merge any features that are not documented to keep our sanity and semantic versioning promises).

The guild deploy is another aspect that's quite hard to plan around: If it happened/happens this can all be convenience getters, which don't require API requests. If we can not rely on this we don't really have a ...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description
I'd like to request an API endpoint for bulk-editing the voice permissions of users in a particular voice channel.

Essentially, a bulk version of PATCH/guilds/{guild.id}/members/{user.id}, but purely for server-mute and server-deafen.

Why This is Needed
I maintain one of several bots designed to automate voice channels for users playing Among Us. The biggest hurdle faced by my bot, as well as [my mai...

chilly siloBOT
chilly siloBOT
#

Hi. I'm just going to be upfront and say that I'm not sure this would get through, regardless of whether these changes were made for clarity's sake.

I say this because Discord has previously closed #2127, an issue making a single change like the one in this (because of concerns of being hard to understand), because they want their docs to give off the tone of a (quote) "playful and fun brand that doesn't take o...

chilly siloBOT
#

@tpcstld Thanks for the merge. I was actually about to make one final change, though (before my internet decided to die) -- the warning below the table was going to be changed to reference the token revocation URL, rather than just the token URL, as both of them seem to require the x-www-form-urlencoded content type.

> warn
> In accordance with the relevant RFCs, the token and token revocation endpoints will **only** accept a content type of `x-www-form-urlencoded`. JSON co...
chilly siloBOT
#

Hi! This is a small change that I was going to make over at #2194, however the PR was merged before I could make it. So it's going in its own PR.

I opted to remove the URL to the URLs table, as this warning is right below it. I also removed the references to the RFCs, as we are now referencing URLs that are from two different RFCs (and it'd be awkward to change that warning every time a new OAuth2 endpoint is added).

chilly siloBOT
#

Hi! I was notified in the Discord API server, some time after my last PR was merged, that the OAuth2 Token endpoint supports submitting parameters as Content: multipart/form-data. After testing this for myself and verifying that this was the case, I found myself confused -- this seems to be flying in the face of the relevant RFC (RFC 6749), which always says to use application/x-www-form-urlencoded.

I thought it might of been a quirk of how Discor...

chilly siloBOT
#

This is likely due to a quirk of our API framework. For POST requests with values, the framework automatically accepts and parses both kinds of content type.

I haven't consulted with others yet (it's late here), but I would consider this to be an un-intentional error in the API. I would encourage people to use x-www-form-urlencoded, and we will probably only "officially" support that version. However I believe this is probably not a high-priority fix (?), unless I'm missing something i...

chilly siloBOT
#

Thank you -- even if it might not be fixed (though I kind of hope it is at some point -- I like things staying to spec, personally), it's nice to have an answer.

The only thing I can think of regarding allowing form-data for this (even if unintentionally) is that it may require the API to receive somewhat more data from the client. You can see an example of how form-data sends stuff here, just in case anyone ...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

As it currently stands, Channel Updates have 4 (or 3?) distinct criteria for hitting a rate limit. For those who are unaware, the main one to note is that channel name / topic changes now fall under a 2 requests every 10 minutes. Attached is the announcement made by Mason, and link is: #api-announcements message

image

Thus, Channel Updates have several possibilities to reach a 429

Just a name change => 2 every 10 minut...

chilly siloBOT
chilly siloBOT
#

I can't figure out what these params mean. At first, I assumed it meant I could tie an invite to a specific user, which is exactly what I was trying to do (so sharing the link would require logging in as that user). But it seems like this is for something else because passing target_user or target_user_id doesn't work (the former doesn't throw an error but doesn't change anything, the latter throws GUILD_INVITE_INVALID_TARGET_USER_ID.

{
    "max_uses": 1,
    "unique": tru...
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description

When a bot has no 'Embed Link' permissions he should still be able to send embed messages.
When a user turned off 'Show website preview info from links posted into chat' setting, it should still show embeds of webhooks and bots

Why This is Needed

I guess that this permission/setting was added to prevent abuse of link embeds by server members eg. NSFW Content. For bots, it doesn't make sense, because most of them depend on embeds to provide full functionality.
Th...

#

This doesn't make sense, as embeds act like a link to a client. I personally discourage them for this reason, and recommend people to use code blocks with a language like adoc:

===== LEADERBOARD =====
 1 :: someName
 2 :: anotherName
 3 :: (none)
 4 :: (none)
 5 :: (none)
 6 :: (none)
 7 :: (none)
 8 :: (none)
 9 :: (none)
10 :: (none)
``` (the `::` has special highlighting in Discord)
#

Bots should not get special treatment when it comes to embedding for users. If a user does not want to receive embeds and previews, the client will always respect that. As far as permissions, the solution to this is for a server admin to give the bot the permissions it needs - so make sure to request those permissions in the bot's invite. If the admins don't want embeds, again, it's their choice, bots should not bypass user permissions and choices.

#

For bots, it doesn't make sense, because most of them depend on embeds to provide full functionality.

Bots should never rely on having any permission (except maybe send messages -- bots will almost always have that one), as their permissions can be edited at any time. If a bot is asked to do something that it doesn't have permission for, it should be ask to be given that permission.

With that said, I'm not sure I understand this "needed for full functionality" argument either. While l...

#

I personally discourage them for this reason, and recommend people to use code blocks with a language like adoc:

Code blocks have way fewer features and look worse. Especially working with images is a key feature of embeds. Messages don't allow editing images, but embeds do.
Without embeds, developer have way fewer options to display information

Bots should not get special treatment when it comes to embedding for users. If a user does not want to receive embeds and previews, the ...

#

For my bot, wrong permission setup is the top 1 issue in support even through my bot already providing help for permissions.

I think you misunderstood my response.

If someone hasn't given your bot something like Manage Roles when it needs Manage Roles, that's a different story. If you're having issues with your users being unable to set up permissions even when given instructions to, that's a different story.

What I am saying is that you should never rely on Embed Links just t...

#

Bots should never rely on having any permission (except maybe send messages -- bots will almost always have that one), as their permissions can be edited at any time. If a bot is asked to do something that it doesn't have permission for, and you absolutely need that permission for that action, it should be ask to be given that permission.

The current way to solve this issue is by telling the user, that he should grant those specific permissions. As mentioned in my comment above, many us...

#

The comment you quote was just a response to eslachance and thetayloredman

My bad, I somehow misread the quote. >_< Sorry.

The current way to solve this issue is by telling the user, that he should grant those specific permissions.

That's one way to solve it, but personally I wouldn't rely on having Embed Links just to be able to generate a response. Needing a permission that sounds like it's related to links, when you're not sending links in response, can really confuse users. ...

#
  • Add a fallback parameter which bots can populate, similar to the noscript html element

Now this does seem like a good idea, so bots can use embeds, without the worry of having it disabled where it can have a fallback message (or code block for my use case). And, perhaps splitting EMBED_LINKS into something like USE_LINK_PREVIEWS and SEND_EMBEDS? (with a different name of course)

chilly siloBOT
#

Yeah, those do make embeds look nice, but I still wouldn't rely on them. Everything you mentioned (and everything I can think of on top of that) sounds like it's ultimately "a nice thing to have" rather than "absolutely needed". If you are able to send embeds, go ahead and use those features -- but don't make the functionality of your bot hinge on the permission.

I and other people don't depend on them but switching to normal text would drastically decrease the usability. Usability is a ...

chilly siloBOT
#

How can I fix this error sent by the console?

data: index.js:4128 - Niespodziewana Odmowa. { DiscordAPIError: Unknown Message
data: index.js:4128 - at item.request.gen.end (/home/exbot/node_modules/discord.js/src/client/rest/RequestHandlers/Sequential.js:85:15)
data: index.js:4128 - at then (/home/exbot/node_modules/snekfetch/src/index.js:215:21)
data: index.js:4128 - at process._tickCallback (internal/process/next_tick.js:68:7)
data: index.js:4128 - name: ...

chilly siloBOT
chilly siloBOT
#

Greetings,

After a few recent updates, I'm unable to click on any link placed in Discord (be it through "open original" or clicking on the link itself depending on the type of linked content).

I can't really reproduce the issue and am not well versed in programming to give you proper details, but I was hoping you could look into the problem and tell me what I need to provide to help you gain more insight into the issue.

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description

When a bot is already part of a guild and a bot scoped oauth request is received, it should not require a captcha.

Why This is Needed

If the bot is missing permissions at the guild level, a bot invite link can be quickly used to grant the missing permissions in bulk without needing to go to the role menu.

Alternatives Considered

  • Telling the user to give the bot more permissions. This is the current solution, but some people don't understand Disco...
chilly siloBOT
#

Description

Complementing #2216, it would be great if the channel_id parameter already possible for webhook.incoming was available for the bot scope. If given in combination with the guild_id parameter, it would create a user level override granting the permissions you have selected. This of course would only be available when the bot is already in the guild (I guess this is optional, but would be a little weird otherwise.)

Why This is Needed

This would provide a simp...

chilly siloBOT
#

Description
The client uses this endpoint to get the album and artist IDs of a user's Spotify song to load the URLs in the browser.
Currently, bots cannot use this endpoint, but it doesn't seem to be an issue to let bots with the Presence intent use it.

Why This is Needed
Currently, Discord can make the Spotify album and artist names links, but bots can't. This isn't really needed but would be nice to have.

Alternatives Considered
Sending the additional IDs in the norm...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

I have another use case for this:
<img width="429" alt="Screenshot 2020-11-07 at 19 53 58" src="https://user-images.githubusercontent.com/13135287/98449333-fce6d600-2132-11eb-99c6-5e407254c201.png">
what you see is results from a search tool for deno modules; i was hoping to be able to add links for the modules to the name of the fields, but then sadly found out that such isnt possible.

chilly siloBOT
chilly siloBOT
#

Hi!

While chatting within the Discord API server, it was noted that the Token Exchange step requires a scope parameter, though the RFC does not specify a scope parameter as needed during the token exchange. After doing some testing, I found that the Token Exchange step outright ignores the scope parameter. I have thus removed the scope parameter from the Token Exchange documentation.

I've also taken this opportunity to update th...

chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
chilly siloBOT
#

Description
Attachments that have been uploaded to channel that got deleted are not being removed from Discord CDN.

Steps to Reproduce
• Create a text channel or choose an existing one
• Post a message with attachment
• Copy link to that attachment
• Delete that channel
• Visit that link you copied. Attachment is still on Discord CDN.

Expected Behavior
Attachment should be deleted from Discord CDN.

Current Behavior
Attachment isn't deleted from Discord CDN.

...

chilly siloBOT
chilly siloBOT
chilly siloBOT
#

!!English Below!!

Türkçe
Emir lütfen gerekli yerleri düzgün ve detaylı bir şekilde doldur aksi takdirde ne demek istediğin anlaşılamayacaktır ayrıca lütfen sadece İngilizce yazman gerekiyor buraya bakan çoğu kişi Türkçe bilmemekte.

English
Emir, please fill in the required fields properly and in detail otherwise what you mean will not be understood. Also please write only in English. Most people who look here do not speak Turkish.

#

What I mean is this: My bot's profile picture doesn't change. I'll put
another photo, it doesn't work. One, there is an error. Do you have to
Thank you :))

8 Kas 2020 Paz 19:38 tarihinde Zamion101 notifications@github.com şunu
yazdı:

!!English Below!!

Türkçe
Emir lütfen gerekli yerleri düzgün ve detaylı bir şekilde doldur aksi
takdirde ne demek istediğin anlaşılamayacaktır ayrıca lütfen sadece
İngilizce yazman gerekiyor buraya bakan çoğu kişi Türkçe bilmemekte.

*Englis...

#

What I mean is this: My bot's profile picture doesn't change. I'll put another photo, it doesn't work. One, there is an error. Do you have to Thank you :))

Don't comment your problem. You need to fill in the required fields (like Description, Steps to Reproduce, Expected Behavior and so on) properly and in detail! Please edit your Issue or delete and open new one with properly and in detail.

#

Ok. Thanks :)

8 Kas 2020 Paz 19:51 tarihinde Zamion101 notifications@github.com şunu
yazdı:

What I mean is this: My bot's profile picture doesn't change. I'll put
another photo, it doesn't work. One, there is an error. Do you have to
Thank you :))

Don't comment your problem. You need to fill in the required fields (like
Description, Steps to Reproduce, Expected Behavior and so on)
properly and in detail! Please edit your Issue or delete and open new one
with properly...

#

Very İmportant!!

Huh .. Bot, I was changing your avatar. I want to change the profile photo
of my bot. Not happening. There is a problem. How can I do it? Do you
understand? Thank you :)) :((

8 Kas 2020 Paz 19:55 tarihinde SinisterRectus notifications@github.com
şunu yazdı:

You need to use the Modify Current User endpoint. Changing the
application's avatar may not change the bot's avatar.


You are receiving this because you authored the thread.
Reply to this email directly, ...

#

I want to change this, it doesn't change. There is a bug. I need help.
Thank you :)) :((

8 Kas 2020 Paz 19:55 tarihinde SinisterRectus notifications@github.com
şunu yazdı:

You need to use the Modify Current User endpoint. Changing the
application's avatar may not change the bot's avatar.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/discord/discord-api-docs/issues/2223#issuecomment-723634093,
...