Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to interaction responses and flags #2615

Merged
merged 6 commits into from
Mar 5, 2021

Conversation

msciotti
Copy link
Contributor

@msciotti msciotti commented Feb 17, 2021

Slash Commands UI Changes

DISCLAIMER: These changes are still being worked on so this PR will merge when they are complete

Hey all! Another day, another update. This time, we want to talk about UI changes and how we're gonna support them.

We've gotten a lot of feedback that the in-chat view of commands could be improved:

We agree. After seeing some bots integrate and using Slash Commands a bunch ourselves, we've decided to take some extra steps into making slash commands feel better than just copying what bots did before.

Check out the designs here

There's a few changes within these designs:

  • Slash commands and bot responses are now combined into one message
  • All slash commands now have the "User used" source message and a bot response. You can no longer hide the source
  • The raw text of the source command can be seen on hover on desktop or by tapping to bring up a half sheet on mobile
  • You can't send a public source message with an ephemeral response, or vice versa. Both will be either ephemeral or public because they are now one message, controlled by the flags field
  • "ACK" responses are being changed to "deferred" responses. They function the same way, but now indicate in the UI to the user that the bot is thinking, instead of not getting any acknowledgement

Why?

  • Having two separate messages felt weird. The "source" message was fairly useless, and took up a lot of space in chat
  • We needed to clearly show sending, pending, and error states to users in a way that they understood what "step" was being processed
  • Having a bot response without a user message, or vice versa, was confusing and led to inconsistent behavior, expectations, and designs
  • It looks a lot better, doesn't it?

API Changes

To support these new designs, we're going to be deprecating two interaction response types:

  • Pong is the same

  • Acknowledge will be deprecated

  • ChannelMessage will be deprecated

  • ChannelMessageWithSource will be the same

  • AcknowledgeWithSource will be renamed to DeferredChannelMessageWithSource

    Additionally, sending flags: 1 << 6 for an ephemeral message response will make both the source message and the bot response ephemeral or public.

    Here's the proposed updated data model:

    Interaction Response Type
    Name Value Description
    Pong 1 ACK a Ping
    ChannelMessageWithSource 4 Respond immediate to an interaction
    DeferredChannelMessageWithSource 5 ACK an interaction and send a response later
    Example Public Immediate Response
    {
      "type": 4,
      "data": {
        "content": "Hi this is a response":
      }
    }
    Example Ephemeral Deferred Response
    {
      "type": 5,
      "data": {
        "flags": 1 << 6
      }
    }

@GamingGeek
Copy link
Contributor

For the ephemeral response demo in the figma, is the initial source message visible to everyone while the command is being sent/application is thinking or is it only sent when the application responds?

@msciotti
Copy link
Contributor Author

msciotti commented Feb 17, 2021

@GamingGeek there's a few states:

When the interaction is still being sent to Discord's servers, the source message is only visible to the invoking user.

When the third-party server responds, if it decides to respond ephemerally, the message will stay visible to only the user and we'll add the blue background.

If it decides to respond publicly, the message will appear in chat for everyone.

We didn't add the blue ephemeral background for the initial "bot has not yet responded" state because it was too jarring.

@GamingGeek
Copy link
Contributor

@GamingGeek there's a few states:

When the interaction is still being sent to Discord's servers, the source message is only visible to the invoking user.

When the third-party server responds, if it decides to respond ephemerally, the message will stay visible to only the user and we'll add the blue background.

If it decides to respond publicly, the message will appear in chat for everyone.

We didn't add the blue ephemeral background for the initial "bot has not yet responded" state because it was too jarring.

Ah, makes sense. Thanks for the clarification, the changes look great :D

@monbrey
Copy link
Contributor

monbrey commented Feb 17, 2021

If you defer responding with a 5, how do you then issue the deferred response? Is that a 4, or a follow-up message?

@msciotti
Copy link
Contributor Author

@monbrey thank you for the question. You do so by using PATCH /@original. Let me update the docs.

docs/interactions/Slash_Commands.md Outdated Show resolved Hide resolved
docs/interactions/Slash_Commands.md Outdated Show resolved Hide resolved
docs/interactions/Slash_Commands.md Show resolved Hide resolved
docs/interactions/Slash_Commands.md Show resolved Hide resolved
docs/Change_Log.md Show resolved Hide resolved
@MeguminSama
Copy link
Contributor

Any chance of "bot name is thinking" being customisable? whether returned in the deferred response, or set globally on the bot.

@Snazzah
Copy link
Contributor

Snazzah commented Feb 17, 2021

  • Is DeferredChannelMessageWithSource only visible to the user who invoked the interaction?
  • Can you add a flags prop when editing the original message? (In order to make a DeferredChannelMessageWithSource become ephemeral)

@advaith1
Copy link
Contributor

ephemeral can be set in the initial "deferred" response, see the example at the bottom of the post and #2615 (comment)

@msciotti
Copy link
Contributor Author

msciotti commented Feb 17, 2021

Any chance of "bot name is thinking" being customisable? whether returned in the deferred response, or set globally on the bot.

