Message Content Access Deprecation for Verified Bots

[IanMitchell]

Hi everyone! We have an important update to share.

As the popularity and number of Discord bots grow, it's important to keep our users and developers safe and healthy. This means from time to time, like any maturing platform, we need to update our policies to reflect the current needs of the ecosystem.

In April of 2022, message content will become a Privileged Intent. Like other privileged intents (Presence and Guild Members), it will require approval and affect only verified bots.

If you run a verified bot, or a bot that you plan to get verified in the future, we recommend starting to transition to new functionality like slash commands and other interactions.

We want to help make this transition as easy as possible, so we're starting off by providing plenty of time (nine months) as well as hosting an "office hours" in the Discord Developers server where you can ask us questions or flag any considerations. This will be on Wednesday, August 4, at 11am pacific. We will be sharing our answers to questions that come in for those who want to read but can't make that time.

We're also continuing to invest in interactions as the future of bots, including new slash command option types, better moderation controls, and new types of interactions.

• You can read the full details in our help article here, along with an FAQ: https://support-dev.discord.com/hc/en-us/articles/4404772028055
• If you have questions or concerns, we'd appreciate you filling out this very short survey to help us centralize feedback: http://s.alchemer.com/s3/f1811257ea63. We'll use these responses as discussion topics for part of the office hours and to help inform our roadmap.
• We have opened a #message-intent channel in our Discord Developer server

Thank you all for your help in making this change with us. We know it's a big one, and we know that the future of bots on Discord remains incredibly exciting.

[Andre601]

I just drop in here to provide some reasons as to why I currently won't switch to Slash commands and, given the planned deprecation, most likely will discontinue my bot if these problems/features haven't been fixed/added yet to Slash commands.

• Slash commands don't support new lines yet.
  I was told that a fix is on the way and should be implemented within the next 3 months(!!!) If this really takes this that long will I already have lost a 3rd of the supposed time we have to move.
• No option to set/mark a command as NSFW.
  My bot does offer some NSFW commands, I don't make a big secret out of it. And I honestly won't remove them because people use and like them. But I also don't want them to just show in plain sight to everyone, so a way to tell Discord to only show and allow some commands in NSFW channels would be appreciated. [Related Discussion: NSFW Slash Commands #3312]
• No way for multiple instances of one Option.
  One option, one value. That's how it is and it is extremely limiting. My bot offers multiple commands where you can provide multiple members through mentions and now limiting it to a single user argument is extremely bad. One user even mentioned that he likes the fact that you can mention multiple people to f.e. hug them, spreading the love. So please allow this to continue. [Related Discussion: Slash Commands: add variadic arguments #3286]

Those are the most prominent issues I currently have with the slash commands and why I don't use them yet.

[GoldenAngel2]

Another thing I'd add to the list is since slash commands is being pretty much needed for bots, why have a separate scope for it.
All bots would need applications.commands now so it doesn't make sense to require 2 scopes for the bot to function in the server.
And there currently isn't a way to tell which servers have the scope added until you make a request(I've already brought this point up with Ian but most likely doesn't hurt to be posted publicly)
Imo keeping the scope will just cause more issues for bot developers(and support-staff for bots) as they're the ones that is going to handle angry users when it doesn't work for them.

[RedDaedalus]

The scope mostly serves to allow applications to provide commands without the use of a bot. A way to set required scopes would be nice.

[MMaximum]

I do agree with @Andre601 but one issue with slash commands is, The api would sometimes fail or crash in the process plus discord need to remove option to remove slash commands on bot invite since it breaks bots quickly, we are forced to use the same prefix, this is the dumbest decision by discord, why? Discord Developers ain't getting updates at all sometimes the message would fail but when discord says screw this and forces all developers to be in slash commands is the dumbest decision and it can ruin the company in many ways,

Resolve Problems via doing this

you could make it so when the bot prefix is triggered it gets the bot to respond and not see the message on there unless it's requested via making a allow bot to read messages on a prompt via cycle.

[Andre601]

The scope mostly serves to allow applications to provide commands without the use of a bot. A way to set required scopes would be nice.

Downside of the scope is, that bot accounts may show as offline if the bot is Rest-only, which can give the impression that they are not active and therefore broken/discontinued.
Maybe have a heartbeat-like setup for applications.commands only bots would be a way to go?

[Aya-Komichi]

I would like to go into detail on why I believe this entire idea is just not ready to happen so soon and I would also like to give an alternative idea that could be far better.

