jdev - 2024-05-20

larma, was there a specific reason why you didnt include a fallback with reactions?

Yes, if you do fallback for reactions it sucks so hardly for fallback users that it hinders adoption.

Imagine in a public room, you have a message with 5 thumbs up and 3 thumbs down, that would be 9 messages for the fallback.

you mean because the chat gets spammed with quotes?

yeah i thought the same .. it could lead to making it very annoying for legacy users

If users care about the UX of fallback users (and that's what fallback is all about) they wouldn't do reactions, but just normal messages, if reactions had fallback ✏

Fallback could be reasonable in direct chats, as you know there will only be very few reactions per message and it is more important that the other side does see the reaction

We didn't mention anything about fallbacks explicitly in the XEP, but that's because at the time we wanted to be open for experiments.

We should probably add some rules though (especially that if a fallback body is present it should be ignored and a <fallback> should be added).

larma, just fyi, i opened a bug request with GTK because they generate invalid sequences in the emoji picker. They fixed it promptly in GTK4. https://gitlab.gnome.org/GNOME/gtk/-/issues/6714 But as we merge Gajims reaction soon, we opted to send only emojis without any selectors, because from the context its clear how they should be displayed, also on incoming we strip all presentation variant selectors to prevent different emoji pickers on different platforms do different things.

but i feel there should be some recommendation in the XEP around that

I don't think unnecessary variant selectors are strictly speaking illegal in Unicode

yes they are

as you can read in the links to the implementation notes in that ticket

but thats beside the point, if you work under the assumption that its not illegal, you have the same problem

you can receive a emoji in 3 different versions

telling an implementor that this can/will happen, and a recommendation for some kind of normalization, would be good

When I looked it up it was legal Unicode, but not necessarily a legal emoji

yeah so? we want to count emojis or?

You can even have multiple variant selectors after each other, if they're conflicting, the last one is the one that counts ✏

not sure what you are getting at, you can add all kind of codepoints in a sequence, but how is that relevant

The XEP is (currently) intentionally vague with all this because the Unicode standard is a moving target

i guess it has nothing to do with the protocol how you count emojis

maybe it should not be in the XEP, i guess implementors will learn it once they do the GUI for it

> A <reaction> element SHOULD only contain Unicode codepoints that can be displayed as a single emoji, as specified in the latest revision of the Unicode® Technical Standard #51 I think this covers well the intent. And it also means that unnecessary variant selectors are indeed valid under the XEP because they're valid Unicode and don't hinder display as a single emoji (as they still create a Unicode grapheme cluster that is equivalent to a valid TR#51 emoji).

Adding something about normalization in the part where we say that they may be displayed summarized and the part where we say that each reaction may only appear once still makes sense though

Not strictly normalization (because that's probably not well defined for this use case) but something along the lines of "things that are displayed the same even if it had different Unicode codepoints"

On Slack you can only do one thumbs up no matter which skin color modifier you use. We might want to allow clients to do something similar

In mattermost the skin colors are not merged. Usually it doesn't matter, someone will do the first reaction with whichever skin color they have configured and other people will click on the existing reaction to add other thumbs up

But if you really want, you can add a different thumb up in another skin color

> unnecessary variant selectors are indeed valid i think you are mistaken, unnecessary variant selectors are not valid emoji sequences, as all valid sequences are specifically mentioned and listed by the unicode standard, which make any sequence that is not in that in that list, undefined or invalid.

emoji character is defined as > emoji character may have an emoji or text presentation selector added *if the result is a valid emoji presentation sequence* or text presentation sequence

emoji presentation sequence is also defined and points to a list with defined sequences.

if your argument is, but a font may ignore unnecessary variant selectors added and not display them, then i would argue, its unreasonable to make clients test an incoming reaction with the current active font and somehow find out if this font displays what ever was sent as single emoji.

its much more simple to define a emoji character exactly as it is defined in the unicode standard, and not make it dependent on the display (font) layer

implementors will use regex or dedicated emoji libraries to find out if a emoji is a single emoji character and a valid one

and such libraries are correct if they reject invalid emoji presentation sequences as invalid, or more specifically, not an emoji character as per standard defined. ✏

but if we stay at that definition "what can be displayed as a single emoji" then a cleaning algorithm is even more important, there is no way to know what codepoints a font would ignore after a emoji character, could be many. Further it makes what is valid or not dependent on the current active font of the user.

This all assumes a very specific UI around summaries which is only one possible UI anyway. So I agree doing some cleaning is sane if one has such a UI but I don't think the xep needs to care about it

Maybe removing any qualification before counting and restricting possible modifiers is a good way to go. Wrt rendering it's up the up what feels to be the best

MattJ, did you think about putting Hats into messages at least for MAM messages? I really want to provide this feature in a consistent way, for me having a hat in a roster, is ok but it would be much more useful if i could consistently display it on the message. im not even mentioning use cases like not broadcasting presence, which would simply be incompatible. The answer to this question is blocking our implementation, because it needs different database considerations.

Anyone know why in Siskin iOS my “Settings” in the top left might have a “1” count that is perpetually there? I’ve gone through all the menu options in there but don’t see what is “unread” or needs attention

ask in the siskin room