User privacy and safety are high priorities for Discord, including with the use of bots. In August, we announced message content access for bots will require verification and privileged gateway intent approval for any bot operating in 100 servers or more. Our goal is to ensure that message privacy is the default state of the world for bots operating at scale on Discord, and that message content access is only granted based on the need for a bot's core functionality.
There are of course plenty of use-cases where a bot has a legitimate need to access message content. Some common ones we see:
- Content moderation
- Gameplay interactions
- Machine learning and neuro-linguistic applications
- Community archival features
- Message proxying and chat relays
❓ Got questions about your use case? Make a ticket at https://dis.gd/contact using the Bot & API Developer Support form, or ask in the Discord Developers server!
To be approved for verification to use message content, a bot's use-case for accessing message content must:
- provide a unique, compelling, and/or transformative experience to users;
-
be non-invasive and put user privacy and safety front and center;
- Provide a link to your Privacy Policy for users to easily find.
- cannot be feasibly migrated to our new interaction options;
- be relevant to the bot's mission and existing feature set;
- not represent any significant impact to our infrastructure.
We recommend that all bots begin migration to our new interaction options where at all possible, even if approved for the message intent.
What does this article cover?
- Background
- Criteria for Approval
- Feasibility of migration
- Library Issues
- Relevancy to bot
- Impact to infrastructure
- Reporting
- Enforcement
Background
⚠️ If your Bot is operating in 100 servers or less, this change doesn't impact you.
If you're reading this, it's because you've heard the big news—as of August 31, 2022, message content will require verification and privileged gateway intent approval for any bot operating in over 100 servers. If your bot is operating in fewer than 100 servers, this change doesn't impact you.
Our goal is to ensure that message privacy is the default state of the world for bots operating at scale on Discord, and that message content access is only granted based on the need for a bot's core functionality. Message content access is not going away. There will always be unique, compelling, and transformative features that require access to messages in a server: from moderation to gameplay, to things we can't even imagine yet. Bots will continue to have access to any messages that specifically @mention them, as well as to DMs directly with the bot, regardless of message intent approval.
If a bot operating at scale has access to messages in bulk, we have to ensure it has that access with good reason. Approval for message content also means that bot is using messages in ways that cannot be migrated to our newer interaction options. Handling message data is a huge responsibility and can greatly impact the privacy and safety of users on Discord.
Below, we'll explain what the different criteria mentioned above mean and why they're important to our thought process.
Criteria for Approval
We've rooted our approval philosophy in three basic tenets. We look for features that are unique, compelling, and transformative. Let's talk about what that means in general, and what it will mean for messages moving forward.
Unique
📝 We consider UNIQUE to be features that are not currently available in any capacity within the client.
If a feature you are building is something the client already does to some capacity, we likely wouldn't grant you intents approval for that feature.
-
Example: Let's use Guild Presences and activity data as an example of how we apply these criteria generally. When working with Guild Presences, and your only use case is to count how many users are online in a given server. The client already does this—you can just check the sidebar in any channel with @everyone access! Because the client does this near identically, we wouldn't consider your use case a unique one, and thus wouldn't grant you Presences access solely to provide that kind of feature.
- Note that what features are "unique" can change as the client does. We reserve the right to deny or remove Privileged Intents when this functionality is exposed through the client.
Compelling
📝 We think of COMPELLING as features that are clear, self-explanatory, and immediately understandable why this feature should exist and where it would be useful.
Of all our criteria, features being considered compelling is perhaps the most nuanced, which is why we encourage you to share as much detail as you possibly can.
Describe your features in-depth. Tell us why you think your features are cool, and why you think your users need them. We love it when you tell us stories about the software you're making, so tell us your stories!
With that in mind, simply requesting approval for messages so you can maintain custom prefixes or traditional command interfaces will result in a denial, as we don't believe that to be a compelling use case on its own.
Transformative
📝 We consider TRANSFORMATIVE as using the information you collect through message intents to provide new functionality or features.
Just resurfacing the message content you're collecting in a new way generally isn't considered "transformative". Often, developers will request approval for intents simply so they can share user information, server data, or other statistics. For the most part, that kind of thing isn't transformative.
Example: Let's use Guild Presences and activity data as an example of how we apply these criteria generally. If you're just displaying what someone's activity status is with some sort of !activity [user ID here] command, for example, that's simply recreating functionality that exists in the client. But, if you're looking at someone's activity data and acting on it in ways that the client can't, that'd be transformative. For example, a command that provides lyrics for a song mentioned in someone's Now Playing activity status.
Non-Invasive
In addition to looking for features that are unique, compelling, and transformative, we also require that use cases respect user privacy and safety.
If you intend to collect user data to provide some degree of functionality, you must:
- Ensure that you are complying with all relevant privacy laws. This includes clearly disclosing what data you collect and how you use it.
- Post a Privacy Policy publicly and make it accessible to users (and provide us with a link).
- Allow users to opt out of providing you that data, even if that means not being able to participate in the feature.
- Provide an accessible way for users to request access to and deletion of their data.
As a reminder, it's your responsibility to ensure that you have reviewed and comply with our Developer Terms, Developer Policy, Terms of Service, and Community Guideline.
Example: Let's use Guild Presences and activity data as an example of how we apply these criteria generally. Collecting a user's Presence information to gather a rough idea of what time zone they're in based on their time spent active on platform, without users volunteering that information to you themselves. The most invasive features are ones that are used to provide advertising and marketing within servers, which is explicitly disallowed by our Developer Policy already.
Feasibility of migration
When reviewing requests for message content, we're going to consider the feasibility of migrating your stated functionality to interactions where possible. Our goal is to either maintain the functionality of those features that fit the above criteria as they exist now, or to help you migrate those features to interactions where possible.
If a feature cannot be migrated to interactions in any capacity and meets our other criteria, you'll likely get message content approval. If, however, a feature can be migrated to interactions with some degree of modifications to your user experience, we'll likely lean towards helping you migrate that functionality rather than granting you message approval.
Library Issues
When discussing the feasibility of migration, it's of course important for us to consider the impact of community-driven libraries and their adoption of our interaction options. We've been working with the libdev community since early summer to try and help them adopt interactions as quickly and smoothly as possible.
That said, we won't be able to grant message intents in cases where your only blocker preventing migration is a lack of support for interactions in your chosen development library.
- If you are on a library that does not support interactions, and your features are not otherwise unique or compelling enough to justify message intent approval, please consider exploring library extensions, alternative libraries, or alternative languages where possible.
Bots will continue to have access to any messages that specifically @mention them, as well as to DMs directly with the bot, regardless of message intent approval. If you're developing with a library that does not support migration to interactions, you can rely on this access as a fallback.
Relevancy to bot
Our goal is to ensure that developers are only getting access to message content where it's necessary to provide features that are directly relevant to their users. With that in mind, for the message intent, we'll be a bit more discerning about whether or not a proposed feature is relevant to your bot's overall stated goals.
Plan to explain why your bot in particular needs accesses to message content in order to enable that specific functionality.
🛑 We reserve the right to re-review privileges and verification to any bot at random, on a periodic basis to ensure they are compliant with our policies. We may revoke verification for a verified bot if the bot changed significantly from the stated goals and purposes in the original verification application and has not been updated.
Impact to infrastructure
- Features that incentivize spam.
- Features that put undue load on our databases (e.g. hammering the same resource very fast forever).
- Features that incentivize selfbotting.
Reporting
If you find a bot that is not compliant with this policy, please report it to us by filling out the form here: https://dis.gd/report
Enforcement
This policy is enforced by our Developer Support team. The team will review your application, may request further information, and can make the decision to verify, not verify, or revoke verification depending on the bot's compliance with this policy and all other applicable terms and policies.
Questions, comments, concerns? We've got the Developer Support contact form and the Discord Developers server ready and waiting for your questions as we approach approval day.