Open Aspie96 opened 3 months ago
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. It would be more than reasonable for that user to select a happy face Unicode fallback emoji to display in place of the shortcode. It is much closer to the emoji semantically and differs only by an aesthetically.
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. It's the author of the note that would choose the fallback emoji, out of free will.
Apple has no chance of adding parameters to tags of Nostr events. If they could do so Nostr would be broken.
Are you developing a client? I would suggest adding a shortcode list into your client with fallbacks by shortcode.
Are you developing a client?
Yes, although this wasn't, obviously, meant just for me.
I would suggest adding a shortcode list into your client with fallbacks by shortcode.
Shortcodes are ephemeral and non-standard. Any user can use any shortcode and point it to any image. Of course, a smart user will use a meaningful shortcode (aware of the fact some clients may not display custom emojis), but not necessarily "standard" ones. Replacing a shortcode with my own opinion of what Unicode emoji it represents might not be what the author of the note would want. If it's the author of the note that has chosen that particular fallback emoji, it means that it matches the author's intention of what the post should say.
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.