Delete Ephemeral Message through API Endpoint

[Rohit3523]

Description
Currently we can only edit Ephemeral Message but we can't delete Ephemeral Message through API Request.

Why This is Needed
Deleting a Ephemeral Message will help us to show a temporary message to user who used Slash Command.

[jhgg]

I'm not sure the point of this - ephemeral messages are already temporary and can be dismissed by the user.

[muddyfish]

Say you're running a command which uses buttons and ephemeral messages.

In some cases you'll have multiple messages displayed, and editing the message takes up horizonal space, especially if the user is trying to perform other actions at the same time

[monbrey]

It should be possible to at least fetch an ephemeral reply.

POST /interactions/<interaction_id>/<interaction_token>/callback always returns a 204, ideally this would just return the Message object to us like POST /channels/<channel_id>/messages does, but that isn't the case currently.

For a regular response you can instead use GET /webhooks/<application_id>/<interaction_token>/messages/@original to fetch it, but this doesn't work for ephemeral messages - the API will return DiscordAPIError: Unknown Message

However, PATCH /webhooks/<application_id>/<interaction_token>/messages/@original will return a message object for both ephemeral and non-ephemeral messages, so the data does exist. I don't see any reason not to allow it to be fetched.

This will become relevant with future interactions that need to be linked to specific messages, such as buttons in ephemeral messages. The interaction payload includes the message, but without doing a dummy PATCH request to get an ID the two can't be correlated.

[SpencerSharkey]

I would like to see this feature, too. Although a user could suppress it themselves when they no longer see the need for it, allowing the application more fine-grained control of the message history would help make for a cleaner UX in some scenarios.

For instance, a simple ephemeral confirm/deny button dialog prompt could self-destruct once an answer is provided with no more interaction from the user.

[bassner]

Dropping my thoughts here as well:

This is really important. I understand that these messages are not stored, but please give us

• a timeout option that we can send with ephemeral messages that makes the receiving client auto-dismiss it after X seconds
• the ability to delete them manually using the interaction endpoint. This could be realized by sending an event to the receiving client to inform them about this.

I have a use case where users click a button, and get an ephemeral messages like "Please check your DMs". Afterwards, I have a more complicated flow in DMs.
Users may use this button several times per hours, and these "Please check your DMs" messages stack up if they don't manually dismiss it. I'd love to remove this clutter using timeouts on your or my side, whichever works best for you.

But the timeout options seems to be most feasible as it's only an additional data point when sending ephemeral messages, and one call to set a js timeout in the client, so it might be an easy option for you guys to implement.

[IanMitchell]

