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.
Uncategorized
43
Beiträge
9
Kommentatoren
0
Aufrufe
-
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.
The challenges are numerous:
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like
:party_blob:) as thealttext, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
#fedidev
@hongminhee I would do the same thing I do for images right now: I add a summary field on the ActivityPub object that designates the image/svg, which then gets translated into an alt text when rendered into HTML. See this as an example: https://marius.federated.id/outbox/1743586392386 (this is an ActivityPub Create for that Image that you see). If you access the object of the Create you get just the plain binary image, but so encapsulated it renders with the alt text.
-
@liaizon@social.wake.st I appreciate the enthusiasm, but I personally don't have much motivation to standardize custom emoji. While I understand many people enjoy this feature, I'm not particularly fond of custom emoji functionality in general. My limited interest in the feature itself, combined with the significant accessibility issues it creates, makes it difficult for me to get excited about investing time in standardization efforts. Though I respect that others might feel differently!
@hongminhee @liaizon I've never really got to the point to add custom emojis for my projects, but I think they as a concept work really well on top of ActivityPub in the form of "Like" activities which have a URL (or even maybe a binary Content directly) to the actual emoji image, but also support alternate text as I described in my sibling message.
-
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.
The challenges are numerous:
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like
:party_blob:) as thealttext, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
#fedidev
@hongminhee I plan to write a FEP documenting existing implementations (it is needed to finalize my emoji reactions FEP).
>Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users
Do you know implementations that provide alt text for custom emojis?
-
@hongminhee I know there's a FEP for emoji reactions, but I don't think there's ever been one for custom emojis? https://codeberg.org/fediverse/fep/src/branch/main/fep/c0e0/fep-c0e0.md
@thisismissem@hachyderm.io You're right, I don't believe there's a specific FEP for custom emojis yet. If one were to be created, accessibility through proper
alttext would definitely need to be a core requirement. The current state where emoji codes like:blob_wave:become the alt text creates significant barriers for screen reader users—especially for non-English speakers, who face an additional language barrier when trying to understand these codes. A proper standard should address how to provide meaningful descriptions that actually convey what the emoji represents in multiple languages. -
@hongminhee I plan to write a FEP documenting existing implementations (it is needed to finalize my emoji reactions FEP).
>Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users
Do you know implementations that provide alt text for custom emojis?
silverpill@mitra.social I personally didn't find integrating custom emoji to be difficult at all.
However NodeBB did already have custom emoji support (so it was fairly straightforward to add the outbound federation support), and as for inbound, the short code is defined in the payload and a simple regex replace handles it ok.
Sure, some emoji might look weird if they have different aspect ratios, but that's something outside the scope of what I'd want. All remote emoji are reduced down to a small square (or technically I think it's maybe max width and height of 1rem or similar), inline with the text and that honestly works with like 99% of the emoji I see.
-
silverpill@mitra.social I personally didn't find integrating custom emoji to be difficult at all.
However NodeBB did already have custom emoji support (so it was fairly straightforward to add the outbound federation support), and as for inbound, the short code is defined in the payload and a simple regex replace handles it ok.
Sure, some emoji might look weird if they have different aspect ratios, but that's something outside the scope of what I'd want. All remote emoji are reduced down to a small square (or technically I think it's maybe max width and height of 1rem or similar), inline with the text and that honestly works with like 99% of the emoji I see.
That said an FEP would be nice so I'd be able to verify that my implementation checks all the boxes.
-
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.
The challenges are numerous:
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like
:party_blob:) as thealttext, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
#fedidev
Another annoying thing about the current custom emoji spec in the fediverse: the type is just called
Emojiinstead ofCustomEmoji. Such a small detail, but it creates unnecessary ambiguity between Unicode emojis and custom ones. I ran into this while implementing BotKit and had type name collisions withEmoji—had to use awkward namespacing to work around it. These little inconsistencies make implementation more tedious than it needs to be. -
That said an FEP would be nice so I'd be able to verify that my implementation checks all the boxes.
Started writing it
Listed requirements for the
Emojiobject.
I should probably describe the microsynax there as well, and how custom emojis are rendered. -
Another annoying thing about the current custom emoji spec in the fediverse: the type is just called
Emojiinstead ofCustomEmoji. Such a small detail, but it creates unnecessary ambiguity between Unicode emojis and custom ones. I ran into this while implementing BotKit and had type name collisions withEmoji—had to use awkward namespacing to work around it. These little inconsistencies make implementation more tedious than it needs to be.@hongminhee Why there are collisions? Do you generate
Emojiobjects for unicode emojis too? -
Started writing it
Listed requirements for the
Emojiobject.
I should probably describe the microsynax there as well, and how custom emojis are rendered.@silverpill @julian @hongminhee you have listed "Image is a square" but is definitely not true for Misskey. And Mastodon renders Misskeys long emojos just fine.
Actually mastodon does fine with long emojos now too
-
@silverpill @julian @hongminhee you have listed "Image is a square" but is definitely not true for Misskey. And Mastodon renders Misskeys long emojos just fine.
Actually mastodon does fine with long emojos now tooliaizon@social.wake.st oh fun, NodeBB handles the long emoji fine as well.
I can't wait for this to be abused
-
@silverpill @julian @hongminhee you have listed "Image is a square" but is definitely not true for Misskey. And Mastodon renders Misskeys long emojos just fine.
Actually mastodon does fine with long emojos now tooRequirements in that section are meant for those who want maximum compatibility. For example, JPEGs and images larger than 256 KB are supported by Pleroma and others, but Mastodon doesn't allow them.
Non-square emojis are a bit more complicated. They are not rejected by most servers, but might not be displayed properly by clients.
I just visited your instance and made a screenshot of how emoji is rendered by web UI (attached). The emoji is present, but I can't tell what is depicted there. Some clients enlarge custom emojis on hover, but not Mastodon, so I have to open the image in a new browser tab, or zoom in the page. This is no ideal, hence the recommendation in the FEP.
-
@thisismissem@hachyderm.io You're right, I don't believe there's a specific FEP for custom emojis yet. If one were to be created, accessibility through proper
alttext would definitely need to be a core requirement. The current state where emoji codes like:blob_wave:become the alt text creates significant barriers for screen reader users—especially for non-English speakers, who face an additional language barrier when trying to understand these codes. A proper standard should address how to provide meaningful descriptions that actually convey what the emoji represents in multiple languages.I think we can use
summaryproperty onEmojiobject. It's one of those properties for which the spec allows multi-language mappings: -
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.
The challenges are numerous:
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like
:party_blob:) as thealttext, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
#fedidev
@hongminhee
Fedibird seems to have a feature that lets you see details about emojis, which may also contribute to accessibility.
https://fedibird.com/@noellabo/113876564190790916 -
I think we can use
summaryproperty onEmojiobject. It's one of those properties for which the spec allows multi-language mappings:@silverpill @hongminhee @thisismissem
`summary` could represent *some* kind of accessible information, but it's not obvious to me which kind exactly: should it be an accessible name (<https://developer.mozilla.org/en-US/docs/Glossary/Accessible_name>) or an accessible description (<https://developer.mozilla.org/en-US/docs/Glossary/Accessible_description>)? (Or even an HTML `title` attribute?)
(I think it's unfortunate that we need to reinvent an accessibility tree representation, when an AS2 `content` is just an HTML, which has already been equipped with a feature-rich and battle-tested accessibility framework called ARIA, but I digress.)
-
@silverpill @hongminhee @thisismissem
`summary` could represent *some* kind of accessible information, but it's not obvious to me which kind exactly: should it be an accessible name (<https://developer.mozilla.org/en-US/docs/Glossary/Accessible_name>) or an accessible description (<https://developer.mozilla.org/en-US/docs/Glossary/Accessible_description>)? (Or even an HTML `title` attribute?)
(I think it's unfortunate that we need to reinvent an accessibility tree representation, when an AS2 `content` is just an HTML, which has already been equipped with a feature-rich and battle-tested accessibility framework called ARIA, but I digress.)
@tesaguri @silverpill @hongminhee wouldn't it just be the alt text?
-
Requirements in that section are meant for those who want maximum compatibility. For example, JPEGs and images larger than 256 KB are supported by Pleroma and others, but Mastodon doesn't allow them.
Non-square emojis are a bit more complicated. They are not rejected by most servers, but might not be displayed properly by clients.
I just visited your instance and made a screenshot of how emoji is rendered by web UI (attached). The emoji is present, but I can't tell what is depicted there. Some clients enlarge custom emojis on hover, but not Mastodon, so I have to open the image in a new browser tab, or zoom in the page. This is no ideal, hence the recommendation in the FEP.
@silverpill @julian @hongminhee ugh mastodon android squishes this. These are both Mastodon bugs as far as I am concerned. I think as long as you specify what you are making maximum compatibility with that seems OK but long emojos are INCREDIBLY popular on all the misskey and misskey adjacent fediverse areas. So I would argue that usage should be spelled out in the FEP as well.
-
@hongminhee
Fedibird seems to have a feature that lets you see details about emojis, which may also contribute to accessibility.
https://fedibird.com/@noellabo/113876564190790916@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_jaFedibirdのcustom_emojis APIのエンティティ
https://fedibird.com/api/v1/custom_emojis/prohibits_importing_to_other_servers_ja -
@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_jaFedibirdのcustom_emojis APIのエンティティ
https://fedibird.com/api/v1/custom_emojis/prohibits_importing_to_other_servers_ja@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.
-
@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.
@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.
