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.