@MeguminSama you could technically customize this yourself but not doing a deferred message and sending an immediate response that looks like a loading message. Customizing that system string is not something planned.

I'm open to other, less anthropomorphized wording though. "Waiting on bot_name", or something else

@prryplatypus
Copy link
Contributor

"Awaiting response from XXXX"?

Co-authored-by: Advaith <advaithj1@gmail.com>
@ckohen
Copy link
Contributor

ckohen commented Feb 17, 2021

Just to be clear, with these changes there is no way to respond without a channel message correct? E.g. Some of my commands currently use ACK with source and send a message with the bot separately that gets deleted next time the command is used. This is done mainly because these messages are embeds that have minor changes with each usage and clutter up the history. However, that history is still nice / important to see for some commands.
I can think of a workaround for now - suppressing embeds on the message so the source is still visible at least.

@msciotti
Copy link
Contributor Author

@ckohen that is correct. There always has to be both a source message and a bot response message, but you can choose if they are public or ephemeral.

We designed this for what we believe is the 99% use case of command --> reply, but are aware that there are other cases where you might not need a separate reply (our remake of Airhorn bot is this way currently, actually). For now we're going to err more on the side of standardization and wait and see what everyone does once this thing is launched and has widespread adoption.

But, these are comments/thoughts that we are aware of 👍

@ckohen
Copy link
Contributor

ckohen commented Feb 17, 2021

Thanks!
On another note, #2410 seems to be closed by this PR. It natively provides the message object when using deferred due to the necessity to PATCH @original and I think this may end up being way more common than channel message anyways in order to avoid the risk of missing the 3 second timeout. Further, there's no longer an id of the "source" message.
Edit: I realize this is probably not "closing" the PR because of the tracking for the GET endpoint.

@advaith1
Copy link
Contributor

advaith1 commented Feb 17, 2021

I think this may end up being way more common than channel message anyways in order to avoid the risk of missing the 3 second timeout

well that doesn't really change anything; sending a normal channel message will still be used and support for getting that message (without the PATCH workaround) should still be implemented

@LatvianModder

This comment has been minimized.

HopeBaron added a commit to kordlib/kord that referenced this pull request Mar 5, 2021
* remove redundant map structures

* code cleanup

* [WIP] - Rewrite Interaction Commands

* Fix incorrect name reference

* abstract rootName instead of name

* Move documents to declaration and rename Command

* More docs

* correct sub-commands in docs

* Fix filtered no-arg sub-commands

* Add interaction serialization tests

* Add interaction type testing

* mark test class with KordPreview

* WIP: Add resolvables

* WIP: Use flows for resolved objects

This most likely will be changed to a set or back to a map

* Resolvables first prototype

* Rename OptionValue to DiscordOptionValue

* Create a core OptionValue to hold resolvable entities

* Hold resolvable entities in the interaction command

* consider MemberOption a UserOption

* Serialize message flags as longs

* Add Ephemeral flag

* Change interaction response types

discord/discord-api-docs#2615

* Use deferred response type for acknowledgement

* Revert Message flags to ints

* Fix incorrect endpoint call

* Add multi-command put support

* add mapeValues for maps data structure

* Correct the json representations for new interactions

* Add DmInteractions and GuildInteractions

* Use put instead of post for bulk command registration

* remove resolved field from interaction object

* make deaf and mute optional

* Core representations for bulk command end points

* Code cleanup

* Fix serialization for roles

