jdev - 2024-05-21

lovetox, larma, FWIW in slidge core I had to add some substitutions to remove/add those emoji variation selector things so that it works OK on all sides, and I am still not 100% sure of what the "correct" behaviour should be (and I don't really plan on becoming a deep unicode expert in the foreseeable future). There's still https://github.com/dino/dino/issues/1461 that slightly annoys me and I don't know if I should special-case this in my gateways. All that to say, client devs, do not hesitate to use slidge and bug report the bad things slidge does ;)

Im interested what do you need to add/remove so it works on another messenger service?

I just checked and what I ended up doing is just stripping the "emoji variation selector 16" (?) from reactions coming from XMPP, or telegram did not accept them AFAIR. Maybe some other networks required it but I'm not 100% as I mostly use telegram for "end to end devtesting" https://git.sr.ht/~nicoco/slidge/tree/master/item/slidge/util/util.py#L260

Then there's mattermost which for some reason does not use unicode but emoji aliases that are slightly different than aliases you see used elsewhere, something like "face_with_3_hearts" instead of "face_with_three_hearts", cf https://git.sr.ht/~nicoco/matteridge/tree/master/item/matteridge/util.py#L16

There are other slightly surprising things, like the heart used in telegram (which is the default heart of whatsapp, in the "short list of reactions"), which is rendered as ♥️ in the UI of both telegram and whatsapp clients, but is actually a "black heart" which both dino and gajim renders monochrome

i see you will have fun with reactions

yes gajim sends only emojis out without variant selectors (for reactions) and also strips all selectors on incoming messages

https://upload.slidge.im:5281/file_share/UxMsoIrtHfSqmiRp22iiK9y1/6eb200cd-82f9-45c0-9e2c-77b1220fc861.png

nicoco I did the same thing https://github.com/movim/movim/commit/d60ddf2f166dab1a30cc53a8f44d9b24bfcb2396

nicoco_, hmmm this seems like a bug in Gajim then, this is a text presentation, and not a emoji presentation what you see

please send me the stanza you receive here

or it is your font ..

```xml <reactions xmlns="urn:xmpp:reactions:0" id="7700742144"> <reaction>❤</reaction> </reactions> ``` This is just the emoji… erm character… erm unicode thing I receive from telegram. Interestingly whatsapp is similar in this regards.

yeah this is fine, its just a display problem in Gajim, i will fix it

Interestingly, gajim lets me send that monochrome heart to telegram by clicking on it in the UI, yet I cannot pick it in the emoji selector. If I try to send ♥️ instead of ♥ telegram is not happy. I am possibly doing some bad stuff here, I don't know.

> yeah this is fine, its just a display problem in Gajim, i will fix it oh, cool ↺

llarma: interestingly, dino renders it the same:

https://upload.slidge.im:5281/file_share/6Yc8HOqIK2-uoGhGB_JAXpY5/21321839-f90c-4d79-a686-4501930b6c21.png

nicoco, could be a font problem on your end, too.

https://uc.xmpp.zombofant.net/92aff0f3-c416-421b-a92d-a34793f9a418/foo.png

that is expected its a black heart, without emoji presentation variant selector, the font fallsback to the default presentation which is text not emoji

it would be the job of the client to add the variant selector if it things the context calls for it

the font can only guess because it does not know in which context it draws the characters

jonas’, haha that screenshot is interesting. looks like I'm spilling nonsense xD

then again, I think this is the system which will sometimes render normal digits as emoji, so who knows whose end is at fault here.

its nobodys fault you just need to know how it works

if no selector is added, the font needs to guess

different fonts, in different context will guess differently

thats why the presentation selector was invented

``` >>> import emoji >>> emoji.demojize("If I try to send ♥️ instead of ♥ telegram is not happy") 'If I try to send :heart_suit: instead of :heart_suit: telegram is not happy' ``` I would have sworn that monochrome one was called black_heart something, dammit brain

🖤 is black heart, isn't it?

hmmm yes, I got confused somewhere along the way apparently

I live confused.

it has its own wiki article

https://en.wikipedia.org/wiki/Hearts_in_Unicode

and if you checkout U+2764 in this article

you will see its called black heart, but its only black in text representation

in emoji its red

anyway, should be fixed nicoco you can try now, should be displayed correctly in Gajim

I did some more tests and I did say a few false things: If I pick ♥️ in gajim, telegram actually accepts it, so my "remove emoji variant selector whatever suffix bytes" does what it needs for telegram. and indeed, there is a gajim bug because it is monochrome, even in a "pure XMPP" context.

or a fontconfig issue

> anyway, should be fixed nicoco you can try now, should be displayed correctly in Gajim indeed! I think you forgot the tooltip, it's still monochrome in there ↺

https://upload.slidge.im:5281/file_share/43mH2LTn-Oj4nOBTLdYucdvM/Screenshot_20240521_123757.png

ah damn, fixed :)

atomic commits, all good

Hi @everyone ! I am Assurance MBULA , GSoC 2024 contributor , I will be working on the implementation of XMPP Extension Protocol 0-389 , this summer !

Hi assu_2000 - In which client will you implement this spec? FWIW, since I need multi-factor auth in the gateway components I develop, I use a dedicated adhoc command instead of XEP-0077

MattJ, for your MUX spec, please think about race condition free joins, one thing that is a ugly currently, is that many XEPs and UseCases depend on looking up disco info, but this is not possible in a race condition free manner without doing crazy things in your application. Either you request disco info before you send the join, then its outdated once your join is complete, or you request after join, then you can receive messages before the disco returns, and you need the disco to process the messages correctly.

Why does disco change after join?

It can, and thats all that is important

isnt it a bug if it changes? why would it change?

MUC Configuration is part of the MUC Disco Info

Users can change configurations at will

hence disco info changes at will

Would it help to have the caps hash part of the join response?

Hi _nicoco , I will be implementing it on prav server which is a quicksy server folk

hm, i think there are some features that are important for processing messages correctly occupant-id feature stanza-id feature i think these features need to be communicated *before* i receive a message, and maybe should be part of the join? ✏

i just think if disco is a necessary part to process messages correctly, it should part of the join flow, or at least the necessary infos should be part of it

it was definitly optional previously, but it is not an optional thing anymore for clients who want to implement recent features

but a new spec theoretically could make all those things again mandatory, so no need for disco anymore

until new features are developed