jdev - 2024-05-20

  1. lovetox

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

  2. larma

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

  3. larma

    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.

  4. lovetox

    you mean because the chat gets spammed with quotes?

  5. lovetox

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

  6. larma

    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

  7. larma

    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

  8. larma

    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

  9. larma

    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.

  10. larma

    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).

  11. lovetox

    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.

  12. lovetox

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

  13. larma

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

  14. lovetox

    yes they are

  15. lovetox

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

  16. lovetox

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

  17. lovetox

    you can receive a emoji in 3 different versions

  18. lovetox

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

  19. larma

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

  20. lovetox

    yeah so? we want to count emojis or?

  21. larma

    You can even have multiple variant selectors after each other, the last one is the one that counts

  22. larma

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

  23. lovetox

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

  24. larma

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

  25. lovetox

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

  26. lovetox

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

  27. larma

    > 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).

  28. larma

    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

  29. larma

    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"

  30. larma

    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

  31. pulkomandy

    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

  32. pulkomandy

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

  33. lovetox

    > 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.

  34. lovetox

    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

  35. lovetox

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

  36. lovetox

    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.

  37. lovetox

    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

  38. lovetox

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

  39. lovetox

    and such libraries are correct if they reject invalid emoji presentation sequences as invalid

  40. lovetox

    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.

  41. lovetox

    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.

  42. singpolyma

    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

  43. rion

    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

  44. lovetox

    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.

  45. soulcaramel

    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

  46. Hydrogen

    ask in the siskin room