Custom emoji for long-run

[akihikodaki]

The implementation of custom emoji is optimized to provide additional server flavour quickly. However, it has several problems when considering to run the feature for a long time:
1. limiting choices of instances by emojis

1. Sources of copied emojis are unknown
2. limited namespace
3. limiting ability to create emojis for those who are not admins, don't know how to launch an instance, cannot ask admins to add an emoji

1 can effectively construct some kind of norms that users should be in a particular instance so that we can use common emojis. For example, if an emoji named :catnip: become quite a popular as if it is an Internet meme, people interested in it would move to the page. They may even say "why don't you come here to use the cool emoji?" That is against decentralization. Solved with #5231.

For details of 1, see #5287.

2 is caused by the broad namespace and the write-once architecture. The emojis are shared in an instance (some instances are quite a large even now), and the emoji cannot be removed, replaced, or renamed without breaking the statuses already made.

3 matters when Mastodon accepts users who are far from Web development community. Such users can be easily found in some large instances like mstdn.jp or Pawoo.

Here I suggest solutions corresponding to those challenges.

Remote emoji fetching feature (breaking, #5145)

It was suggested by @Gargron at https://mastodon.social/@Gargron/19389045. Though he mentioned it as "copy", I consider it should be implemented by tracking the source of emojis in order to cache or block emojis, and to potential copyright dispute.
This would be realized with a breaking change of federation and database:

• ActivityPub's Emoji will refer to an Image as icon, where the Image has an id to track the source.
• OStatus's href of link[rel=emoji] would now point an entry which has an id and link[rel=enclosure].
• The database will have shortcodes table which references custom_emojis.
• custom_emojis will have uri column.

Scoped shortcode (breaking)

shortcode is a currently permanent, domain-wide identifier. However, it is seen by users and connecting the internal implementation and the UI without any reason.
By limiting the scope of shortcode to statuses, statuses would keep consistent representation of emojis.
This would also involve a breaking change on the federation and the database:

• ActivityPub's Emoji would be put in attachment where it is currently put in tag.
• (no change for OStatus)
• shortcodes table will belong to statuses.

Emoji creation for accounts (#5072)

This does not involve any federation change.

icon attribution

This adds attributedTo to ActivityPub representation of the image.

---

Tagging priority - high; whether this will be wontfix or not, this issue should be closed before releasing 2.0. We are expecting more people will involve in the discussion (https://mastodon.social/@Gargron/19575435). This is a feature request anyway so it matters whether you think those features are nice to have or not.

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[nolanlawson]

You raise some really interesting points!

emoji cannot be removed, replaced, or renamed without breaking the statuses already made

I think this may be the most serious issue. An admin could change an emoji after a status was already posted, which could alter the original meaning. This is almost like allowing admins to edit people's posts…

[akihikodaki]

This is almost like allowing admins to edit people's posts…

That is not really a problem for Mastodon since we have assumed admins are not evil when considering security, UX or whatever, as far as I can tell.

The problem is more technical. Even if you are the admin, you cannot update the federated emoji because they are cached without binding to statuses; other instances has no means to know whether emojis are updated are not. You cannot reuse the same name and need to add fixes (e.g. :emojo:. :emojoex:, :emojoexex: if you adopt old good Windows naming)

By the way, if you are concerning cases an admin is evil, you may consider about emoji creation for accounts. While Mastodon assumes admins are not evil as I said, it always allows to migrate to other instances as the last measure. However, emojis bound to instances may make people reluctant to migrate to other instances because of emojis they have used.

[akihikodaki]

I have found two existing problems are related to scoped shortcode.

One is avatar emojis of friends.nico. friends.nico allows to use avatars as emojis. Such emoji features not constrained to the context of the domain custom emoji could be interpolated with scoped shortcode.
In other words, the emoji feature is highly dependent on the context of Mastodon.

The other is introduction of static image (#5107). Such change of emojis can be implemented safely after introducing scoped shortcode. Currently it is not possible and we cannot update the feature of emojis such as animated/unanimated, format, resolution or whatever.

It is an open-ended question to what extent we make it "flexible", but I think it is reasonable to use the existing feature of ActivityStreams/JSON-LD to maintain the flexibility (id). At least, I do not think there is a reason to reinvent the wheel with domain-shortcode pair.

[akihikodaki]

I'll close this issue. I'm no longer interested in the feature because the emoji feature landed with 2.0.0 and there is no way to implement but adding a different protocol.