1. You are forcing all the bots to have the same prefix with slash commands. In case you don't know, there's a good reason why all the bots have different prefixes, to avoid interference and confusion in servers with more than 1 bot.
   1.1. Your answer to that is an UI that is quite small for the amount of commands some bots will have. Well made embed help commands can do better than that.

2. The great majority of the bots rely on a discord wrapper and many also rely on a command framework. Most libraries do not support slash commands at all or do not give a full support, that means it might take a while before these bots have libraries they can properly use for a rewrite. And even for the bots that do not use a 3rd party library whatsoever, those will require a major rewrite.

3. You are enforcing a feature that not so long ago wasn't even ready for a proper release, yet it got released anyway. And even now, it is very limited. Like Andre601 mentioned it doesn't even support multiple line input and support for that will take 3 months for that to happen and it also only supports one option. How do you expect bot developers to go around that? Simply by killing of that feature?

4. With slash commands, you are limited to 100 global commands and many bots offer 100+ commands these days. Now granted, sub-commands are a thing that was done before and could be done again now, but with the already complex rewrite necessary for the vast majority of discord bots, that's another task to take care off.
   4.1. Also this would make some commands more complex to be comprehensible by the end user and also harder to document.

5. The Discord users themselves aren't used to slash commands yet and they will even have to re-invite the bots with your current plans for their scopes like GoldenAngel2 said.
   5.1. Even if you inform them of such changes, you can't expect all of them to understand them.

I support the fact you want to bring more privacy to the end user, but this change you're proposing is too drastic and downright outrageous. What I purpose would be a much simpler solution that should be compatible with every single discord library out there, provides just the same amount of privacy and does not have the current limitations of slash commands.

What I suggest is to instead make all discord bots only receive message events of messages that start with their prefix. This would require every discord bot user to go on the Discord Developer Portal and set their intended prefix(es) for their bot(s). Verified bots without a prefix set, would not receive any message events. You can also enforce some rules such as minimum of 2 characters for a prefix if you would fancy so.

Edited: changed the point 1.1. and removed the 1.2. since it isn't true at the present moment, sorry for the possible confusion caused over those.

[DEVTomatoCake]

I agree fully, but the prefix idea wouldn't work on bots with a per-guild prefix.

[Andre601]

Maybe a guild-dashboard for bot-specific settings (i.e. what channels commands can be used in, which should be active/inactive, etc) could be an idea to set a new prefix for a bot and its command.

In general should Discord try helping the devs in managing their commands. If we're supposed to use THEIR slash commands should they at least give a way for the end user to choose where what command should be used.

I mean, we already have a dedicated place for bots, which is the Interactions section, so why not add command settings there?

[Aya-Komichi]

I agree fully, but the prefix idea wouldn't work on bots with a per-guild prefix.

True, I don't really know how they would get around that. Another reason to simply just delay this update longer.

Edit: nvm did not read Andre's response beforehand. That's a good solution.

[GoldenAngel2]

One more thing I'd like to mention.
With the current setup for slash commands it's not possible to limit a bot to a certain channel.
Example: Dank Memer's slash commands only be used in #dank-memer channel etc.

It's not possible to do it via permissions due to the way interactions work, it would require all bot developers to add a system for servers to configure the bot/application to only respond in x channel
Which is a shit setup and gives less control to the actual servers.

While I know they're looking into the 100 global & guild command limit(and some other limits) there isn't any news on how or when they plan to fix this issue.

And imo everything with slash commands need to be in place before they even decide when/if they make the message intent required.

Overall slash commands are good but barely anyone uses them which is a huge problem and is going to cause issues for bot developers and their support staff, it's the bot devs & support staff that has to deal with the blow back from their user base for a decision that Discord forced onto them and everyone else.

I do have hopes for the entire system getting better but now really isn't the time when everything is still up in the air with everything.

[c43721]

I think this is a great change, and if this means that slash commands and message components will have a higher priorty for releases, then I'm all for it.

I strongly believe this change is great, especially because only ~10% of bots (speculation) have the commands that truly need the message content to do their fancy stuffs. However, the other 90% of bots really just serve commands (again, speculation). The need for reading message content for commands is not really something that should happen, and as long as there's enough library support for slash commands and building them, then I think this is 'migration' from message prefixes to full slash commands can be justified.

Also, libraries are going to have all the support, at least the major ones, way before this change is actually in effect. Discord.js for example is doing great with thier v13 release, and I can assume the same with other languages like discord.py. I don't believe library support will become a hinderance to this migration, and in fact, will probably come faster with the added pressure, but that may be a good and bad thing.

