Skip to content
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

Open
Aspie96 opened this issue Jul 30, 2024 · 6 comments
Open

Custom emojis: fallback standard emoji #1401

Aspie96 opened this issue Jul 30, 2024 · 6 comments

Comments

@Aspie96
Copy link

Aspie96 commented Jul 30, 2024

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.

@alexgleason
Copy link
Member

Clients should just display the shortcode text if a custom emoji can't be rendered.

@Aspie96
Copy link
Author

Aspie96 commented Jul 30, 2024

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.

@alexgleason
Copy link
Member

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.

@Aspie96
Copy link
Author

Aspie96 commented Jul 30, 2024

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.

@alexgleason
Copy link
Member

Are you developing a client? I would suggest adding a shortcode list into your client with fallbacks by shortcode.

@Aspie96
Copy link
Author

Aspie96 commented Jul 31, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants