When an app is receiving reactions, it is ambiguous how they should be decoded for display. The README references smile as an example value, which maps to U+2323 in unicode...which is rendered as ⌣. But that's probably not the actual emoji you want, which would be 😊 ("Smiling Face with Smiling Eyes" is the official unicode title).
Is the suggestion that these values should be emoji shortcodes? If so, which kind? Github shortcodes are different from Slack and Discord shortcodes, and none of them are part of the unicode standard. Here's a list of all the competing shortcode standards.
I don't see how this is a practical solution without some metadata explaining to clients how they should decode the content.
Describe the solution to the problem
I would suggest that we add another parameter that specifies explicitly what schema should be used for decoding reactions, and that the default schema should expect unicode code points in the emoji range. If someone wants to send custom reactions, they should have to specify that the schema is custom (and which custom schema they are using).
For unicode emoji, the easiest and clearest is to use the character itself (😙). The unicode name is also standards-based, but the unicode character is going to be much smaller and less anglo-centric. It also doesn't require some library to map names to emoji.
If we really want to use shortcodes, the parameter should specify which shortcode dictionary the sender was using.
Describe the uses cases for the feature
Making it easier for apps across the ecosystem to consistently display reactions.
Is your feature request related to a problem?
When an app is receiving reactions, it is ambiguous how they should be decoded for display. The README references
smileas an example value, which maps to U+2323 in unicode...which is rendered as ⌣. But that's probably not the actual emoji you want, which would be 😊 ("Smiling Face with Smiling Eyes" is the official unicode title).Is the suggestion that these values should be emoji shortcodes? If so, which kind? Github shortcodes are different from Slack and Discord shortcodes, and none of them are part of the unicode standard. Here's a list of all the competing shortcode standards.
I don't see how this is a practical solution without some metadata explaining to clients how they should decode the content.
Describe the solution to the problem
I would suggest that we add another parameter that specifies explicitly what schema should be used for decoding reactions, and that the default schema should expect unicode code points in the emoji range. If someone wants to send custom reactions, they should have to specify that the schema is custom (and which custom schema they are using).
For unicode emoji, the easiest and clearest is to use the character itself (😙). The unicode name is also standards-based, but the unicode character is going to be much smaller and less anglo-centric. It also doesn't require some library to map names to emoji.
If we really want to use shortcodes, the parameter should specify which shortcode dictionary the sender was using.
Describe the uses cases for the feature
Making it easier for apps across the ecosystem to consistently display reactions.
Additional details
No response