Standardization of Unicode Emojis accepted by the API

[davfsa]

Description

I would like to continue the discussion in #2723 and request a standardization of what Unicode Emojis the API accepts as valid.

Why This is Needed

After looking at what Discord uses internally in the client (thanks to @Emzi0767's extraction of the internal list) they all seem to use Variation Sector 16. This differentiates them from Twemoji, which is where Discord seems to get all the emoji svgs from. To have a 1-1 mapping you need to remove the Variation Sector 16 if it is the second codepoint and the emoji is less than 4 codepoints long (for some reason the gay-pride flag is an outlier). This means that there is no widely accepted emoji mapping that developers can follow.

Furthermore, without any sort of strict validation from the API, developers cannot know what a "valid" emoji is (one that will render equally across all applications) and the lack of documentation makes us follow no standard. This causes confusions in both mobile and desktop apps for users as well as for developers. Examples of this can be seen bellow:

Users:

Mobile view of reactions without and with Variation Sector 16: (taken from here: #2723 (comment))

Desktop view of reactions with and without Variation Sector 16:

Developers:

With no consistency across what is considered a Unicode Emoji in Discord's terms, there can be cases where you want to detect when a user reacts with a specific emoji, but have no guarantee if that emoji will have a Variation Sector 16 or not, leading to bugs which are confusing to debug if you don't know about this (specially if you use desktop, as can be seen in the screenshot above)

Alternatives Considered

Instead of forcing what emojis to send, Discord could normalize them in the endpoints backend, thus allowing more inputs but ending in the same output. Downside of this one is that some people check for the reaction using the same emoji they sent, which would cause confusion.

[Emzi0767]

I'm Commander Shepard and this is my favourite issue on the repo.

I'm personally in favour of server-side normalization. Considering that it's a giant lookup list, and the rules for when the selector is optional are more-or-less trivial, it is not too difficult to implement.

[JDJGInc]

I also say tying it to the api and then having the wrappers being able to grab this emoji list too, so people can grab valid values :D

[JDJGInc]

Please make this a thing.

[davfsa]

@IanMitchell could this be moved back to an issue, it is also a bug. I was only able to mark it as a feature request when I created the issue, not as a bug

[IanMitchell]

I don't think I'm able to move it back as an issue, unfortunately - you can open a new issue though and link to it here, and I'll close this out

[davfsa]

Is there anyway we could keep the comments that were made?

[IanMitchell]

Unfortunately no - I'd just open an issue with a link to this discussion, and then post a link to the issue here and I'll mark that as the answer