I also believe the gripes that Andre601 has are valid points to have a discussion on, seeing as restricting commands is the most important thing right now. There's a lot missing from slash commands that are needed before my bot can be migrated, but I have full confidence that Discord, within the next 9 months and with enough developer feedback on the API, will be able to make this switch easily and confidently. The last 9 months have brought in a lot of new features, and I think with the work Discord is doing, the next 9 months will be filled with the tools we as bot developers need to make this switch.

I may as well add that this is a change in 9 months, and I don't think there should be a lot of anger regarding the "but slash commands aren't doing x or y" point that's brought up so many times. I don't think there's any grounds for this argument since it's something that can improve 10 fold over the next 9 months. Furthermore, the suggestions of how to make slash commands would be much more of a benefit here rather than the arugments against this new policy. When there's more support for the slash commands, there would be almost no reason to not use them. In fact, if you're planning on a rewrite or next major version, there's probably good intent you should migrate to slash commands now- most libraries support it, and if not, you can find a package that can work short term, though that's quite a a bodge there.

In summery, this change is good; not only will it force developers to use bare minimum from the Discord API, thus saving bandwidth on WS events (and saving the planet from that CPU usage time!), but it will also help bring the slash commands and message components to the degree Discord showed off last year. The argument that this is not a good change because it will hinder developers abilities to make custom bots is invalid because if Discord is offering a way to improve your ability to make it clearer for end users to use your bot's commands, I think that's enough of a justification to deprecate support for reading user messages. There's really only a small margin of users who can make use of commands that need message content to work, and those who need that support, well, they can just request it.

[N1C0exe]

They cant ask us to re write a big part of code this is the point

[c43721]

May I add, would you consider this intent to be pushed back another 6, 8 months to make room for these updates to take place?

Or, better yet, Discord releases the toolings we need first, maybe take the 9 months to 'complete' their slash and message components, then give a 6, 8 month notice for the intent to be enabled for verified bots?

Do you think this would be a viable alternative to what we have now?

[swarley]

The deadline won't be moving. But yes, it should have been set after the replacement was completely ready

[N1C0exe]

For me not . I prefer if the things stay like before. Maybe they can do another type of secuirty improvements

[c43721]

I think this is a good step for end user privacy, but I can get behind the idea for the features to come out first to allow solo devs to implement the features needed for their migration.

I think this is a valid point to bring up with the Discord discussion, seeing as there's lots of controversy on the affect this may have on the open source community in particular with solo developers (like me!). I hope to participate, and encourage you all to do so as well.

[mniip]

I've submitted the exact same thing in the survey, posting it here for the world to see and maybe comment on:

---

As I said I understand "why" discord is making these changes -- that is, I understand what problem is being solved there, and I agree that it is a problem and that it needs solving. But I do not understand/agree with the chosen general direction of the solution.

The overall strategy that Discord seems to be executing is that all interactions with bots have to conform to a fixed list of pre-defined rules. You're expanding the list, that's great, but it's still fundamentally rigid. Bots of the past were first-class users of the platform, they could do most things a user could, and you could interact with your bot in any way that the platform could proxy. You didn't have to selfbot because you could just create an actual bot (unless of course you wanted to automate something specifically related to your account, in which case tough luck).

You may think that you've made great UI/UX choices, but they're just that -- a subjective choice. Bot developers might have their own choices based off their understanding of the process. You're robbing the bot developers of the freedom to make that choice for their bot.

These kinds of freedoms are what made developing bots for discord fun, and a lot of bots are developed by a single person or a very small team, just because it's fun. Bots had their own identity, a personal touch from their creator. Instead now Discord is trying to advertise bots as more a part of the platform, a Discord feature that you can enable on your server (ignoring the fact that it's developed by someone else).

My personal pet peeve here is the kind of bot that you don't specifically address, but which instead reacts to certain parts of your message, and automatically augments it with its own information. You're just having a normal conversation with someone, and the bot adds onto it. For example, it could be looking for hashtag issue numbers and provide issue tracker links; it could be looking for code blocks and evaluating code in it, for demonstration purposes; it could be looking for LaTeX and rendering it. Considering the usage pattern of such bots, it would be detrimental to require the users to manually request an interaction with the bot in these cases. Having the bots automatically extract triggers from message contents is part of the magic.

