Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

Transcript of live Q&A related to message intents becoming privileged, held in a stage channel on the Discord Developers server, on 2021-08-04 at 11AM PDT.

Written by spiral. Contact me on Discord at spiral#3257 if I messed up anything here, and I can fix it.

Useful links:

Note: [text like this, in square brackets] is words that have been changed to better fit a text format. [text like this, in italics] is myself commenting on what was said.

This is not a perfect transcript of what was said, nor is it an adaptation to text format. It is something in-between; my goal with it is to be useful both to those who are listening along to the audio recording while reading this, and to those who just want to read it at their own pace.

Ian: Welcome everyone to our first public Developer Q&A (in a stage channel). My name is Ian, I'm the engineering lead on the Bots and API team. I'm joined here by my friend Mason, the product manager for the team, who many of you know because he has been working on Bots and API at Discord for many years.

So, today, the subject of our discussion is the message intent announcement. Obviously, we've received a ton of community feedback on this. We've been following closely in the discussion on this server as well as the survey responses that you submitted and I just want to say I appreciate the variety of the viewpoints that you all have.

I definitely want to acknowledge that this change is clearly disruptive to many of you. You've all put a lot of time, energy, effort, into your bots and you're very invested in the bot ecosystem. And this is something that we've put a great deal of time and thought into as well. We're trying to make this change with a deep understanding of the tradeoffs involved.

So, why is this change happening? We want to build an ecosystem on Discord in which every user and server owner can find a bot that is perfect for them. In order to get there, we need to make it as easy as possible for users to discover and safely use bots. We need to make it really easy for devs to build and innovate within a framework that is easy to use, respectful of our users, and mitigates the scope of damage that can be done by bad actors (bad bots, or hacked bots).

At the same time, Discord has grown immensely from its earlier days, especially in the past year, and we have millions and millions of users that are brand new and basically unfamiliar with what the bot ecosystem has to offer. Our long-term goal here is to create a place that includes the many users who are not currently using bots.

In order to do that, we need to grow our user base [audio glitched] we need to work together to find a way to ensure user privacy, prevent bots from doing harmful things, and place checks on people and actors that abuse our users' trust. The solution that we've identified here is to introduce a privileged intent that will grant bots the ability to read content in messages as well as embeds and attachments and components.

Like other privileged intents, this will kick in when your bot reaches 100 servers. You'll have to go through a verification process to share your use case and get the intent on your bot. You can read all about this in this message in the #announcements channel [on]. There's a help center article, there's also now a GitHub discussion. I recommend going through it to make sure you understand the change in detail.

The last thing I'll say here is that everyone in the audience is a developer, every Discord staff in this channel right now and that you'll hear from today is a developer as well, so I want to ask us to keep the conversation constructive so that we can move forward in the best way possible, and make sure that we're doing great things for Discord and the API.

