-
Notifications
You must be signed in to change notification settings - Fork 577
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
Custom emojis: fallback standard emoji #1401
Comments
Clients should just display the shortcode text if a custom emoji can't be rendered. |
Yes, I understand that. However, imagine a user wanting to use a custom happy face emoji which they think looks nice. Obviously if there is no Unicode emoji which represents the same meaning, then no fallback will be provided by the user and the shortcode will be displayed. |
This reminds me of when Apple changed the gun emoji from a pistol to a water gun and people accidentally sent each other death threats. |
Except I am suggesting no such idiocy. Apple has no chance of adding parameters to tags of Nostr events. |
Are you developing a client? I would suggest adding a shortcode list into your client with fallbacks by shortcode. |
Yes, although this wasn't, obviously, meant just for me.
Shortcodes are ephemeral and non-standard. |
I am writing this in relation to NIP-30 for custom emojis.
Custom emojis are images.
I support the idea of making custom emojis, instead of limiting ourselves what the Unicode standard provides.
However, I think it would be reasonable for certain clients not to embed images at all.
Some clients could be purely text-based (maybe usable trough a TUI or CLI) and able to display standard emojis (which are text), but not images. Others may be configured to not to fetch arbitrary URLs.
Sometimes pure text may need further processing.
I think it would be a good idea to allow users to, optionally, specify an additional parameter to the
emoji
tag, which will contain a Unicode fallback character which has a similar meaning to the emoji.This can also be displayed by clients which do support images whenever a certain image cannot be loaded.
The desired behavior by the author of the note is still to display the custom emoji, of course. But maybe a Unicode replacement would be better than just the code of the emoji.
The text was updated successfully, but these errors were encountered: