Longer Custom Ids / Select Option Value Lengths

[Bedrockbreaker]

Issue

Currently, the limit of the lengths for both custom ids and (select option) values is 100 characters each. However, this can be quite short in certain situations, especially when used to maintain state throughout a series of interactions (one of their main purposes as described in the documentation).

Proposal

Preferably, this should be increased to what a slash command is able to send in a single interaction, since message components nearly act like shortcuts for slash commands anyway. If that's not entirely reasonable, then at least allowing the total character count of all custom ids/values in a message be raised to 2000 or something would still be a greatly welcomed change.

To justify, simply sending the ids of a few objects (guilds, channels, users) within a custom id takes up 18 characters each. Combined with other information passed along in a custom id, this can easily exceed 100 characters in some situations. (For example, some user has a select menu and chooses multiple users, which then updates the message with a panel of buttons to do some action to them (hug, steal their battleship, etc.). Each button would need to store all of the user ids, which rapidly decrease available custom id space. Sure, you could store the users in the message content itself, but that's not always pretty/good UI when displayed to the user.)

[Bluenix2]

I don't think this will ever happen, still, to fix your problem have you considered base64 encoding the IDs?

>>> import base64
>>> snowflake = 344404945359077377
>>> base64.b64encode(snowflake.to_bytes(8, byteorder="big"))
b'BMeSeRsEAAE='

That's 18 down to 12 characters.

[psibean]

To justify, simply sending the ids of a few objects (guilds, channels, users) within a custom id takes up 18 characters each. Combined with other information passed along in a custom id, this can easily exceed 100 characters in some situations. (For example, some user has a select menu and chooses multiple users, which then updates the message with a panel of buttons to do some action to them (hug, steal their battleship, etc.). Each button would need to store all of the user ids, which rapidly decrease available custom id space. Sure, you could store the users in the message content itself, but that's not always pretty/good UI when displayed to the user.)

I would say your approach is wrong, the custom id is only intended to allow you to identify the action of the interacted component. You should definitely not be putting user id's and other things in there - you should store them on the bots side, and identify them by some other means. You already have the ability to limit the interactions to just the user and to also scope the listening of interactions to the specified message, therefore:

As an example:

I would send the buttons up front in a disabled state.
Once at least one user is selected, update them to be enabled.
In your response to a selection, make sure you send back the values that are selected with default set to true, so they remain selected.
(in this case I can't think off the top of my head right now how you would handle de-selecting, you could have a button specifically for clearing selections)
If it changes so there are no selected values, set buttons back to disabled.
With users selected, pressing a button will thus enact that action on those users.

When they press the button, your interaction will still contain the information of what values are selected, so you can store those id's as option values (where the label is their username/nickname).

Another alternative:

When the user selects a user on the select menu, store them on your bots side (a map of id and user objects, an array, a Set, whatever), and edit the message content to let them know what users have been selected. If they select someone who has previously been selected, remove them from the storage on your bots side and thus remove them from the selected list in the message content / embed.

[muddyfish]

My current solution is to serialise all the data into the custom_id, but if it would be more than 100 characters, cache it in redis and generate a UUID for the key. This means most custom ids can stick around forever but the longer ones still need to be flushed out of redis every so often

[psibean]

Edit: Do note, I'd initially assumed you were OP, but the comment still applies!

I can't speak for your specific use case because I don't know your overarching intentions and your underlying architecture.

But the main point of my proposed example approaches was that, you wouldn't need to serialize any of that data, nor would you need to cache it if that data was always in the interaction payload that discord is sending you along with the users interaction. Which it would be in the first example. As for the second example, the data would still be in the interaction, you'd just be controlling it a bit differently and you wouldn't need to store as much.

As for the cache sweeping you can just time them out based on not receiving an interaction on a particular message for X amount of time and edit the message to remove the message action components, or if the message is deleted.

If you're using a framework (and not interacting with the API directly yourself) all of this would be relatively trivial to manage and shouldn't be an issue.

[muddyfish]

For my particular usecase, I do not include information already given in the request (yay). The problem with using a temporary cache is that buttons stop working when the application could otherwise support it, so storing all required data inside the custom id becomes desirable.

Say a reaction role, help command message or something else that could easily be made persistent would be helped considerably by having the data being persistent. Luckily for my usecases, I find most of these cases generally serialise to under 100 characters anyway, so temporary caching isn't necessary.