Here's how today is going to work: you've all submitted a bunch of questions in Slido, we already probably have too many questions to cover, but we're going to get through as many of them as we can. You'll be able to keep submitting questions for probably the next couple minutes but we'll close submissions soon because we can't really keep up with all of them. You'll still be able to use the Slido link to upvote questions that you want to see answered. And I encourage you to do that so we don't end up going through questions in chronological order. If you want to access the Slido, it's pinned on top of the #stage-discussion channel, which hopefully you're all in and following along. [In this transcript, it's linked at the top of this paragraph.]

Without further ado, I want to give Mason the floor. Again, he's our product manager and he's gonna field a lot of these questions. And I'm just gonna serve them up to him by looking at the Slido. Mason, do you have anything to add before we get started?

Mason: Yeah. Just very quickly before we get started, thank you all for attending. We all know that it is not 11am for everybody in the world, so thank you for those who are making time in your, perhaps otherwise off-hour, schedules to come attend this. I also want to say a special thank you.

I know there are a lot of international developers on our platform, and developers for whom English is not their first language, so thank you very much for engaging with us and I'm sorry that all we have is an English Q&A right now. We wanted to make sure the help center article and the FAQ was translated into the languages that we support, and we do have some long-term plans to support more languages in things like our documentation as well. If the help center article is not in your native language, please do let us know - we'd love to know what more languages we can support for developers for whom English might not be their first language, because we know meeting you where you're at and making this change and this transition as easy as possible for you can only be helped if we can give you this information in your native languages. So, thank you.

Without further ado, yeah, if you want to just serve them up, let's make it happen.

Q: Will DMs sent to bots have full message content?

Mason: This is a question that we've seen a lot in the discussions over the past week. To be transparent, we are still discussing it.

I do also want to say that regardless of the decision, we are actively thinking about ways that users and bots can have private conversations without having to leave the context of a server, especially without having to worry about whether the person you're trying to talk to has DMs turned on or not (I know that I've had a lot of personal frustrations when trying to interact with a bot and now I'm flipping back and forth between DMs and servers, or maybe I have DMs turned off for that server and things seem broken).

Bots can already do this on their side with ephemeral messages, so the next step is how do we make users able to do something like this?

Q: Do you realize that your decision kills a lot of bots that don't have a large budget / team behind them? I am the only responsible person for a bot with a large codebase, years of work, and migrating means rewriting everything - impossible in just some months. How do you plan to prevent this and help people like me?

I'm very sorry that this decision is causing you stress. We very much recognize that large bots with teams of multiple developers are the anomaly on our platform, and we're super glad that they're part of our platform, but we know that most of you are single-developer teams trying to make something that your users love. This is a big change and we recognize that.

Reminder that we have at least 9 months until any changes are required - April of next year [2022]. Most of our popular libraries have either finished integrating commands and interactions, or are quite close, or have forks that support them. Hopefully that removes a big blocker from you and others in your situation.

If there are specific issues that you have migrating that are independent and specific to your bot and your implementaion, please do respond to the survey from the announcement post and tell us if you haven't already. We are reading all of those responses. We're also going to be hosting more recurring events in this server like this - more Q&As, and more office hours - to answer specfic questions from individual developers about their specific use cases.

My last plug is: if there's something in the documentation that seems confusing, or inconsistent, or something you think that might be helpful to others, feel free to make pull requests against our documentation. It is open source on GitHub the repo is discord/discord-api-docs. We very much welcome improvements there.

small aside from Ian/Mason about questions being closed and voting still being open.

Q: What usecases will be valid?

This is definitely the biggest question, and one that we do not take lightly, which is why we are not talking specifics yet. I know that feels very frustrating, but we know that there are a lot of questions about what is okay and what is not. The language in the announcement specifically talks about "unique and compelling use-cases that cannot be replicated by slash commands and interactions", so I think if you put yourself in that mindset, that should give you some initial answers.

We will be publishing a pretty comprehensive policy with some examples before the approval process goes live to answer your specific questions.

Q: What is your ideal goal with adding intents? Are there any plans to add intents for more things?

This is a really good question and I want to make the distinction between "gateway intents" and "privileged intents" here. We have a lot of gateway intents, including things like gateway voice states, and reactions. A few of those intents are privileged, like presence data, guild members, and moving forward, messages.

The intent system has two goals, so first, let's talk about privileged intents.

As we stated in the FAQ for message content, and last year, I believe it was last year when we did presence and guild members, the intent of privileged intents (no pun intended) is to put some information in our API that we deem inherently sensitive at scale behind an approval process that's more than just a server admin granting a permission on behalf of everybody in their server. We believe that presence data, guild member information, and message content are at that level.

There are no current plans to add any more privileged intents.

Like I said, there are a lot of intents that are not privileged - they do not require approval. The gateway intent system as a whole is a great way to unsubscribe from gateway events that your bot doesn't need to function, directly saving you processing power and money. We will probably add more non-privileged intents as we make more gateway events, to help you filter what information you need and don't need.

I know that when some of the largest bots were able to drop presence data thanks to intents, it was a nearly 50% bandwith and CPU saving for them. I know that not everybody is necessarily operating at that cost and scale, but aside from the intents that require approval, definitely take a look at what they all are in our documentation. You might be able to stop handling some events that you don't actually need and save yourself a little bit of effort.

Q: Will bots still be able to see message content for messages they are mentioned in?

This is currently the same answer as for DMs. We are still actively discussing this.

Q: Do you plan to implement channel permissions to filter out certain bots for slash commands? For example if you make a bot not able to view the channel, [users] can still run slash commands. Will server owners be able to filter channels?

Yes. We are currently thinking through a pretty decent improvement and revamp of the current command permission system to solve problems like this.

Q: Will the limit be raised for slash commands? I already have more commands than the limit and plan to add more.

There are currently no plans to allow more than 100 global and 100 guild commands, but we know this is a common request. As a reminder, you also have access to 25 subcommand groups within each command, and 25 subcommands within each group, so that's 200 commands * 25 groups * 25 subcommands. You can do the math on that one. [Calculator says 125,000].

We encourage you to explore subcommands and groups, especially after the work that we're going to be doing pretty shortly to move them into their own autocomplete within top-level commands. We know it feels a bit cluttered right now when everything is at the top level, and we believe that's a pretty big mental barrier for why people aren't trying out subcommand groups and subcommands more right now.

Q: Can you guarantee that there will be significant improvements to slash commands in the future before making a switch to entirely slash commands?

Yes. Our planned improvements to slash commands were posted in the same message as this Q&A link yesterday, take a look there. We definitely know how important it is to continue enabling you all to make great stuff, so you can check that GitHub discussion to see all the stuff that we are quite literally working on right now. There will definitely be more stuff to come that is not directly mentioned there.

Ian: The next question is from 'George Washington'. I wonder if this is the real one.

Q: Is the process of getting intents going to be improved with this new set of intents? What steps are being taken to ensure that a massive backlog does not repeat itself?

This is an excellent question, and also one that we have seen a lot. Yes. It will be improved.

We've recently finished analyzing both our intent request and verification queues, both our current sort of steady-state and the burst that has happened during announcements in the past. We've improved workflows and tooling and hired more people to make sure we meet the need appropriately. We are also currently, I believe, back to inbox zero on verifications - so, back to that 5-day SLA.

The post-verification intent request is next on our list to get back to that promised SLA.

Q: Will Union argument types (eg. user OR string) be available in the future?

Union arguments are currently doable by using a string type. We also recently just shipped a change where mentions inside of a string type will get resolved, so if you have a string type and you type @Mason inside of it, the interaction payload should have my user object resolved in it. That's a way you can sort-of do this.

As for explicit union types, the difficulty here is more communicating to people using your bot what is valid. What I mean by that is: if there is an autocomplete of users in front of somebody, but it technically takes either a user or a string, people are going to pick users that are visible in the list, because that's what they assume is going to be valid.

Ian: Just following chat on the auto-resolve behaviour for strings. This is a very recent change (Mason: I think, like, last week.) Once it's fully rolled out, we'll make a separate announcement for it.

Mason: I will also say very quickly: there are some types that we are looking to do better filtering on, like channels. Right now, the channel type just gives you everything in a server. We are looking into, for cases like that, allowing you to specify "I just want voice channels" or "I just want text channels" or "I just want text and voice channels". Which is not really a union type, but a restriction within a type, I suppose.

Q: Will there be a way to localize slash commands? Having slash command names, descriptions, and arguments in only one language is hard to users who don't speak English.

Absolutely. As I said at the top of this, I know that a lot of our development community is not English as their first language, and we know that the majority of the people who use Discord is not English as their first language, either. There's a lot of places in the world other than just English-speaking countries.

Localization is a sort of two-step problem. There's the question of, how do we show localized information to users when they type / and see command names are localized, descriptions that are localized. We are actively figuring out a good system to make that work. Previously, we've used things like localized dictionaries that you can register to our API for stuff like store channels. It has its pros and cons, it might just be the easiest thing.

The second part of localization is responding to users in the language of their choice. Some of you may know, if you go through OAuth, you can get user locale on the user object - which is the language that they've chosen to have their Discord client in. We have historically considered that more sensitive information than we're willing to just pass through in our API, but we're reinvestigating the possibility of doing something like that, so when an user sends you an interaction you will know what their locale is, and if you want to, can respond in a localized way in your response message. I will say that is a more complicated privacy question that it may appear on the surface.

Q: Will there ever be a "discovery" for bots? This would probably reduce the need of a bot list to grow your bot.

You all make really incredible and awesome things. There are so many creative and useful and fun bots on our platform.

Right now, our focus is on making improvements to slash commands, like we've been talking about here, so that this transition period goes well. But discoverability of bots is absolutely something that we know that we want to start looking into very soon.

Q: Are there any plans to create some kind of menu where you can input text that opens when you interact with a button?

Yes. We are considering ideas for followup text input. It might not look exactly like a popup, or exactly like a text box in chat, but yes, we are considering the ability to do things like this. I think it is actually listed in the GitHub discussion as well.

Q: What is the overall point of introducing the message intent? If someone wants to steal data or use it maliciously, I don't see how this stops them, and it barely makes it any harder.

It's difficult for me to answer your objections without knowing what they are specifically. I would say that I pretty fundamentally disagree that moving message content behind a privileged intent doesn't make it any harder to passively get message data. As for why we're doing this, we've gone into detail both here, in announcements, and in the FAQ about why this is happening, so please do read that article.

Q: If we do get access to the intent for legitimate reasons, will we still be required to transfer all our commands to slash commands?

We do expect that people will migrate to slash commands, yes. Access to the message intent, and I believe I'm quoting or at least paraphrasing what is said in the FAQ, is for "powering unique or compelling use-cases that cannot be replicated by commands and interactions", for example, reading messages to look for bad words.

We do expect people to migrate their text commands to slash commands and other interactions, yes.

Q: What priority is a date picker option for slash commands? Similar to the new event modal where it has date & time.

I very much want a date picker type. It is currently sort of a stretch goal for us, it's not listed in the GitHub discussion. The reason why it's not listed there is because there's a lot of other actual blocking work to make sure we get done first, like a better permissions system and a better experience of using slash commands, but a date-time picker to replace arbitrary strings and trying to parse date-time (which we all know is very difficult and obnoxious) is definitely high on the list of other considerations.

Q: Can Discord re-review intent requests every year? For example, a bot gets access to the message intent, but removes moderation features. Then the next year the bot would lose access since it doesn't need the intent.

There are no current plans to do this. It's something we've talked about quite a bit. It is a very heavy burden, both operationally to re-review these things, and for you all to worry about every year. We know that other platforms like Apple go as far as to check every single build of your app that you upload, that's a bit much for where we're at. I don't that we would be confident in doing this until we're confident we can handle the current influx of verifications and intent requests.

Q: Will variable-length arguments (e.g. a flexible amount of users in a row) be available in the future?

One of the reasons that this has not yet existed is because the way you currently fill out slash commands makes it very difficult to do this from a UI perspective. Like, how do you decide when a user is done sending you enough people?

Right now, this can be definitely be done with string arguments, you can just mention multiple people, but I agree with you, we have user arguments, it should be able to work this way. We're currently doing a lot of work to make the UX for slash commands better, and this might be something that becomes a lot easier to do once we finish that other work.

I'm not currently committing to doing it, but it's one of those things, much like the date/time picker, that we know is a top frustration.

Q: When will context menus be released to the public?

Very, very soon.

Q: I remember back in early 2020 where a preview of the interactions was shown and there were commands inside the upload button (the + one to the left of the chat bar). Is this still being worked on or was the idea scrapped?

We actually have an experiment out right now, live on iOS, that adds an entrypoint to slash commands in the + button. Right now, for most of you, if you press that button on your iPhone you will see the media picker; some of you may see some different UI that grants you access to the slash commands picker.

Something like this is likely to get added to desktop as well, which is why we pre-emptively made that change to the file upload button, but we're currently prioritizing mobile in the experiment because using slash commands, finding slash commands, that whole flow is a lot harder on smaller screens and mobile keyboards.

It's likely that this will get added to desktop.

Q: Could you finally give the real reason for the message intent instead of buzz words about privacy?

As absolutely unexciting as it is, there is no "secret real reason". We posted a follow-up to our announcement yesterday, er, two days ago, that specifically answered this question. We encourage to all of you to make sure you've read that as well as the original help center article. We're being completely transparent here in our reasoning; there's not really a lot else that we can continue to say about this, except that we hope if you hear the words "real reason", you know that there isn't anything more that we're not saying.

Q: Will you be doing another round of grandfathering for the slash command scope?

We are considering this, but only after we're sure that our new permissions system affords moderators the right amount of control in keeping their servers safe and healthy. We know that when we did this last time and we didn't have the right permissions system in place, a lot of moderators got very frustrated and kicked a lot of bots out of their server and then re-invited them without the commands scope.

We don't want to make their lives any more difficult, but we know that having to reinvite bots with the scope is annoying and we also know that having separate scopes is kind of confusing, so I think this question will probably also come up, but we're also considering baking the slash commands scope into the bot scope. But again, we're only going to do that once we are sure that our new permissions and control system is what it needs to be to let moderators have the control that they need over slash commands.

Q: I think we should be provided intent analysis on a hypothetical project. I would rather be assured that a planned project of mine can get an intent if needed without having to build it out and grow it to 100 servers first. Any way for developers to request a "probably" or "probably not" evaluation?

We will publish policy and some examples to, you know, help give that initial guidance. But of course there are always going to be specifics that people are coming up that we haven't thought of before, and that's great. We try to leave a lot of flexibility in development, which is why these changes do not affect unverified bots. We want to give you the flexibility to ideate and try new things without having to ask for everything in the world when you start making a bot just in case.

But the idea of, is it even worth investing the time and whether or not I'll know that this is accepted, is super valid. I think this is ultimately something that we would love our developer support to be able to answer for people. I said the verification queue is now sort of inbox zero on our SLA, post-verification intent requests are next; the third thing on that list is how do we make our general developer support queue better so that you can ask these types of questions?

We will also, like I said, be doing recurring events within this server, Q&A, office hours, and just chatting with us where you could come ask some of those questions.

Q: A lot of bots have different prefixes currently. Slash commands replace all of those, so how do two bots with similar commands resolve which slash command is being run?

For those of you who may not have interacted much with slash commands yet, when you type /, a list of all available slash commands in the server appears above your chat box, sectioned off by the bots that they belong to. As you type more to try to filter down commands, you will see a list of commands that match what you've typed, as well, again, the bot that they belong to.

There really is no guessing or collision that you need to worry about on your part. You no longer have to care if other bots also have play commands. When you use a command, you directly choose the bot that you are using.

Q: How we will be able to run eval commands? Slash commands only support one line.

I'm going to answer the question then get on the soapbox for a second.

One of the improvements that we are making to the slash commands experience is to make them work with multiline input, we know that doesn't work very well today. Read, "at all". So multiline input is something that we're going to be fixing.

To get on the soapbox for a second, please don't make eval commands! I have seen a lot of servers get accidentally nuked because people incorrectly used or allowed others access to eval commands. Just... think about it. Please.

Q: What solution have you come up with to prevent server owners having to re-invite bots to grant the applications.commands scope?

We just talked about a possible scope migration a second ago, as well as baking the slash commands ability into the bot scope, but again, after we are very confident in our new permissions system.

Q: What about text input after a slash command is used?

I think this is currently on the GitHub issue of things we're working on right now [(it is not)]. There's sort of the two-fold part of this problem of how do we make more free-form text input in sending a slash command work better, which is something to get "for free" with the UX improvements we're making, and then the "how do I get users to send me follow-up data after a button click or a slash command or a context menu" is another big use case.

There's a few different ways that this could go. We could make a text input component, we could make a new interaction type that allows you to pop up a modal and have a text box, or have a message in the chat box be sent directly to the bot instead of to the channel? They all have their pros and cons, we haven't decided exactly what the best first thing to do is, but solving this problem is I believe something we've said that we're committing to.

Q: Will we be able to lock permissions on permission or will bots be able to create their own permission nodes [sic]?

Permissions are a very difficult problem, and you can ask the other people on my team as I have been agonizing over the past couple weeks about how to make a system that isn't completely insane. We haven't nailed down the specifics yet, and that's not because we're not trying... we've had multiple, quite long, conversations about how to build a system that works here.

There's a few meta points that I'll make, which is: as developers, you're very used to interacting with Discord permission bits; server moderators are used to working with roles. So there needs to be a way to sort of rectify those two things in a way that makes sense for your code, but translates into logical moderation on a server admin's side of things. That is not an easy thing to do, but it's literally something we're working on right now.

My second meta point is: a permission system needs to help moderators first and foremost. As we think through ideas and land on something that we think is good, we will definitely be sharing thoughts with our developer community, but we will also be sharing thoughts with moderators in our moderator community, because ultimately, your goal is to make sure that there are sane defaults on your commands so they can be used safely; moderators need to make sure their whole server is safe and manageable. Those are not conflicting ideas, they are both equally important.

Q: When will you re-open staging?

I don't have control over opening staging. Historically, we've opened our staging environment to do specific testing of things. It's not really intended to be an always available free-for-all. I was not the one who ran the testing on staging at the time... I'm just sorta thinking back, it was intended to be a really easy way to give a bunch of people access to something to test without having to make some very convoluted experiments to allow people in.

It's not intended to be an always available "come play in our staging environment" thing, because we use it for staging before production. If it becomes available in the future, I have no direct control over it or not, and it would probably be for very specific reasons.

Q: Will bots be marked somehow if they have the messages intent or other intents?

We will probably add some user education around when bots have access to things that we deem privileged. No specifics right now, because making sure that we unblock all of you to make the transition is currently a bit more important than educating users about something that hasn't happened yet. There's also a very fine line between informing people and making them scared for no reason.

Q: Question from chat: custom commands?

One of the things in our roadmap on the GitHub discussion is something called an autocomplete type. What that means is that it can be an option that lets you dynamically return responses from your server, more than just the 25 things you have pre-registered as options. I see a world where custom commands could fit into that and you could have infinite custom commands within a single command, if that makes sense.

That might've not been a great explanation; when we finish that API it'll be a lot more clear.

Q: Some popular libraries haven't yet implemented slash commands (for example, doesn't even have a beta available yet). Can you guarantee that devs have enough time to implement slash commands after every important library implements slash commands?

