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.
-
wrote for 21 dage siden sidst redigeret af
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
-
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
wrote for 21 dage siden sidst redigeret af@hongminhee let's make a new standard for adding metadata to emojos! I think there is enough motivation around this feature to get the various implementors to add new stuff to it!
-
@hongminhee let's make a new standard for adding metadata to emojos! I think there is enough motivation around this feature to get the various implementors to add new stuff to it!
wrote for 21 dage siden sidst redigeret af@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!
-
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
wrote for 21 dage siden sidst redigeret af@hongminhee sounds like there needs to be a better FEP written, one which encourages alt text for custom emojis?
-
@hongminhee sounds like there needs to be a better FEP written, one which encourages alt text for custom emojis?
wrote for 21 dage siden sidst redigeret af@thisismissem@hachyderm.io Yeah, if it’s standardized al text should be considered…
-
@thisismissem@hachyderm.io Yeah, if it’s standardized al text should be considered…
wrote for 21 dage siden sidst redigeret af@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
-
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
wrote for 21 dage siden sidst redigeret af@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!
wrote for 21 dage siden sidst redigeret af@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
wrote for 20 dage siden sidst redigeret af@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 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?
wrote for 20 dage siden sidst redigeret af@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.
wrote for 20 dage siden sidst redigeret afThat said an FEP would be nice so I’d be able to verify that my implementation checks all the boxes.
-
wrote for 20 dage siden sidst redigeret af
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. -
wrote for 19 dage siden sidst redigeret af
Started writing it
https://codeberg.org/silverpill/feps/src/branch/main/9098/fep-9098.md
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.wrote for 19 dage siden sidst redigeret af@hongminhee Why there are collisions? Do you generate
Emojiobjects for unicode emojis too? -
Started writing it
https://codeberg.org/silverpill/feps/src/branch/main/9098/fep-9098.md
Listed requirements for the
Emojiobject.
I should probably describe the microsynax there as well, and how custom emojis are rendered.wrote for 18 dage siden sidst redigeret af@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 toowrote for 18 dage siden sidst redigeret af@liaizon@social.wake.st oh fun, NodeBB handles the long emoji fine as well.
I can’t wait for this to be abused