* Expose allowedMentions to followup builder (#187)

* Apply suggestions

* Code cleanup

* Fix predicate and apply few tweaks

Co-authored-by: Michael Rittmeister <michael@rittmeister.in>
@msciotti
Copy link
Contributor Author

msciotti commented Mar 5, 2021

Changes are in! You'll see them next week when we turn on the feature flag in the API. It's disabled for now to give old clients time to get new code.

@msciotti msciotti merged commit ac350ce into master Mar 5, 2021
@msciotti msciotti deleted the interactions/response-changes branch March 5, 2021 21:12
@AnotherCat
Copy link
Contributor

I'm guessing that this #2615 (comment) is not possible, but can i get confirmation of this?

arqunis added a commit to serenity-rs/serenity that referenced this pull request Mar 8, 2021
… type (#1252)

This updates the interaction types to reflect the changes as laid in the slash commands UI changes pull request for Discord's API documentation: discord/discord-api-docs#2615. 

This removes the `Acknowledge` and `ChannelMessage` interaction response types, as they have been deprecated and scheduled for removal on the 9th of April, and renames `AcknowledgeWithSource` to `DeferredChannelMessageWithSource` to suit a better purpose. 

Furthermore, a new `MessageInteraction` type and its corresponding `interaction` field in `Message` is added.

Additionally, a fix is incorporated to the interaction responses builders to use the correct field name for embeds (`embed` -> `embeds`).
HuyaneMatsu added a commit to HuyaneMatsu/hata that referenced this pull request Mar 10, 2021
References:

discord/discord-api-docs#2667

- Update application command limits.
- Add length assertion for `ApplicationCommandOptionChoice.value`.
- Add `ApplicationCommandOptionChoice.__len__`.
- Add `ApplicationCommandOption.__len__`.
- Add `ApplicationCommand.__len__`.

discord/discord-api-docs#2615

- Add `InteractionType`.
- Add `InteractionEvent.type`.
- Add `Message.interaction`.
- Add `file` parameter to `Client.webhook_message_edit`.
- Add `file` parameter to `Client.interaction_response_message_edit`.
- Add `file` parameter to `Client.interaction_followup_message_edit`.

discord/discord-api-docs#2690

- Add `InviteTargetType.EMBEDDED_APPLICATION`.
- Add `Invite.target_application`.
- Add `target_application` parameter to `Invite.precreate`.
- Add `Client.application_invite_create`.

discord/discord-api-docs#2692

- Add `ChannelVoice.region` attribute.
- Add `region` parameter to `ChannelVoice.precreate`.
- Add `region` parameter to `cr_pg_channel_object`. (Inherited by `Client.channel_create`.)
- Add `region` parameter to `Client.channel_edit`.
- Handle voice client disconnect when moving between voice channels of different regions.

Public API:

Coroutine generators yielded or returned from slash commands are handled as coroutine generator slash commands themselves.
Add `SlashResponse` class.
Update `slash.md`.
Add `'number'` annotation to slash commands.
Add `emoji.md` to topics.
Add `Application.precreate`.

Internal:

Fix a broken docstring in `Color` (Reported by NeKun#9509).
Add `URL.subdomain`.
Add `URL.raw_subdomain`.
Slash commands dropped back type based annotations.
Redo slash command syncing to handle extensions correctly.
`Application.__new__` could not set `.flags`.
Update links in intro.
Fix formatting issues in commands extension.
`Extension._unload_extension` did not use executor when rendering exception traceback.
Missing `ApplicationCommand.__ne__` caused errors (inheritance issues probably).
Update `Guild.precreate.__doc__`.
Remove unused `Guild.has_animated_icon` attribute (was removed like 1 year ago, lol).
Add `region` parameter to `Guild.precreate`.
Handle voice client player and reader stop when the guild's voice region changes.
Do voice client reconnect for close code `1006`.
`User.has_higher_role_than_at` could return `False` when the other other is not in the guild meanwhile self is.
LiBa001 added a commit to LiBa001/discord-interactions.py that referenced this pull request Mar 13, 2021
@Andre601
Copy link
Contributor

Not sure if this was asked here before (or if there are particular reasons for this) but does it make much sense to mention the name of the bot in the command message now?
Since the command is now "attached" to the response of the bot does it seem pointless to have with <bot> on it. Just having <user> used /<command> would now be enough to have here.

I'm referring to this here for those who aren't sure what I mean.
I also want to point out, that these changes, despite what is said here aren't live yet? Like it's more than a week now and I still see the bots using the old format, so unless they need specific changes to their code does this seem to not be live yet...
I personally doubt that the bot in question uses outdated code as it is used to test the Slash-command integration into JDA which is a current WIP thing...

(Oh and sorry for anyone I annoy with this message)

@advaith1
Copy link
Contributor

  • yes it was changed to just user used /command
  • the changes aren't live yet due to app store issues

@TorKallon
Copy link

Any news on when this will be live?

@RedDaedalus
Copy link
Contributor

The change got pushed back due to an app store issue, last I heard the issue is resolved and the api change will go live in a few days so people have time to update.

@MichaelJHarvey
Copy link

Looks like the change has gone live.

@Abu-Maher
Copy link

YouTube together future, how can I make it with slash commands ?

@TwilightZebby
Copy link

@Abu-Maher You don't. It's an experimental feature and you shouldn't be trying to give yourself access to it by any means... Also, the YT/Voice Activities thing has nothing to do with this PR and Slash Commands/Interactions.

@somebody1234
Copy link

somebody1234 commented Mar 26, 2021

Will attachments be possible with Edit Original Response (when using deferred response to do processing)? Currently, attachments can't be uploaded when editing messages

Are you sure they aren't already? Maybe you should try this out

interesting; looks like its undocumented but you can upload attachments while editing webhook messages and interaction responses, not for normal messages tho

would anyone happen to know if it also works when creating webhook messages and interaction responses?

@advaith1
Copy link
Contributor

@somebody1234 it's already documented for creating webhook messages so that isn't new; it doesn't work for creating interaction responses though (gotta use deferred + edit original for that)

@remyjette
Copy link

Is there any way to edit/delete the original message if it's ephemeral?

I can PATCH and DELETE at the /@original endpoint just find if I don't set flags, but if I set "flags": 64 on the InteractionApplicationCommandCallbackData then trying to talk to /@original gives me a 404.

@GamingGeek
Copy link
Contributor

Is there any way to edit/delete the original message if it's ephemeral?

I can PATCH and DELETE at the /@original endpoint just find if I don't set flags, but if I set "flags": 64 on the InteractionApplicationCommandCallbackData then trying to talk to /@original gives me a 404.

Ephemeral messages are not stored so the API does not know it exists once the message is sent, hence the 404

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.