We obviously do not have control over our third-party libraries - they are third party. We try to work with them very closely to keep them informed of changes, and to answer their questions about implementations and API inconsistencies and just does the API suck or not.

Slash commands have been in an open developer beta since December of last year. Changes are not happening until an additional 9 months from now, which will make it 1 year and 4 months / 16 months if I know how to do math correctly [sort of? April is 8 months from now, so 16 months is correct, but 9 months from now would be 17 months total] since slash commands were first released.

Many libraries do have support, some have unofficial forks. I will also say that for those intrepid developers they are pretty well usable without libraries, but I know that's a much bigger task to undertake. But if you haven't checked out using slash commands over HTTP and outgoing webhooks, it's pretty dope and pretty easily scalable.

advaith: cloudflare workers moment

Q: Do you know when forms are expected to be released? We were midway through rewriting for slash commands, then we changed it again for buttons and now forms are being released. An ETA would be great so we can consolidate our changes.

I don't have an ETA for forms, but I can share a little bit about how we're thinking about it. Forms are basically just a different visual for slash commands. At their core, they're a pre-registered set of things that an user will see when they do a specific action.

One of the things we've been considering is, what if we tried to autocreate forms out of slash commands, because we already know exactly what your arguments are and exactly what types you accept. That could be a way that forms actually work "for free".