So my personal opinion as a user and bot dev is that ephemeral timeouts or deleting ephemeral messages isn't a great UX pattern to encourage. Timed messages are easy for a user to miss, and they aren't forgiving if a user takes a certain amount of time to read and comprehend a message (especially common if it isn't in their native language). Since ephemeral messages are unique to a user, we also lack tools to alert the user what happened to the disappearing message they had just been looking at - it won't show up in the Audit Log for instance. I don't think it's clear the bot deleted it in this case.

I think y'all want this to fill a product gap we have rather than wanting the functionality itself, though? What I mean by that is I think if we built out alternative responses - something like a toast notification or Notification Center maybe - we wouldn't need this functionality as much?

[bassner]

I think it's a needed thing.
Example:

My bot has a message with a button in a server channel where no one is writing in. Clicking it spawns an ephemeral message that tells the user to read the DM I've just sent to him. It'd be good to be able to delete the ephemeral message as soon as the user interacts with the DM I sent.

No one else is writing in the channel with the first button. It's basically a fixed message in a fixed channel. Users might want to use it multiple times, and every time it spawns an ephemeral message that doesn't go away. They stack up, and the client shows maybe 6 times "Hey Joe, please have a look at your DMs!". It looks weird, and is not cool, and I want to be able to delete them.

The assumption that ephemeral messages don't last longer than 15 minutes seems to assumes that they are sent in channels with active chatting. That's not always the case. For me, they don't go away any time soon unless I restart.

One could move this type of functionality to a notification center, but as a user, I want to see some kind of feedback when I press a button, and it should be near to that button, otherwise I might press it 10 times because I think it doesn't work. An ephemeral message is a good solution here, I can even link to the DM. But really, I need a way to clear them.

[ckohen]

Ultimately, ephemeral messages are not intended to be used that way in my opinion. For one thing, sending a user a dm is an act of acknowledgement, a response, user feedback. Discord currently doesn't have a way to say, "hey, i've acknowledged this interaction some other way than these few predefined methods" and that's a recurring theme which I hope is being worked on.

Another thing to consider is why send a DM at all? If you want the message to persist, that's understandable, but if you're going to resend the DM every time, why not just put the content in the ephemeral message? Part of the point of ephemeral messages is to stop that annoying pattern of execute bot action, bot sends DM, switch to DMs, switch back to server. Plus, they completely eliminate the issue of people having their DMs closed.

I want to see some kind of feedback when I press a button, and it should be near to that button, otherwise I might press it 10 times because I think it doesn't work.

Yes! Precisely! Ephemeral (or normal) messages sent in response to components or context menus already have problems with this! Try using a context menu on a message when you are scrolled to "older messages". If the bot sends a response, its a new message at the bottom of the message history that doesn't give immediate feedback. The same happens with components. This is a problem! (Oh and for ephemeral messages you won't ever be able to see the message, but IIRC that's being worked on).

I think what's come to light here is that devs are forcing ephemeral messages to be something they're not, because its currently the only way to avoid sending a standard message and deleting it. Personally, I treat ephemeral messages as send and forget because, as you say, my buttons are always in a static channel with no other content. That means what a person sees when they click a button is that message, and they have to consciously make a choice to click the same button or dismiss the message, because the original message has moved. And if I'm doing this on an already ephemeral message, its a simple edit instead of a new send in order to avoid clutter.

They stack up

I mentioned it before but I'll say it again., I think this is the main problem trying to be addressed here. However, I personally, as a dev, initially hated ephemeral messages because of this, but I realized the majority of users won't ever encounter this.

[bassner]

Another thing to consider is why send a DM at all?

Well, yes, this is in some way a legacy thing coming from the years of operating this bot when we had no other choice.

I initiate a private flow in DMs that requires to user to talk back to the bot one or multiple times, choose options, etc. Still, it's not solvable through interactions, due to missing ephemeral inputs (forms, multi-line-text).

However, even if we get something like multi-line text-input, I'm not sure if I should move that at all. As opposed to you, I don't consider DMs to be a bad way of performing a complex 1:1 interaction between a user and a bot. In some way, it's even a feature exactly built for that (communication between two users). I'm even getting a very much more visible "notification" (dunno if that's the right word) if my bot needs some time to perform a task, and then wants to follow up; with ephemeral channel follow-up messages, I might get a ping on a server. With DMs, I get my own bubble on top of the server list. Me, for my part, doesn't care about server pings. I get waaaay to many of them, and one more red mark with a number in it won't raise my attention. A DM will.

DMs have valid use cases in my opinion, and if I (in my own creative process of writing my own system) decide that it's a good idea to move a flow to DMs, it'd be cool if I could auto-clear the message I use to tell the user about this location change. Usually, I even just include a link or button that get's them to the DM in one click, so it's not really an interruption either.

Just give me the choice, and a very, very simple tool to make it look clean.
Maybe this is something I'll change in the future if Discord comes up with a very sophisticated new interaction type that solves all my problems. For now, this a pain point, and one that is easy to solve.

[sbrocket]

It’s not just ephemeral message build up, though build up is (with my user hat on) somewhat annoying for some interaction patterns. I don’t see how a Notification Center-like affordance would be a net benefit since it seems like that would involve pulling the responses out of the channel where the user issues the command, but maybe I’m not imagining the right thing. In any case that’s not the only issue.

There are two scenarios where I’ve wanted this, though the second one will go away once we have better multi-line input support, so I’ll just talk about the first.

My bot has a command to create a new clan event. The interaction responses are ephemeral since there’s no need for the creation flow to appear to other users, and the final response includes an embed with the event details. The bot posts messages with this same embed elsewhere (in channels that list all scheduled events) and keeps all such embeds up to date as users join the event or the event is edited.

I don’t want to leave an embed behind with stale event details that I can’t update after the interaction token expires at 15 minutes. Since there’s no auto-expiration or way to delete the response, right now I have to hold on to the token and make sure to edit the message to remove the embed before the token expires.

[ckohen]

You both bring up excellent points.

I'm even getting a very much more visible "notification"

Yeah, again that problem of a much more visible response than a message but you have to send a message thing 😢

I don’t see how a Notification Center-like affordance would be a net benefit since it seems like that would involve pulling the responses out of the channel where the user issues the command

Yeah, I don't like bringing it completely out of the flow, but something other than a message element would be great. It would especially help (and make possible) with user context menus in voice channels (which got removed because there's no where to send the response!). I believe there's a future in which not everything is associated with a channel, maybe guild context menus?

I don’t want to leave an embed behind with stale event details that I can’t update

I have seen this point a few times. Maybe a solution to this is an ephemeral response type that directs to another message (since you're duplicating it) that once interacted with automatically dismis?

[Longhouse81]

I have multiple points about this topic:

• Be able to close on interaction complete. (User clicks a button, interaction closes, users doesn't have to close the msg themselves, saves the bot having to edit the msg on completion).
• Towards users auto close on the expiration time. (No need for them to see an interaction that they can't use anymore).
• API response when interaction gets closed before or on the expiration time. (to be able to get feedback and on the bot side taking the steps to remove listeners or any other stuff instead of keeping it up until expiration time).

Now keeping in mind there should be a way to also set auto deletion or not, sometimes you just want to display responses without any interaction of users, and then it's not timebound and users can close it themselves.
I would more opt-in to add the option for auto close on expiration and completion of interaction with an optional parameter on the creation of an app response.

[philipaarseth]

This limitation seems pretty arbitrary.
If the idea is that it would be confusing for users if they didn't have time to read the message before it disappears, then why is it limited to ephemeral messages? It's surely as or more confusing if a normal channel message (where multiple people can read it) disappears quickly?

One of our use cases for ephemeral messages is gathering user input then editing that ephemeral message over and over like a in-channel multi-step form. Then when they're done, the what is essentially a notification that they're done sticks around until they manually dismiss it. I can't imagine the people that have completed several such submissions would not think it's a chore to dismiss all the leftovers.

For our use case a multi-step dynamic modal with some kind of notification at the end would work, but it looks like we're several steps away from that happening since modals are quite limited at this point.

I quite like the timeout idea, maybe with the addition

• a hover to suspend countdown.
• don't start countdown until ephemeral message is in view (if user is scrolled away)
• a minimum timeout. Say at least 5 seconds

[advaith1]

This feature was added in 2022: https://discord.com/developers/docs/change-log#delete-ephemeral-messages