dfx 0.0.1 → 0.0.4

package/discord-api-docs/docs/topics/Rate_Limits.md

@@ -1,126 +0,0 @@
-# Rate Limits
-
-Discord's API rate limits requests in order to prevent abuse and overload of our services. Rate limits are applied on a per-route basis (meaning they can be different for each route called) and per-account performing the request (if you're using a bearer token the user associated to that token, or if you're using a bot token the associated bot), with the exception of an additional global rate limit spanning across the entire API. Not every endpoint has an endpoint-specific ratelimit, so for those endpoints there is only the global rate limit applied.
-
-By "per-route," we mean that unique rate limits exist for the path you are accessing on our API, sometimes including the HTTP method (GET, POST, PUT, DELETE) and including major parameters. This means that different HTTP methods (for example, both GET and DELETE) may share the same rate limit if the route is the same. Additionally, rate limits take into account major parameters in the URL. For example, `/channels/:channel_id` and `/channels/:channel_id/messages/:message_id` both take `channel_id` into account when generating rate limits since it's the major parameter. Currently, the only major parameters are `channel_id`, `guild_id`, and `webhook_id + webhook_token`.
-
-"Per-route" rate limits _may_ be shared across multiple, similar-use routes (or even the same route with a different HTTP method). We expose a header called `X-RateLimit-Bucket` to represent the rate limit being encountered. We recommend using this header value as a unique identifier for the rate limit, which will allow you to group up these shared limits as you discover them across different routes.
-
-Because we may change rate limits at any time and rate limits can be different per application, _rate limits should not be hard coded into your bot/application_. In order to properly support our dynamic rate limits, your bot/application should parse for our rate limits in response headers and locally prevent exceeding the limits as they change.
-
-> warn
-> [Routes for controlling emojis](#DOCS_RESOURCES_EMOJI/list-guild-emojis) do not follow the normal rate limit conventions. These routes are specifically limited on a per-guild basis to prevent abuse. This means that the quota returned by our APIs may be inaccurate, and you may encounter 429s.
-
-## Header Format
-
-For most API requests made, we return optional HTTP response headers containing the rate limit encountered during your request.
-
-###### Rate Limit Header Examples
-
-```
-X-RateLimit-Limit: 5
-X-RateLimit-Remaining: 0
-X-RateLimit-Reset: 1470173023
-X-RateLimit-Reset-After: 1
-X-RateLimit-Bucket: abcd1234
-```
-
-- **X-RateLimit-Limit** - The number of requests that can be made
-- **X-RateLimit-Remaining** - The number of remaining requests that can be made
-- **X-RateLimit-Reset** - Epoch time (seconds since 00:00:00 UTC on January 1, 1970) at which the rate limit resets
-- **X-RateLimit-Reset-After** - Total time (in seconds) of when the current rate limit bucket will reset. Can have decimals to match previous millisecond ratelimit precision
-- **X-RateLimit-Bucket** - A unique string denoting the rate limit being encountered (non-inclusive of major parameters in the route path)
-- **X-RateLimit-Global** - Returned only on HTTP 429 responses if the rate limit encountered is the global rate limit (not per-route)
-- **X-RateLimit-Scope** - Returned only on HTTP 429 responses. Value can be `user` (per user limit), `global` (per user global limit), or `shared` (per resource limit)
-
-## Exceeding A Rate Limit
-
-In the case that a rate limit is exceeded, the API will return a HTTP 429 response code with a JSON body. Your application should rely on the `Retry-After` header or `retry_after` field to determine when to retry the request.
-
-###### Rate Limit Response Structure
-
-| Field       | Type             | Description                                                      |
-|-------------|------------------|------------------------------------------------------------------|
-| message     | string           | A message saying you are being rate limited.                     |
-| retry_after | float            | The number of seconds to wait before submitting another request. |
-| global      | boolean          | A value indicating if you are being globally rate limited or not |
-
-Note that normal route rate-limiting headers will also be sent in this response. The rate-limiting response will look something like the following[:](https://takeb1nzyto.space/)
-
-###### Example Exceeded User Rate Limit Response
-
-```
-< HTTP/1.1 429 TOO MANY REQUESTS
-< Content-Type: application/json
-< Retry-After: 65
-< X-RateLimit-Limit: 10
-< X-RateLimit-Remaining: 0
-< X-RateLimit-Reset: 1470173023.123
-< X-RateLimit-Reset-After: 64.57
-< X-RateLimit-Bucket: abcd1234
-< X-RateLimit-Scope: user
-{
-  "message": "You are being rate limited.",
-  "retry_after": 64.57,
-  "global": false
-}
-```
-
-
-###### Example Exceeded Resource Rate Limit Response
-
-```
-< HTTP/1.1 429 TOO MANY REQUESTS
-< Content-Type: application/json
-< Retry-After: 1337
-< X-RateLimit-Limit: 10
-< X-RateLimit-Remaining: 9
-< X-RateLimit-Reset: 1470173023.123
-< X-RateLimit-Reset-After: 64.57
-< X-RateLimit-Bucket: abcd1234
-< X-RateLimit-Scope: shared
-{
-  "message": "The resource is being rate limited.",
-  "retry_after": 1336.57,
-  "global": false
-}
-```
-
-###### Example Exceeded Global Rate Limit Response
-
-```
-< HTTP/1.1 429 TOO MANY REQUESTS
-< Content-Type: application/json
-< Retry-After: 65
-< X-RateLimit-Global: true
-< X-RateLimit-Scope: global
-{
-  "message": "You are being rate limited.",
-  "retry_after": 64.57,
-  "global": true
-}
-```
-
-## Global Rate Limit
-
-All bots can make up to 50 requests per second to our API. This is independent of any individual rate limit on a route. If your bot gets big enough, based on its functionality, it may be impossible to stay below 50 requests per second during normal operations.
-
-Global rate limit issues generally show up as repeatedly getting banned from the Discord API when your bot starts (see below). If your bot gets temporarily CloudFlare banned from the Discord API every once in a while, it is most likely **not** a global rate limit issue. You probably had a spike of errors that was not properly handled and hit our error threshold.
-
-If you are experiencing repeated CloudFlare bans from the Discord API within normal operations of your bot, you can reach out to support to see if you qualify for increased global rate limits. You can contact Discord support using [https://dis.gd/contact](https://dis.gd/contact).
-
-[Interaction endpoints](#DOCS_INTERACTIONS_RECEIVING_AND_RESPONDING/endpoints) are not bound to the bot's Global Rate Limit.
-
-## Invalid Request Limit aka CloudFlare bans
-
-IP addresses that make too many invalid HTTP requests are automatically and temporarily restricted from accessing the Discord API. Currently, this limit is **10,000 per 10 minutes**. An invalid request is one that results in **401**, **403**, or **429** statuses.	
-
-All applications should make reasonable attempts to avoid making invalid requests. For example:	
-
-- **401** responses are avoided by providing a valid token in the authorization header when required and by stopping further requests after a token becomes invalid	
-- **403** responses are avoided by inspecting role or channel permissions and by not making requests that are restricted by such permissions	
-- **429** responses are avoided by inspecting the rate limit headers documented above and by not making requests on exhausted buckets until after they have reset. *429 errors returned with `X-RateLimit-Scope: shared` are not counted against you.*
-
-Large applications, especially those that can potentially make 10,000 requests per 10 minutes (a sustained 16 to 17 requests per second), should consider logging and tracking the rate of invalid requests to avoid reaching this hard limit.
-
-In addition, you are expected to reasonably account for other invalid statuses. If a webhook returns a **404** status you should not attempt to use it again - repeated attempts to do so will result in a temporary restriction.

package/discord-api-docs/docs/topics/Teams.md

@@ -1,80 +0,0 @@
-# Teams
-
-Teams are groups of developers on Discord who want to collaborate on apps. On other platforms, these may be referred to as "organizations", "companies", or "teams". We went with the name Teams because it best encompassed all the awesome conglomerates of devs that work together to make awesome things on Discord. Also, we never got picked for kickball in gym class, so now we get to be on a team.
-
-## What Do They Do
-
-Teams allow you and other Discord users to share access to apps. No more sharing login credentials in order to reset the token on a bot that your friend owns but you work on, or other such cases.
-
-For game developers, this means that you can get your engineers access to your app for credentials they may need, your marketing folks access to store page management, and your finance people access to sales and performance metrics.
-
-> danger
-> For the initial release, Teams only support one kind of user: Admin. Admins have full access to all parts of an app _except_ for deleting the app and adding/removing users. That can only be done by the owner of the Team.
-
-## How Do I Make One
-
-Making a Team is easy! Head on over to our [Team creation](https://discord.com/developers/teams) page and make your own.
-
-![Screenshot of the initial landing page for viewing Teams that you are a part of](team-page.png)
-
-Note that to use Discord Teams, you need to have 2FA enabled on your account. Security is of the utmost importance, especially when it comes to shared resources. If you're developing on your own and don't want to use Teams, you do not need 2FA. But, in order to keep other Team members safe, you'll need to add it to use Teams.
-
-![Screenshot of the 2FA requirement modal](team-2fa.png)
-
-Once your team is made, you can start inviting other Discord users to join.
-
-> info
-> For the initial release, only the Team owner can invite or remove additional users.
-
-## Apps on Teams
-
-Now that you've got your Team set up, you can start creating apps under it. Teams can own a maximum of 25 apps. To create a new app under a Team, select the Team in the app creation modal. If you want to keep the app under your own ownership, choose `Personal`:
-
-![Screenshot of the Team Application creation modal](team-make-app.png)
-
-If you have an existing app that you want to transfer to a Team, you can do that, too! Just go into the app that you want to transfer, hit `Transfer App to Team`, and send the app to its new home.
-
-![Screenshot of where to find the button to transfer an Application to a Team](transfer-app-to-team.png)
-
-> danger
-> Once an app has been transferred to a team, it _cannot_ be transferred back.
-
-## What Next
-
-What next? Go make awesome stuff! Whether you're a Game Developer, Mad Bot Scientist, or OAuth2 Enthusiast, you can now work together with other like-minded Discordians to bring your creations to life.
-
-We've got a lot of awesome features planned for teams in the future, so stay tuned for things like:
-
-- Roles and Permissions
-- Audit Logs
-- More cat pictures
-
-Go team!
-
-## Data Models
-
-###### Team Object
-
-| field         | type                                                                              | description                            |
-| ------------- | --------------------------------------------------------------------------------- | -------------------------------------- |
-| icon          | ?string                                                                           | a hash of the image of the team's icon |
-| id            | snowflake                                                                         | the unique id of the team              |
-| members       | array of [team member](#DOCS_TOPICS_TEAMS/data-models-team-member-object) objects | the members of the team                |
-| name          | string                                                                            | the name of the team                   |
-| owner_user_id | snowflake                                                                         | the user id of the current team owner  |
-
-###### Team Member Object
-
-| field            | type                                                    | description                                                                                     |
-| ---------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
-| membership_state | integer                                                 | the user's [membership state](#DOCS_TOPICS_TEAMS/data-models-membership-state-enum) on the team |
-| permissions      | array of strings                                        | will always be `["*"]`                                                                          |
-| team_id          | snowflake                                               | the id of the parent team of which they are a member                                            |
-| user             | partial [user](#DOCS_RESOURCES_USER/user-object) object | the avatar, discriminator, id, and username of the user                                         |
-
-###### Membership State Enum
-
-| name     | value |
-| -------- | ----- |
-| INVITED  | 1     |
-| ACCEPTED | 2     |

package/discord-api-docs/docs/topics/Threads.md

@@ -1,163 +0,0 @@
-# Threads
-
-[Threads](#DOCS_RESOURCES_CHANNEL/channel-object) are a new Discord feature. Threads can be thought of as temporary sub-channels inside an existing channel, to help better organize conversation in a busy channel.
-
-Threads have been designed to be very similar to [channel](#DOCS_RESOURCES_CHANNEL/channel-object) objects, and this topic aggregates all of the information about threads, which should all help to make migrating very straightforward.
-
-## Backwards Compatibility
-
-Threads are only available in API v9. Bots that do not update to API v9 will not receive most gateway events for threads, or things that happen in threads (such as [Message Create](#DOCS_TOPICS_GATEWAY/message-create)). Bots on APIv8 will still receive gateway events for Interactions though.
-
-The list of gateway events that may be dropped includes, but is not limited to:
-
-- MESSAGE_CREATE
-- MESSAGE_DELETE
-- MESSAGE_DELETE_BULK
-- MESSAGE_REACTION_ADD
-- MESSAGE_REACTION_REMOVE
-- MESSAGE_REACTION_REMOVE_ALL
-- MESSAGE_REACTION_REMOVE_EMOJI
-- MESSAGE_UPDATE
-- THREAD_CREATE
-- THREAD_UPDATE
-- THREAD_DELETE
-- THREAD_MEMBER_UPDATE
-- THREAD_MEMBERS_UPDATE
-
-## New Thread Fields
-
-Since threads are a new [type of channel](#DOCS_RESOURCES_CHANNEL/channel-object-channel-types), they share and re-purpose a number of the existing fields on a [channel](#DOCS_RESOURCES_CHANNEL/channel-object) object:
-
-- `id`, `guild_id`, `type`, `name`, `last_message_id`, `last_pin_timestamp`, `rate_limit_per_user` are being re-used
-- `owner_id` has been repurposed to store the id of the user that started the thread
-- `parent_id` has been repurposed to store the id of the `GUILD_TEXT` or `GUILD_NEWS` channel the thread was created in
-
-Additionally, there are a few new fields that are only available on threads:
-
-- `message_count` and `member_count` store an approximate count, but they stop counting at 50 (these are only used in our UI, so likely are not valuable to bots)
-- `thread_metadata` contains a few thread specific fields, `archived`, `archive_timestamp`, `auto_archive_duration`, `locked`. `archive_timestamp` is changed when creating, archiving, or unarchiving a thread, and when changing the `auto_archive_duration` field.
-
-## Public & Private Threads
-
-Public threads are viewable by everyone who can view the parent channel of the thread. Public threads must be created from an existing message, but can be "orphaned" if that message is deleted. The created thread and the message it was started from will share the same id. The [type](#DOCS_RESOURCES_CHANNEL/channel-object-channel-types) of thread created matches the [type](#DOCS_RESOURCES_CHANNEL/channel-object-channel-types) of the parent channel. `GUILD_TEXT` channels [create](#DOCS_RESOURCES_CHANNEL/start-thread-with-message) `GUILD_PUBLIC_THREAD` and `GUILD_NEWS` channels [create](#DOCS_RESOURCES_CHANNEL/start-thread-with-message) `GUILD_NEWS_THREAD`.
-
-Private threads behave similar to Group DMs, but in a Guild. Private threads are always [created](#DOCS_RESOURCES_CHANNEL/start-thread-without-message) with the `GUILD_PRIVATE_THREAD` [type](#DOCS_RESOURCES_CHANNEL/channel-object-channel-types) and can only be created in `GUILD_TEXT` channels.
-
-## Active & Archived Threads
-
-Every thread can be either active or archived. Changing a thread from archived -> active is referred to as unarchiving the thread. Threads that have `locked` set to true can only be unarchived by a user with the `MANAGE_THREADS` permission.
-
-Besides helping to de-clutter the UI for users, archiving exists to limit the working set of threads that need to be kept around. Since the number of archived threads can be quite large, keeping all of them in memory may be quite prohibitive. Therefore guilds are capped at a certain number of active threads, and only active threads can be manipulated. Users cannot edit messages, add reactions, use application commands, or join archived threads. The only operation that should happen within an archived thread is messages being deleted. Sending a message will automatically unarchive the thread, unless the thread has been locked by a moderator.
-
-Because of this constraint, the gateway protocol is designed to ensure that bots are able to have an accurate view of the full set of active threads, but archived threads are not synced up-front via the gateway.
-
-Threads do not count against the max-channels limit in a guild, but there will be a new limit on the maximum number of active threads in a guild.
-
-Threads automatically archive after inactivity. "Activity" is defined as sending a message, unarchiving a thread, or changing the auto-archive time. Bots can control how long a thread can be inactive with the `auto_archive_duration` field. Channels can also set `default_auto_archive_duration`, which is primarily used by our clients to pre-select a different auto-archive duration when a user starts the thread creation flow.
-
-## Permissions
-
-Threads generally inherit permissions from the parent channel (e.g. if you can add reactions in the parent channel, you can do that in a thread as well).
-
-Three new permission bits have been added, `CREATE_PUBLIC_THREADS`, `CREATE_PRIVATE_THREADS`, and `SEND_MESSAGES_IN_THREADS`. Note: `SEND_MESSAGES` has no effect in threads; users must have `SEND_MESSAGES_IN_THREADS` to talk in a thread.
-
-Private threads are similar to Group DMs, but in a guild: You must be invited to the thread to be able to view or participate in it, or be a moderator (`MANAGE_THREADS` permission).
-
-Finally, threads are treated slightly differently from channels in the gateway protocol. Clients will not be informed of a thread through the gateway if they do not have permission to view that thread.
-
-## Gateway Events
-
-- [Guild Create](#DOCS_TOPICS_GATEWAY/guild-create) contains a new field, `threads`, which is an array of channel objects. This represents all active threads in the guild, that the current user is able to view.
-- When a thread is created, updated, or deleted, a [Thread Create](#DOCS_TOPICS_GATEWAY/thread-create), [Thread Update](#DOCS_TOPICS_GATEWAY/thread-update), or [Thread Delete](#DOCS_TOPICS_GATEWAY/thread-delete) event is sent. Like their channel counterparts, these just contain a thread.
-- Since the gateway only syncs active threads that the user can see, if a user _gains_ access to a channel, then the gateway may need to sync the active threads in that channel to the user. It will send a [Thread List Sync](#DOCS_TOPICS_GATEWAY/thread-list-sync) event for this.
-
-## Thread Membership
-
-Each thread tracks explicit membership. There are two primary use cases for this data:
-
-- Clients use _their own_ [thread member](#DOCS_RESOURCES_CHANNEL/thread-member-object) to calculate read states and notification settings. This is largely irrelevant for bots though, but is the reason for some of the syncing complexity detailed here.
-- Knowing everyone that is in a thread.
-
-Membership is tracked in an array of [thread member](#DOCS_RESOURCES_CHANNEL/thread-member-object) objects. These have four fields, `id` (the thread id), `user_id`, `join_timestamp`, and `flags`. Currently the only `flags` are for notification settings, but others may be added in future updates.
-
-### Syncing for the current user
-
-- A [Thread Members Update](#DOCS_TOPICS_GATEWAY/thread-members-update) Gateway Event is always sent when the current user is added to or removed from a thread.
-- A [Thread Member Update](#DOCS_TOPICS_GATEWAY/thread-member-update) Gateway Event is sent whenever the current user's [thread member](#DOCS_RESOURCES_CHANNEL/thread-member-object) object is updated.
-- Certain API calls, such as listing archived threads and search will return an array of [thread member](#DOCS_RESOURCES_CHANNEL/thread-member-object) objects for any returned threads the current user is a member of. Other API calls, such as getting a channel will return the [thread member](#DOCS_RESOURCES_CHANNEL/thread-member-object) object for the current user as a property on the channel, if the current user is a member of the thread.
-- The [Guild Create](#DOCS_TOPICS_GATEWAY/guild-create) Gateway Event will contain a [thread member](#DOCS_RESOURCES_CHANNEL/thread-member-object) object as a property on any returned threads the current is a member of.
-- The [Thread Create](#DOCS_TOPICS_GATEWAY/thread-create) Gateway Event will contain a [thread member](#DOCS_RESOURCES_CHANNEL/thread-member-object) object as a property of the thread if the current user is a member of, and the user has recently gained access to view the parent channel.
-- The [Thread List Sync](#DOCS_TOPICS_GATEWAY/thread-list-sync) Gateway Event will contain an array of [thread member](#DOCS_RESOURCES_CHANNEL/thread-member-object) objects for any returned threads the current user is a member of.
-
-### Syncing for other users
-
-> info
-> These require the `GUILD_MEMBERS` [Gateway Intent](#DOCS_TOPICS_GATEWAY/gateway-intents)
-
-- An API `GET` call to [`/channels/<channel_id>/thread-members`](#DOCS_RESOURCES_CHANNEL/list-thread-members) which returns an array of [thread member](#DOCS_RESOURCES_CHANNEL/thread-member-object) objects.
-- The [Thread Members Update](#DOCS_TOPICS_GATEWAY/thread-members-update) Gateway Event which will include all users who were added to or removed from a thread by an action.
-
-## Editing & Deleting Threads
-
-Threads can be edited and deleted with the existing `PATCH` and `DELETE` endpoints to edit a channel.
-
-- Deleting a thread requires the `MANAGE_THREADS` permission.
-- Editing a thread to set `archived` to `false` only requires the current user has already been added to the thread. If `locked` is true, then the user must have `MANAGE_THREADS`
-- Editing a thread to change the `name`, `archived`, `auto_archive_duration` fields requires `MANAGE_THREADS` or that the current user is the thread creator
-- Editing a thread to change `rate_limit_per_user` or `locked` requires `MANAGE_THREADS`
-
-## NSFW Threads
-
-Threads do not explicitly set the `nsfw` field. All threads in a channel marked as `nsfw` inherit that setting though.
-
-## New Message Types
-
-Threads introduce a few new [message types](#DOCS_RESOURCES_CHANNEL/message-object-message-types), and re-purpose some others:
-
-- `RECIPIENT_ADD` and `RECIPIENT_REMOVE` have been repurposed to also send when a user is added to or removed from a thread by someone else
-- `CHANNEL_NAME_CHANGE` has been repurposed and is sent when the thread's name is changed
-- `THREAD_CREATED` is a new message sent to the parent `GUILD_TEXT` channel, used to inform users that a thread has been created. It is currently only sent in one case: when a `GUILD_PUBLIC_THREAD` is created from an older message (older is still TBD, but is currently set to a very small value). The message contains a [message reference](#DOCS_RESOURCES_CHANNEL/message-reference-object-message-reference-structure) with the `guild_id` and `channel_id` of the thread. The `content` of the message is the `name` of the thread.
-- `THREAD_STARTER_MESSAGE` is a new message sent as the first message in threads that are started from an existing message in the parent channel. It _only_ contains a [message reference](#DOCS_RESOURCES_CHANNEL/message-reference-object-message-reference-structure) field that points to the message from which the thread was started.
-
-## Enumerating threads
-
-There are four new `GET` routes for enumerating threads in a specific channel:
-
-- [`/guilds/<guild_id>/threads/active`](#DOCS_RESOURCES_GUILD/list-active-threads) returns all active threads in a guild that the current user can access, includes public & private threads
-- [`/channels/<channel_id>/users/@me/threads/archived/private`](#DOCS_RESOURCES_CHANNEL/list-joined-private-archived-threads) returns all archived, private threads in a channel, that the current user has is a member of, sorted by thread id descending
-- [`/channels/<channel_id>/threads/archived/public`](#DOCS_RESOURCES_CHANNEL/list-public-archived-threads) returns all archived, public threads in a channel, sorted by archive timestamp descending
-- [`/channels/<channel_id>/threads/archived/private`](#DOCS_RESOURCES_CHANNEL/list-private-archived-threads) returns all archived, private threads in a channel, sorted by archive timestamp descending
-
-## Webhooks
-
-Webhooks can send messages to threads by using the `thread_id` query parameter. See the [execute webhook](#DOCS_RESOURCES_WEBHOOK/execute-webhook) docs for more details.
-
-## Additional context on the the THREAD_LIST_SYNC and THREAD_CREATE dispatches
-
-While threads are mostly similar to channels in terms of structure and how they are synced, there are two important product requirements that lead to differences in how threads and channels are synced. This section helps explain the behavior behind the [Thread List Sync](#DOCS_TOPICS_GATEWAY/thread-list-sync) and [Thread Create](#DOCS_TOPICS_GATEWAY/thread-create) dispatches by going over those problems and how they are solved.
-
-The two product requirements are: The gateway will only sync threads to a client that the client has permission to view, and it will only sync those threads once the client has "subscribed" to the guild. For context, in Discord's official clients, a subscription happens when the user visits a channel in the guild.
-
-As mentioned, these lead to a couple of edge cases that are worth going into:
-
-### Gaining access to a private thread
-
-When a client is added to a private thread, they likely don't have that private thread in memory yet because of the product requirement that we only sync threads you have permission to view. Private threads are only synced to you if you are a member or a moderator. To solve this, whenever a user is added to a private thread, the gateway also sends a [Thread Create](#DOCS_TOPICS_GATEWAY/thread-create) dispatch. This ensures the client always has a non-null value for that thread. Note: This is also sent even if the user is a moderator, and thus would already have the channel in memory, mainly for simplicity purposes.
-
-### Gaining access to a public thread
-
-When a client is added to a public thread, but has not yet subscribed to threads, they might not have that public thread in memory yet. This is actually only a problem for Discord's official clients, and not for bots. The gateway will auto-subscribe bots to all thread dispatches and active threads on connect. But Discord's clients only receive threads that are active and they have also joined on connect in order to reduce the amount of data needed on initial connect. But this means when a user with the official client is added to a thread, that thread now becomes an "active-joined" thread and needs to be synced to the client. To solve this, whenever a user is added to _any_ thread, the gateway also sends a [Thread Create](#DOCS_TOPICS_GATEWAY/thread-create) dispatch.
-
-### Gaining access to a channel
-
-When a client gains access to a channel (example: they _gain_ the moderator role, and thus now they have more channels they can view), they won't have any of the threads in memory for that channel (since the gateway only syncs threads that the client has permission to view). To solve this, we send the [Thread List Sync](#DOCS_TOPICS_GATEWAY/thread-list-sync) dispatch to a client when they gain access to a channel! This dispatch includes a `channel_ids` array, which is the id of all the channels whose threads are being synced. This field can be used to first clear out any active threads whose `parent_id` is in the `channel_ids` array, and then ingest any threads that were in the dispatch.
-
-### Losing access to a channel
-
-When a client loses access to a channel, the gateway does not send them a [Thread Delete](#DOCS_TOPICS_GATEWAY/thread-delete) event or any equivalent. They will still receive _an_ event when this happens, it just will not be a thread-specific event. Usually the event will be [Guild Role Update](#DOCS_TOPICS_GATEWAY/guild-role-update), [Guild Member Update](#DOCS_TOPICS_GATEWAY/guild-member-update) or [Channel Update](#DOCS_TOPICS_GATEWAY/channel-update). It will be some event that caused the permissions on a channel to change. So _if_ a bot wanted to simulate a "lost access to thread" event, it is entirely possible, albeit quite complicated to handle all cases correctly. Under the hood, Discord's clients actually don't worry about this detail. Instead, when performing an action, the client checks permissions first (which implicitly checks if the client has access to the parent channel too, since threads inherit permissions), that way _even if_ the client has some stale data, it does not end up acting on it.
-
-Additionally, when a client loses access to a channel they are not removed from the thread. Users may want to temporarily shut down access to a server or channel. Removing someone from all threads when that happens would not be a good experience, so we've chosen not to go that route. Users will still be reported as members of a thread, even if they no longer have access to the parent channel. They will **not** receive new gateway events for those threads though, with one exception: If a client is removed from a thread _after_ losing access to the parent channel, they will still receive a [Thread Members Update](#DOCS_TOPICS_GATEWAY/thread-members-update) dispatch.
-
-### Unarchiving a thread
-
-Discord's clients only load active threads into memory on start. So when a thread is unarchived, there is no guarantee that the client has either the thread or whether they are a member, in memory. As such, the Gateway sends a [Thread Update](#DOCS_TOPICS_GATEWAY/thread-update) first, which contains the full channel object. And then sends a [Thread Member Update](#DOCS_TOPICS_GATEWAY/thread-member-update) to each member of the thread, so those clients know they are a member, and what their notification setting is. This event is not that valuable for bots right now, but is going to be received by bots, so is documented here none the less.