However, I think there is also merit to being able to respond to an interaction with a dynamic form. Like, somebody clicks a button and you render a form for them that may not be a pre-registered command. I don't have an ETA on that but I do think there are those two separate use-cases.

Q: Will you consider allowing bots to see their owner's message content? This both ensures privacy and helps developers.

This is the first I'm hearing of this feature request!

I don't know. I guess I'd be interested to know why, other than convenience, I guess? I would need a bit more information, so I don't know. "So they can run their eval commands". Yeah. laughs

Q: What is the policy and/or guidelines for granting the message content intent? How leniently are you going to judge if something "cannot be replicated or otherwise implemented with interactions"?

We're not going to talk about policy specifics until we have a published policy.

Q: If we are granted this intent, will bots be sanctioned if they use it for their own use case but also to continue to run "normal" non-slash commands? Or do we assume that if you are granted the intent, you are trusted with it and are allowed to use it for additional uses?

Ian: We answered a similar question before. I don't know if you have anything to add, Mason.

Mason: Yeah, we did answer this similarly before. Like we said before, the message intent is intended to power "unique and compelling functionality that cannot be replicated by commands and interactions", so we would assume, and are expecting you to move your text commands to slash commands regardless.

Q: Are there plans to allow slash commands to inherit bot permissions for external emojis instead of the @everyone role? A lot of bots rely on external emojis to deliver information to their users and this will just leave them confused when external emojis don't work but the bot has the needed permissions.

