As someone who has developed several #ActivityPub software implementations ([Fedify], [Hollo], [BotKit], and [Hackers' Pub]), I believe one of the most frustrating features to implement in the #fediverse is #custom_emoji.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri

(This is in Japanese. Please use machine translation.)

カスタム絵文字については以前から問題意識があって、Fedibirdの実装を通じて解決策を模索してきました。

FEPを検討しているなら、ぜひ拾い上げてください。ひとまず概要を。

・スクエアではない絵文字の取り扱い

・アクセシビリティと多言語対応

・コピー許可と権利情報

・センシティブの扱い

・画像形式やサイズ、アニメーションの互換性やガイドライン

以下は、カスタム絵文字に付与可能な属性をできるだけ記載したサンプルです。

添付画像は、画像化されたテキストを中心とする絵文字に対し、代替テキストが設定され、ツールチップ表示されているサンプルです。

この絵文字のObject表現（JSON）はこちら。
https://fedibird.com/emojis/prohibits_importing_to_other_servers_ja.json

人間向けの公開ページはこちら。
https://fedibird.com/emojis/prohibits_importing_to_other_servers_ja

Fedibirdのcustom_emojis APIのエンティティ
https://fedibird.com/api/v1/custom_emojis/prohibits_importing_to_other_servers_ja

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri When reconsidering the specifications of custom emoji, it would be a good idea to also take into account the information provided by emojis defined in Unicode.

Unicode emojis provide a string that describes what kind of image is depicted, as well as a translation string, so I think it would be better to use them while taking compatibility and consistency into consideration.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri For non-square custom emojis, you should provide width and height in the API response (entity).

This will help client app developers recognize and support non-square emojis.

This is actually very useful, as it improves the user experience by allowing efficient layout before fetching the image.

This may not be necessary for ActivityPub S2S, but it may be useful if you have a case where you can use a dummy image as a placeholder when you can't handle the emoji image.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri @thisismissem Fedibird currently provides the following information to help users understand the content of custom emojis:

- alternateName (alternate_name)

- ruby

- description

alternateName is not a shortcode that serves as a handle, but an alternative expression or name for the emoji content in text.

ruby is equivalent to the ruby ​​element in HTML. It is also useful as an index when selecting a custom emoji from a picker, especially in CJKV.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri @thisismissem description provides detailed information that explains the content of the custom emoji, but it may contain unnecessary content and may not be appropriate for screen readers. alternateName may not provide enough information, but I think it will be sufficient in many cases.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri @thisismissem The server can register and store information in other languages ​​and provide it based on the user's preferred language.

However, it is difficult to expect all custom emoji providers to fill in this information in multiple languages, so we will have to rely on machine translation to some extent.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri @thisismissem Permission for custom emoji has become a particular issue in recent years.

This calls for custom emoji to be treated as something that the creator retains the rights to and is available under various restrictions, rather than being provided in the public domain where each server can copy and use it.

Traditional custom emoji do not assume conditions of use, so information on these is necessary.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri @thisismissem Fedibird has proposed and implemented several attributes that are considered necessary for conditions of use and licenses. However, when it comes to formulating specifications, the discussion is difficult to reach a consensus, and it is difficult to reach an agreement. Therefore, in addition to these, we have proposed an attribute called copyPermission.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri @thisismissem This takes the values ​​allow, deny, and conditional, and provides only information on whether copying is allowed, whether copying is not allowed, and whether copying is allowed only if the conditions of use are confirmed and understood.

We propose that each server implementation should support at least this information as soon as possible, and promptly improve the current situation in which copying is being made against the wishes of custom emoji providers.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri @thisismissem We've outlined some of the ideas and implementations we've had in Fedibird so far, as we work to improve support for custom emojis. We hope this will provide a foundation for development and discussion of new features.

[noellabo@fedibird.com]

@hongminhee @silverpill @ozoramore @julian @liaizon @tesaguri @thisismissem Additional information. Misskey includes free text regarding emoji permission in the object, and information is shared between Misskey users and Fedibird through the federation.
https://misskey.noellabo.jp/emojis/noeskey

_misskey_license: {
freeText: ""
}

The content is not machine-readable, so administrators must read it and make a judgment.

[silverpill@mitra.social]

@noellabo Very interesting, thank you!

What value goes to alt and title attributes when custom emoji is rendered? Is it alternateName?

@hongminhee @ozoramore @julian @liaizon @tesaguri @thisismissem

[noellabo@fedibird.com]

@silverpill @hongminhee @ozoramore @julian @liaizon @tesaguri @thisismissem When rendering a custom emoji into HTML, it is rendered as <img ... alt=":shortcode:" title="alternateName">. alt is the shortcode, and is the source text. This is so that when a user selects and copies the body of the text, the source text can be obtained from the clipboard.

[noellabo@fedibird.com]

@silverpill @hongminhee @ozoramore @julian @liaizon @tesaguri @thisismissem The same goes for mention anchor tags and URL anchor tags; even if they look like they omit the domain part, or if they clip a long URL, it is important to design them so that the source text can be obtained from the clipboard when copied.

(If you copy the body of mitra, the mention domain will be lost, and the meaning will change.)

[silverpill@mitra.social]

@liaizon @julian @hongminhee I added a text explaining this additional requirement: https://codeberg.org/silverpill/feps/src/branch/main/9098/fep-9098.md#additional-requirements

Best practices for rendering custom emojis will go into different section (WIP).

[silverpill@mitra.social]

I finally wrote the section about rendering and submitted the proposal to the FEP repository: https://codeberg.org/fediverse/fep/src/branch/main/fep/9098/fep-9098.md

@liaizon @julian @hongminhee

[liaizon@social.wake.st]

@silverpill @julian @hongminhee the thing that I tried to point out before feels like you didnt really take into consideration yet. You state "This document is based on implementations of custom emojis in Pleroma, Mastodon, Misskey and Fedibird" but Misskeys implementation has always supported long emojo and infact that type of emojo seems to be one of the most popular types in the Japanese speaking fediverse. Personally I feel this should be mentioned in the FEP

[liaizon@social.wake.st]

@silverpill @julian @hongminhee I am really glad to see you write this up regarless, don't want to come across as negative.

[julian@community.nodebb.org]

[email protected] are the long emoji horizontal or vertical?

The former is easier to support (setting just a max height), but the latter has concerns re: line height.

cc [email protected]