I think replacing ID with an image hash (using digestMultibase or digestSRI properties) might work well for custom emojis, but this should be the subject of a different FEP.
Currently id seems to be the de-facto standard for identifying emojis.
Considering some degree of compatibility with existing implementations seems to be a goal, Iāll leave this link to Akkoma docs here: AP extensions#emoji-reactions
The examples already answer questions which came up here about reacting with remote emoji and null ids. Note that both shortcodes with and without enclosing colons are supported and internally normalised to the same form (at least in modern versions) and itās imho probably fine to only require one (either one) in the FEP (as far as Akkoma is concerned at least)
null ids may come about for example from custom, user-selected images; emoji arenāt necessarily limited to a server-admin approved set. Or in implementations allowing remote emoji reacts but not tracking/remembering the original remote emoji id (e.g. iceshrimp.net and Akkoma, with the latter currently setting a bogus ID instead but a change to null is planned)
On the matter of merging āidenticalā emoji counters, i believe itās practically impossible to fully achieve and not worth worrying too much about.
Even a bit-identical image may produce a different file hash due to image format or just metadata differences. A visually identical image may also not be bit-identical due to compression settings differing. Merging by id if not null, otherwise image URL and shortcode(+domain?) seems good enough
I really like this - only thing I want to point out is this:
A single user is allowed to react multiple times with different emoji to the same post. However, they may only react at most once with the same emoji. Repeated reaction from the same user with the same emoji are to be ignored.
Akkoma is of course free to ignore additional reactions with the same emoji, but I feel this should be implementation-specific and not part of the extension specification, so to speak. Just like ActivityPub does not say that multiple Likes on the same thing are not allowed, even if most implementations ignore multiple Likes. You could imagine an implementation wanting to receive all reactions, even duplicate ones, for some reason. Just a small nitpick but otherwise I basically agree with the stated extension.
Thank you, these docs are very helpful. I made several changes to the FEP based on that info: #404 - FEP-c0e0: Update proposal - fediverse/fep - Codeberg.org
I think shortcode in content should be enclosed in colons, that would be consistent with the usage of shortcodes in Note objects. I added this requirement to the FEP.
This FEP doesnāt specify how Emoji object should be structured, and links to Mastodon documentation instead. However, I should say that removing id is a breaking change, and I donāt recommend doing that without coordinating it with other implementers.
The shortcode MUST be enclosed in colons.
this feels too restrictive. using colon wrapping is a convention, not a requirement. itās like saying āMentions MUST begin with an @ā (not a valid assumption, hubzilla et al donāt include the @).
iād change this to instead clarify that the content MUST exactly match the Emoji.name (because thatās whatās really going on at a microsyntax level)
Good point. But Pleroma/Akkoma put unenclosed shortcode in Emoji.name, so such requirement would be incompatible with one of the leading implementations (I donāt have an example of Misskey activity at hand).
This feels like something Pleroma/Akkoma should fix, because parsing microsyntax shouldnāt be required, and should be the same regardless of the type of tag (take ānameā and replace it with the rich entity). Some other implementation might use colon wrapping for something else entirely.
To my knowledge, all existing implementations put colons in content. Youāre right, it is a convention, but in this FEP Iām trying to codify existing conventions, so The shortcode MUST be enclosed in colons requirement seems appropriate. That will make implementerās job easier.
Iāve changed the other requirement to Emoji.name SHOULD match the content: FEP-c0e0: Clarify Emoji.name validation rules Ā· 3343d583c6 - fediverse/fep - Codeberg.org. A bit more strict, but still compatible with Pleroma and Akkoma.
Iām interesting in seeing this become a reality because of how my children communicate (one of themās first language is emoji). Is there anything I can help?
This depends on what you mean by āseeing this become a realityā. Software families such as Misskey and Pleroma already have support for emoji reactions and there are efforts to port over the functionality to glitch-soc as well.
If you have your own AP implementation you can just implement the FEP and start federating them immediately. If you donāt there isnāt much you can do beyond hoping your implementation chooses to support them.
Most in terms of FED-a4edās process:
After at least 60 days the authors may request the proposal to be finalized. This is done by requesting final comments on the proposal. If there are no community objections within 14 days and the authors can show that they have initiated sufficient awareness and discussion of the proposal, a facilitator will set the status of the submission to FINAL.
If after 1 year the authors have not requested the proposal to be finalized, a facilitator should inquire about the status of the proposal. If authors donāt respond, a facilitator will set the status of the submission to
WITHDRAWN.
Since my family (in specific, me and my youngest son) and circle of friends use emoji responses heavily for communication, Iād like to not see this one WITHDRAWN. Also, Iām guessing it would also be hard to get buy-in from say GoToSocial (my preferred instance right now) without having something finalized. At least, that is the impression I got last year when I mentioned it but sadly my old instance is being shut down and I canāt find a link to that post.
Soā¦ I want to help. 
Donāt worry, this FEP is not abandoned and will not be withdrawn
At least 4 projects signaled support for this FEP after it was published. Iāve added this information to the āImplementationsā section: #518 - FEP-c0e0: Implementations - fediverse/fep - Codeberg.org.
I think we can start thinking about finalizing it, but the big missing piece is a good specification for custom emojis. Currently we are referring to Mastodon documentation, which is not very helpful. Ideally it should be a FEP too.
Another thing that is missing is security considerations for reactions with remote emojis. For example, IceshrimpNET developers describe additional requirements in their FEDERATION.md:
Remote custom emoji reactions are supported if two conditions are met:
- The
as:contentproperty is set to:emoji@remoteinstance.tld:oremoji@remoteinstance.tld- The emoji
emojiis already known from a post or reaction by a user onremoteinstance.tld
Something like this should probably be added to the FEP.
Should security be part of this FEP or would the individual instances have their own rules. I would suspect they would want to treat it like they treat emoji normally, much like if someone was just to respond to with ā
ā or a short code by itself. (Would that be a āRECOMMEND to use the same security for emoji asā¦ā?)
I do agree, it would be nice of emojis were more documented instead of āwhatever Mastodon doesā.
EmojiReact activity contains an embedded Emoji object. When embedded emoji has different origin than activity, we may want to verify the emoji. The question is, do we really want that, and if so, how?
Normally, verification of an embedded object is done by retrieving it by its id, but some implementations donāt publish Emoji documents, and some donāt even add id property to their emojis.