This should just work, and if it doesn't, we'll take a look. Messages sent via slash commands actually use webhooks under the hood, and webhooks are, at least historically, have been granted access to just use whatever emojis they want. I don't see a reason why slash commands responses shouldn't work the same way, and if this is not currently the case, we can definitely look into it.

Q: How can an already verified bot get the message intents? And are some fun commands such as the "userphone" command in Yggdrasil bot and auto-moderation actually enough to get the intents?

I'm not going to talk about specifics of what's okay and what's not, but as far as the process goes, bots that are already- sorry, let me step back a second.

When we open the approval queues for message content, the thought is that it's going to look something like this: there will be a place for bots who are already verified to apply for it if you believe that you have a unique and compelling use case. That will be one avenue for people. Then, bots that are not yet verified will just have this request baked into the verification form, much like presence and guild members already are.

Q: What is the plan for implementing or replacing command aliases?

One of the things that doesn't currently exist that we definitely want to do is fuzzy matching commands. By that, I mean if you have a "now playing" command, and right now you have to match the exact string to get that command, it would be much better if you could do something like, /np and it matches your "now playing" commands. Sort of how it works right now with users and channels and stuff, like that fuzzy matching ability. So that's something that we want to do.

Secondly, a lot of the time, these aliases are for commands that people want to use very quickly. We have an experiment out on desktop right now (that is going to go to everybody eventually) to make frequently used commands, so commands that you use frequently in that server, at the top filtered out, so that'll be a way that we can easily access commands that you use a bunch.

