Custom user emojis

[yretenai]

The feature wherein a user is given the ability to upload custom emojis (to a predefined limit.) These emojis should be force-prefixed with the user's handle in the form :dynaomi-smileyface: This is similar to how Twitch handles channel emotes where all of a particular channel's emotes are prefixed with a set term, as opposed to how Discord handles them (which suffixes the term with a counting number for each duplicate.)

This in functionality would replicate the functionality present with Discord servers.

Somewhat relates to #3

---

• [ ] Create routing and storage for uploading emojis.
• [ ] Write API endpoints for managing emojis.
• [ ] Extend status API logic to include emoji metadata (including links to the artifacts)
• [ ] Write frontend logic for showing and listing emojis.
• [ ] Write (helper) logic to list emojis of people you're following.
• [ ] Write frontend logic to disable an emoji per double click
• [ ] Write frontend settings (Circa #39) to enable or disable any or all user emojis.
• [ ] Create the ability for administrators to create instance-wide emojis.
• [ ] Write tests for all of the above (ugh)
• [ ] Write docs

[yretenai]

I'm personally not a fan of using existing emoji as it conflicts with how emoji are currently represented There are also older devices that won't fully render all emoji. Discord currently has this where using an UTF8 emoji in your username will render it as a block in some situations. The code for detecting these patterns will also exponentially increase in complexity.

[marrus-sh]

I think this is a good idea, but regarding implementation:

1. I actually think this should be broken up into two separate issues. The first is letting users redefine existing emojis. The second is letting instance admins and/or users define new emojis. I think that the implementation details regarding these are different and we should handle them with an eye to good fallbacks and federation. In particular, whenever dealing with existing Unicode emojis, we should federate them in a way that other instances will be able to understand.

2. Regarding existing emojis:

   1. I am not sure how I feel about tying emoji to shortcodes. I definitely think that emoji which have a unicode value should be federated as that unicode value, because I think that requiring clients to support emoji shortcodes in order to display statuses is overkill. Furthermore, if I define a custom 😅 emoji, I would like that to fallback as 😅 on unsupporting clients/instances, rather than :marrus_sh-sweat_smile: or whatever.

   2. So I think it would be better, rather than changing how emoji are encoded in statuses (as images or shortcodes or w/e), to leave emoji encoded the way they are currently but then also provide metadata either in the Status or Account object about which emojis are redefined. Where you put this information depends on how you want to handle forward-compatibility: If I redefine/delete an emoji, should it be redefined/deleted in all my past statuses or not? If so, the information should be stored in Account. If not, it should be stored in Status.

      I'm picturing just an array of emoji Unicode values and links to appropriate images that frontends can handle at will.

3. Regarding new emojis:

   1. I think there's a case to be made that only instance administrators should be allowed to define completely new emojis, and also a case to be made that anyone should be allowed to. I'm not sure where I stand regarding that but I think it's open for discussion.

   2. The precedent in the world of Unicode and Emoji (looking at implementations across the board: Twitter, Apple, Facebook, etc.) is to use Zero-Width Joiner (ZWJ) sequences (or emojification of existing glyphs) to define emoji that don't have Unicode representations. The advantages to this approach are:

      • They provide a plain-text fallback which is not tied to language. For example, Twitter's pirate flag emoji renders on unsupporting platforms as 🏴☠️, which is fairly unambiguously a pirate flag regardless of the language you're speaking. :pirate_flag:, on the other hand, is only a pirate flag if you speak English.

      • They provide a canonical version of every emoji. Oftentimes emoji will have multiple shortcode representations; for example, 🏳️‍🌈 might be :pride: or :rainbow_flag:, but it is always 🏳️ + ZWJ + 🌈.

      I don't particularly like the situation where you have a Mandarin speaker typing emoji into their toot only to find that it federates as a bunch of English words that they don't necessarily understand. Emoji aren't tied to language and I'd like them to stay that way.

   3. But even granting the ZWJ approach, the question then becomes how to define them. This is easy enough for instance administrators to do, you just add an custom_emoji.yml to the instance or provide an input area in instance settings or whatever, but this is more complicated to do for end-users.

[marrus-sh]

In general, I think “clients/instances should support Unicode” is a safer and more reasonable demand than “clients/instances should support replacing arbitrary strings of ASCII(?) characters with images.”

[yretenai]

It is safer you are not wrong, however it's a double edged sword.

It has a very low entropy point.

The common case with all of those is that there's a single body behind who decides which ZWJ combination becomes a unique character, in this request I call for everyone to be given that freedom. That freedom will be abused if restricted to UTF8 characters in a chain.

But because of the nature of being federated even restricting it to just instances, there will still be the random instance that has 🌈🏴🌈🏴🌈🏴🌈 as an emoji shortcut. We see this with Reddit where people are using the "language" function of reddit (which in essence is replacing the subdomain with a 2~4 letter country code) to apply several themes or filters to the subreddit. This completely breaks the intended use of the function.

There is no win solution to a method where it won't end up looking like a garbled mess for anyone that isn't using the spec.

Sidenote: Chrome has really big issues with cursor placement and ZWJs, I had to re-write that paragraph four times before I gave up and chose different emoji.

Sidenote 2: There are unlocalized emoji. 🆕 🆖 🆓 🈚 🈹

[yretenai]

In short: We can't federate custom emojis.

[yretenai]

So custom emojis would either have to be dealt with in one of three days:

• Restricting it to just administrator-level ZWJ emoji
• Parsing toots to remove ASCII-emoji
• Restricting either ZWJ or ASCII to local toots from unlisted or private toots/accounts.

[yiskah]

I don't like any feature that discourages federating a post out, so I am against limiting the ability to use the feature based on post-scope. The admin-level ZWJ emoji option seems like the easier to implement and the most interoperable. It does not cause problems for the network as a whole. Ideally users are on small enough instances that they can easily communicate with admins and their community about custom emoji to implement (even a 4000 user instance I think is probably small enough to manage that kind of communication). It keeps it to a level of being their community in-joke rather than something which would promote silo-ing and thus make it more difficult to communicate with admins.

The one thing about the ZWJ option is users would need a way to easily put the ZWJ character there which is supported by other instances. The emoji-picker inserting it is easy enough but having that be the exclusive method creates accessibility issues for people with RSI/wrist mobility issues who depend on keyboard shortcuts for ease of living. We could create a short-code for ZWJ but it'd be necessary for the shortcode to be replaced by the unicode before sending it to other instances, since those instances might not support the shortcode and it'd be silly to be sending over :zwj: rather than just

It's important to me that this is restricted to the admin level as I could see this being abused by bad actors who could create essentially "sensitive content emojis" which could not be hidden like an upsetting image. There'd need to be vetting of what images are used, so that should happen at the admin level.

[yiskah]

oh wait duh

:customthing: is converted to when federated out. no need for special :ZWJ: code

[beatrix-bitrot]

I'm also leaning toward the admin level ZWJ option.

@naomichan are you ok with that?

[marrus-sh]

Yeah to be clear I'm not expecting users to input ZWJs themselves I'm expecting shortcodes that are converted by the backend and federated as such.

[hannahwhy]

Mastodon 2.0 introduces custom emojis, and glitchsoc has them as well. This seems to satisfy most of this issue's original goals, with (AFAICT) three major differences:

1. only an instance admin can modify an instance's custom emoji list
2. Mastodon 2.0 uses shortcodes in the statuses; it does not convert shortcodes to ZWJ sequences
3. users cannot disable individual custom emojis; only admins do that

However, it looks like this issue evolved to also only allow admins to modify the emoji list, and shortcode input is used by both this proposal and the Mastodon 2.0 implementation.

Can we consider this issue closed and open new issues for the parts of the upstream implementation that we want to change?

[beatrix-bitrot]

yep, i'm going to close this and we can address any emojo related shortcomings in other issues and PRs, though i am not sure any are urgent at the moment