And so this "strategy" leads into the rules you'll be using to decide whether to grant or deny the message content intent. If your understanding of how bots should be is "everything is slash commands, buttons, context menus", then you will be denying the intent to people who want custom interactions with their bot via messages. And I can definitely see how you come to this: if bots reading message contents is a problem, then the bots that do want to read message contents better have a damn good (security, moderation) reason for it. But this is where I and a lot of other people disagree.

And the 100+ guilds distinction doesn't really matter here. It would be a double standard to say that small bots can do what they want. Sure if someone is making a bot as they're learning making bots, or learning programming in general it's different. But when someone is making a tool that they're intending for others to use, either as a productivity tool, or even just for entertainment -- it doesn't really matter how popular the tool is. You shouldn't restrict access to core features based solely on how popular a bot is.

So if you were more lenient with your assumption that every single thing must go through interactions, and actually were willing to accommodate for other types of bots -- then we could have a productive conversation about how to reconcile the root issue (bots snooping on a ton of messages they have no business snooping on) with the existing bot ecosystem, where bots might still want to read some messages.

Here's an example of what that might look like:

• Come up with a "pattern matching" system that strikes a middle ground between human-readability, developer-usability, and scalable performance. (Something like globs comes to mind, you could have stuff like !* -- anchored to the beginning, or *$*$* -- anywhere inside).
• Have bots declare patterns that they want to see, in a way similar to slash commands: global and guild-specific.
• When dispatching gateway events or message-related HTTP responses, check whether the message matches any patterns the bot has declared for that guild, if not -- censor content.
• Require manual verification/approval for patterns that match all messages or look like they would match a lot (to prevent e.g. *e*).
• Let server admins see the patterns that each bot uses, in server settings and when adding the bot. (Actually why not let everyone see).
• A bot might request additional patterns but the server admin will have to approve them. (Some bots might have per-guild prefixes and this is how you would facilitate this).

P.S. There's already talks among bot developers to just implement terms moderation into their bot to get approved for message intent, so the fundamental assumption of your system is already broken.

[mniip]

Like it sure is an interesting idea, but it would then require bot devs to understand stuff like glob patterns or regex (if that would be used) and not everyone understands this...

It's a sketch of an idea ("Come up with...", "something like") that I provided just to demonstrate that there's leeway in design space. But if the core principle of "interactions are interactions" stays in place, then all of this is moot anyway.

[c43721]

I really like the explaintion you gave, and I like the points you came up with.

The solution offered does look and feel reasonable too. I wonder how this may be considered as a potential alternative to the problem Discord is outlining in this announcement.

[DigiDuncan]

**Hold on a second!**

You are about to grant a bot read access for ALL messages in your Server!

Bots cannot read messages in your server by default and clicking "I understand" will allow this bot to do so.
This means that the bot will be able to read every message you send in your server, including those about which Wumpus is the best one (It's clearly shiny Wumpus!).

It's recommended to first read the [Privacy Policy]({bot_policy_url}) of the bot to see if it collects and uses messages for certain things.

[ I Understand ] [ ...better not ]

Wow, you're really good at writing like Discord! That's a legit really good message, it conveys the point and still sounds fun. Is this your job? 😅

[Andre601]

**Hold on a second!**

You are about to grant a bot read access for ALL messages in your Server!

Bots cannot read messages in your server by default and clicking "I understand" will allow this bot to do so.
This means that the bot will be able to read every message you send in your server, including those about which Wumpus is the best one (It's clearly shiny Wumpus!).

It's recommended to first read the [Privacy Policy]({bot_policy_url}) of the bot to see if it collects and uses messages for certain things.

[ I Understand ] [ ...better not ]

Wow, you're really good at writing like Discord! That's a legit really good message, it conveys the point and still sounds fun. Is this your job? 😅

Unfortunately no. I'm just more of a guy writing documentation and stuff...
But I have spend enough time on Discord to more or less know their style of writing.

[quirky-bluejay]

I think that the "check this box to allow this bot to view messages" fundamentally won't work. Sure you're giving the user the 'choice'. However it's firstly the illusion of choice as a large majority of bots will request this solely for prefix commands making the bots not work without access and unlikely they'll find an alternative, and secondly most users won't likely understand how bots work and what the potential for abuse is, and people have the tendency to give bots way more permissions than they need (eg administrator)
It's a nice idea, however I don't think it addresses the issue of bots having access to message content at all.
It seems like the cookie banners from a few years ago, the ones where the only options were yes or don't visit the site. People will visit the site, or in this case use the bot regardless.
I may not agree with the pace and implementation of this change, however i do not see any effective alternative.

[ghost]

Bruh, the slash commands are just so bad and uncomfortable tho

[TwilightZebby]

@NexTheMighty Suggestion: Maybe suggest ways Discord could improve Slash Commands, instead of only saying "they are bad" which doesn't help them to know how to improve going forwards?

[cmsteffey]

Hey yall, moosh here.
Just putting my 2 cents in - In short, I don't feel like this change is ready to happen yet, even in April 2022. I feel like this is a problem that needs solving (message privacy), BUT -

I feel like interactions as a whole are still half baked. Slash commands don't support variadic arguments, which is a huge deal, because the best solution for now is to slap an absolutely massive amount of optionals in the arguments list. That looks bad, and can be confusing.

Multi line string arguments don't exist either - some bots use form-style input, and this completely messes that up, because those devs have to split up and inline their form, which doesn't look easy to use, and can be overwhelming for the end users.

Attachment arguments don't exist - Some bots (for example, bots with ID cards with custom backgrounds) need those, and attachments are hidden in this change too, which is a huge hit against the systems of those bots.

There are many other argument types that are currently text parsed, that are not supported, such as dates, timespans, code, and more

I remember the biggest deal with slash commands was supposed to be serverside and clientside validated arguments - what's the point of that, when there's so many arg types that the only way to implement is through a string arg you parse yourself? Even a regex arg type would be amazing, if we could filter user input that way.

All of those aren't even my biggest issue with this, and what I feel like is most important that we get an answer for. My biggest issue with this change is that we don't know what components and slash arg types will be available before this change hits - we have a doomsday date, but no way to see what tools we have to survive it.
I frequent the discord developers server, and occasionally there will be messages talking about the future, but there has been no official statement listing what will come, to my knowledge.

It'd be better if you all did like threads, and posted the api structure for upcoming things, and a promise to implement them, that way we can at least prepare, even if it's not usable stuff yet.

[ckohen]

I remember the biggest deal with slash commands was supposed to be serverside and clientside validated arguments - what's the point of that, when there's so many arg types that the only way to implement is through a string arg you parse yourself? Even a regex arg type would be amazing, if we could filter user input that way.

I'd like to mention discords own new built in /thread command fails clientside validation and has to hit the server before failing. It presents the need for restrictions on input types like string (length, allowed characters)

[DigiDuncan]

I like Slash Commands. I like Interactions. I'm excited for the future. But I'm concerned with how quickly this was rolled out and how lacking communication on what we can expect has been. Slash Commands and Interactions are not ready for the primetime, and us bot devs are not stuck waiting for our libraries to implement features that don't even fully exist yet.
Here's my current list of concerns and grievances.

• No Union type arguments. I can't make a /help [string or channel], for instance.
• No variable-length arguments (there'd probably be the restriction that these have to be your last argument, but they should exist.)
• No aliases (I'm not flooding my commands list with duplicates, and I'm not wasting my 100 slots.)¹
• 100 slots. 25 subcommands. It's just not enough for a lot of use cases, including some of my currently-existing commands to be ported.
• No non-Latin characters (this isn't an issue for me, but I'm sure someone writing a /帮助 command is going to be really upset by this)
• No custom prefixes (unlikely to change, but realistically, the current system is not good enough to replace what we had in this regard. The menu is clunky, somehow too large and too small at the same time, and all around not fun for users to navigate. Also, if I just keep typing, which bot does it choose? It's so unclear.)

I also would like to know what other Interactions are planned. so we can plan around them. Will we get a text field? Checkboxes? Sliders? Knowing this changes a lot about how I design these next few months.

Again, I'm excited for this update, but it being this rushed and incomplete has me and many others worried.

¹ Here's my proposal for aliases.

[MMaximum]

Seems like discord is ignoring the fact, you said you would help developers and getting choices done, but this escalated to someone insulting discord but that's not the others fault and we just want discord to hear our voices, plus you'll be killing discord messages for bots in the future which more developers will leave.
Maximum#6402- YouTuber / Bot Owner I don't expect discord to listen to this. We would rather not have the bots not able to see messages or in slash commands since it may cause issues with developers rewriting there entire bot.

[alexhorner]

I thought I'd put my 2p in here both from the perspective of a bot developer using a 3rd party library and as a user of slash commands (and pulling some feedback from users of my bot too).

I will start off by repeating some of the points from earlier comments to get that out of the way:

• I agree with the intent here to protect user privacy and I do agree with the underlying problem and solutions of restricting it by an intent. - I think the 100 server limit is very double-standard and pointless as it is killing the ability for large and trusted bots to use a feature whilst allowing any old random bot (especially in the case of "Invite me for free nitro!" type bots which you cannot deny happens too often and a ton of people fall for, even with verification) to access sensitive information
• Slash commands feel half baked (will discuss more below)
• User backlash is a problem and us developers are getting the crap for the change
• Permissions on a per bot basis are a necessity

From a user perspective

As a user migrating from prefix commands to slash commands I have encountered a few small issues which have been incredibly frustrating:

• When starting to type slash commands, sometimes Discord doesn't immediately know what command I am typing and it takes a second or two for it to identify and highlight the desired command, meaning I hit enter, expect something to happen, Discord does a little jiggle (like when sending a message in a slowmode timeout period) and nothing gets processed - I have to hit enter again
• When I have finished typing a command, for example /devtools, if there is only one matching command, Discord will immediately select it and push me into the first argument.
  • I see why this seems useful, but what it does instead is mean I now hit space and have a double space, or I backspace and it removes the argument not the last character of my command.
  • A better example of how annoyed I got was I have a /devtool stop command and I kept typo-ing /devtool s stop because Discord put my S in the argument when I intended, incorrectly, to do /devtools stop. I ended up changing the command to stop the frustration which would have been okay had it not been blown out of proportion by the automated switch into the argument. there must be other people and other commands causing this issue
• There are commands I use habitually with a prefix. Changing prefix is doable but many users are upset including myself. This could be considered a "boohoo poor you, get over it" but I think it is a big problem when you have users who have done commands for literal years and are now forced to change

From a developers perspective

• I can't expect all new Discord features to become immediately available in my library. This has been discussed before above
• I have frequently used features which react to emoji being sent in chat. I can't even view emojis in messages if you kill message content. I may as well add another bot to the server specifically to bypass the 100 server limit, just for this emoji feature to work. Big pain
• 9 months isn't enough when I don't even know whats going to change in that time, presumably a lot. Finish the job before forcing me to use the half baked toolset
• My command groups show as separate commands instead of typing the first part then getting suggestions (like enum arguments) of available subcommands. Okay, I can get over that, except they're in one big list? Why? Why aren't they UI segregated groups like the name suggests? You can't even see the group description! I expect you'll fix this but again, half a job.
• Pings don't work on modifying a thinking response. I understand why you don't want to ping on a normal response, just like we don't with normal user generated messages, but a thinking response? That should ping, at least on the first edit from thinking to the final response
• I can't go back to a thinking message? I'd like to do something like Command executed -> thinking -> initial response with buttons -> button pressed -> thinking -> final response
• I like the idea mentioned above about pattern matched prefixes. I really don't like the / prefix, it jumbles everything together, and also, its hard for some mobile users to reach meaning they just don't bother

If I can think of anything else to add I shall reply,

Thanks!

[alexhorner]

Oh - I forgot to mention - the new scope is a pain! Please at least add the ability to retrospectively change scopes on an integration in a way that is easy for users - I don't mean just reauthorising a bot, I mean a switch in the interface or something!

[Aya-Komichi]

Finish the job before forcing me to use the half baked toolset

100% agree, but to be very honest, the way this feature seems to be, I don't think it can quite replace prefix commands in every extent. Slash commands were meant to use built in commands only for a long time, just like for example in Minecraft. And now pushing every single command from every single bot onto there is gonna get messy anyway. In my opinion part of the concept really needs to be reinvented.

[DigiDuncan]

A better example of how annoyed I got was I have a /devtool stop command and I kept typo-ing /devtool s stop because Discord put my S in the argument when I intended, incorrectly, to do /devtools stop [...]

This concerns me, because I have separate commands /stat and /stats, and this is going to cause immense pain if this is true.

[alexhorner]

A better example of how annoyed I got was I have a /devtool stop command and I kept typo-ing /devtool s stop because Discord put my S in the argument when I intended, incorrectly, to do /devtools stop [...]

This concerns me, because I have separate commands /stat and /stats, and this is going to cause immense pain if this is true.

This isn't speculation, this is an experience I had

[Andre601]

I had similar experiences with Discord's /nick command.
Like I have a bot on my server that uses text commands (not slash commands) with a / prefix and it offers a /nickname <user> --random option to randomize a user's nickname...
But because Discord offers a /nick command, and because the client is shit at understanding what commands I actually want to use, did it think I meant /nick and auto-splitted the input right after that. So /nickname became /nick name at the end...

This is a prime example of how bad slash commands can be...