Also, if you start typing specifics of a command, we will filter that list by frequently used as well. So, if there are three "now playing" commands in your server, the one at the top is the one you use most frequently. So, minimizing the amount of typing, maximizing the amount of tabbing and entering that you can quickly do to navigate.

I'll post a screenshot [below]. It looks pretty much exactly as you would expect it to look.

Example of the filtering

Ian: It actually makes it a lot easier to make slash commands, and not have to search through commands that you never use.

Q: What happens to bots that auto-react to some keyword inside your message (not a command)?

Look out for the policy that we will publish. That's the most that I want to say right now.

(I don't mean that in a doomsday way, sorry.)

Q: Will there be aliases to options, and will the number of options be increased? Some of my commands work like command line arguments. I have 30 options right now. I allow both full form and short form options (just like command line arguments). A lot of people prefer short form to save time but it's not a thing.

Ian: This is pretty related to the options discussion that we just had, but it's about options specifically, and a large number of options.

Mason: Let me show something very quickly. Yeah, why not.

Navigating options right now is not super great. There are plans to make navigating options a whole lot better.

There are two things you're going to see in this screenshot!

Example of options

Autocompleting options is definitely something that would make using this a whole lot better. Number of options - I don't know of anybody that - the use case to have more than 25 is a lot. If there are a lot of folks that are having this problem, please continue to give us feedback in this form, and specifics are always helpful.

Ian: We're coming up on time. We probably have time for one or two more questions. Did we talk about custom prefixes already? If not, the question is-

Q: Will you approve requests for message content for bots that want to continue using a custom prefix instead of slash commands?

Mason: Look out for the policy, but also, no.

Q: Can we filter strings based on regexes?

The thing that we're looking to do to filter channel types could possibly be used for regex on strings. The question is not necessarily the difficulty of doing it, it is the safety in doing it because regex is very powerful.

Q: Why add a new global-reaching intent? Why not let guild owners assign intents to bots themselves and let them take control of privacy instead of requiring bot devs to make decisions for everyone?

Like presence data, and like guild member data, there are certain things that we believe are inherently more sensitive at scale to have unfettered access to. The current permission model of bots and apps is that a server owner gets to agree on behalf of everybody in their server that it is OK for this thing to have this information.

That is a good model 99% of the time. If you required every individual person in the server to say "yes this bot can do X or Y", that would be pretty terrible, to put it mildly, and also ripe for abuse of "hey, I'm somebody who says this bot cannot read my messages and therefore I get to opt-out of your moderation capability". Like, that's not great.

So if we sort-of have this model where server owners get to agree on behalf of everybody, and we want to keep that model, but we do think there are things that are inherently a bit more sensitive, that maybe a single person shouldn't be able to just agree for everybody, we want to put those things behind a little bit more of an approval process and a little bit more of thinking of "is this something that is good, and not possibly harmful".

I will also say, not to put anybody on blast, as many as there are people who have legitimate use-cases for getting access to these privileged intents, there are a lot of folks that don't actually understand if they need this stuff to do what they're doing. I don't mean just moving from text commands to slash commands, I mean not actually understanding that the data they're trying to access through a model can be done without presence data, in slightly different ways.

So, that is why we have that approval process in place, because we think it needs to be in an approval process, and there are some people like "making bots on Discord is super easy!" and that's great and we don't want to change that. But it also means that people don't always understand the implications of what they have access to and other ways to do it.

Ian: I think we can end on that. We are at the 1-hour mark now.

I want to say thanks to everyone for doing this and engaging in this session, submitting all the questions. I had a lot of fun, and I can tell from Mason's voice that he had fun too. (Mason: I did. I like talking to you all.)

We're going to keep trying to do this stuff and communicating especially around the message intent. I know that there are a lot of questions that are still remaining on this list, we'll do our best to address a lot of them and give you all clarity as we figure out how to move forward over the next 9 months.

Anything else you want to say, Mason?

Mason: Apparently people want to know what microphone I use. It's a Blue Yeti. I've had it for a long time.

Thanks, everybody.

Copy link

nerrixDE commented Aug 5, 2021

awesome work spiral, appreciated


Copy link

Androz2091 commented Aug 5, 2021

thank you very much 👍


Copy link

a9ex commented Aug 5, 2021

Amazing work 👏


Copy link

NamVr commented Aug 6, 2021

thank you


Copy link

DraftProducts commented Aug 6, 2021

Thank you so much 💯


Copy link

sevenc-nanashi commented Aug 6, 2021

Maybe typo:

Q: Are there any plans to create some kind of menu where you can input test that opens when you interact with a button?

I think it's text


Copy link

spiralw commented Aug 6, 2021

@sevenc-nanashi thanks, fixed!


Copy link

shadeoxide commented Aug 15, 2021

amazing, thanks a lot


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment