jdev - 2024-05-17

> yeah, its just easier to understand > > but for machines its harder to process Maybe for machines from the 1970s But we have webpages that take up more ram than Prosody now so that's not really a valid argument imo

> ... copy paste from xsf@ ... > Hi. A question about avatar conversion (xep-398). > What's going to happen if I publish my vcard without photo? Will it reset avatar in pubsub? > > XEP says "A service MAY support conversion from vCard to PEP in order to display avatars in clients that only support XEP-0084.". > I assume it means if two clients are connected (one publishing vcard and second one supporting just xep-84, then the second one MAY receive pubsub update). and that's all. > From other side the xep insist all the control to be done via pubsub. So it's no clear should I always add an avatar to the publishing vcard or not. rion: I am not entirely sure, but I think the current "standard" behaviour is for clients to only use XEP-0084, then servers to support XEP-0398 because that's how we have avatars in groupchats, and finally there's XEP-0292 where you're not really supposed to put a photo, although it's technically supported but since it lacks the "hash update" mechanism of XEP-0084, it's not used in practice. ↺

I mean, clients should support xep-0153 if they want to display avatars in MUCs too, but AFAIK modern clients don't use it to set avatars. A useful resource? https://docs.modernxmpp.org/client/protocol/#avatars

and thats not even half the xeps mentioned there oO

this needs cleaning up

this -> xeps

nicoco: 🙏

Is there gpl2 compatible C/C++ implementation of emoji detector/extractor in text? I mean some sort of lib capable to detect where an emoji begins for example in utf16 encoded string and where it ends. Or maybe somebody has some good implementation in mind in some other language which I can port to C++.

rion: https://unicode-org.github.io/icu/userguide/strings/regexp.html

I use this regex: (\p{Emoji}.*\p{Me})|\p{Emoji_Presentation}|\65039

on individual grapheme clusters

which libicu can also break apart for you: ICU.brkBreak $ headZ $ ICU.breaks (ICU.breakCharacter ICU.Root) string

singpolyma: does it consider zero-width-joiners, qualification and bunch of various modifiers?

For example will it match this? 1F469 1F3FB 200D 2764 FE0F 200D 1F48B 200D 1F468 1F3FC ; fully-qualified # 👩🏻‍❤️‍💋‍👨🏼 E13.1 kiss: woman, man, light skin tone, medium-light skin tone Yes, there is one single picture after "#". If somebody sees many pictures, it's because of bad unicode or fonts support. ✏

Yes. If you grapheme segment that's all handled

Fun with reactions, we just discovered that the GTK Emoji picker produces invalid emoji presentation sequences

it adds a emoji variant selector on any emoji

That's not invalid

It's just not required

im reading this differently

https://www.unicode.org/reports/tr51/proposed.html#Emoji_Implementation_Notes

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

*if the result is valid*

and its not valid

Why is it not?

Is the result not an emoji?

because emoji presentation sequence is a defind set of emojis

and this is not in there

Or text presentation sequence

https://www.unicode.org/Public/draft/UCD/ucd/emoji/emoji-variation-sequences.txt

every sequence thats not in that list is by definition not a valid emoji presentation sequence

It's somehow an emoji sequence that is neither an emoji sequence nor a text sequence?

i dont know what it is, its a combination of codepoints not defined anywhere

at least thats how i read the implementation notes

So you pick an emoji from the picker but the sequence you picked is an undefined sequence and then they add the selector to this undefined sequence?

Seems strange that an valid emoji gjyph would be an undefined sequence

no, 📯️ for example, it has no defined emoji presentation sequence

because its clear how this codepoint is to be displayed, no need to add any variation selector

hence adding to this a selector is not defined anywhere

So that's not an emoji?

depends, a font can simply render the first codepoint

and ignore the second

if you pass the whole string to a library

and ask "is this string an emoji"

it should say no

What are the two codepoints in this context?

128239 and 65039 for this example

65039 (U+FE0F) is the emoji variant selecotr

it makes sense for receivers like fonts, to not fail on this

So is 128239 a valid emoji sequence by itself or not?

thats on codepoint, and not a sequence

a sequence are multiple codepoints

yes of course the horn emoji is a valid emoji character

but adding the emoji variant selector makes it not a valid sequence

the same as you cant add a skin tone color modifier on the copyright emoji

and say thats a valid sequence

I thought the thing you quoted said emiji selector could be added to any valid text or emoji sequence?

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

this sentence?

Ah, hmm. If the result is. I see it now. Odd way to define it but i guuss this is a gtk bug then technically

Probably not one that really matters, but yeah

i just mention it here, because all people that now implement reactions, search for libs that check if something *is* an emoji

and i think this will lead to funny problems

All my emoji code says if a graphene cluster contains emoji selector then the cluster is an emoji. But I realize now I developed this testing against gajim and Dino which is probably why i saw that so often

haha bingo

I think thats still a correct thing, but yeah someone might hardcode a list or something and have problems

Though for reaction probably shouldn't care if it's an emoji orknot

yeah? you will display any string i send you?

Why not?

The hard part is deciding two emoji with and without selector are "the same" for counting. Or the two kinds of red heart etc. if one wants to do that

for one i dont design a reaction presentation bar, to contain any kind of string length

second, it creates abuse potential

as you cant moderate reactions for example

> as you cant moderate reactions for example Why not? ↺

ok technically maybe thats possible ✏

practically, building a gui for that sounds challenging, and finding support in other clients probably also

and all for what? to let people say "fuck you" in a reaction?

Well new emoji get added so hard coding a list is asking for trouble

i dont have that opinion, there are > 4000 emojis

and like 10 of them are used most of the time

So if I send a new one to an older gajim as reaction it just won't show it?

i guess so, you are right thats a downside

not convinced its a downside enough to let everything through

i mean the first gajim version with reactions will support 4000 emojis

i think its pretty safe to say that holds for many years

on that topic, will you add a fallback text to reactions?

*

Yes

and how do you reference the message which the reaction belongs to

with a quote?

Yes, quote/reply as fallback

> and how do you reference the message which the reaction belongs to You mean which id do I use? Just as per xep I think ↺

no i meant in the fallback

but you answered the question

Ah, yeah. Quote

not sure i want to do that .. :/ on one side yeah can be useful, on the other side in MUCs where many clients have reactions, this probably floods the chat with quotes and reaction text

The alternative is thrt people are replying and it's invisible to some users

yeah .. its probably the responsible thing to add the fallback text

If you don't like seeing 100 replies get a client with summary UI 😉

Hello

> and all for what? to let people say "fuck you" in a reaction? Well it's better than them replying "fuck you" :) ↺

no its not, because if they reply in a message, i can easily moderate it in many clients who support message moderation

Can't those same clients moderate reactions?

They'll even see it as a message until they implement it no? Should work out of the box

i dont plan to moderate reactions

but i also dont plan to let people write messages as reactions ✏

Why not? You can't whitelist reactions to prevent offensive ones...

not that i did plan this, but why do you think there cant be a whitelist?

i gave the reasons above, its not a easy task GUI wise to provide a UI to reatract reactions

of course its relatively easy if there is *one* reaction

hmm but probably i dont care by who, i only care about the image, so i could retract all

I'm saying it's not like blocking "bad" reactions like 🖕 can prevent inappropriate reactions, imagine someone posts: > My mom just died And someone reacts: 😁🤣🎉🥳

Yea I'd imagine you'd moderate all of that image

yeah you can always be sarcastic ..

true

... ok i guess its not that hard to do it in the gui if you retract all of one kind

i think you convinced me, to look into moderation

still dont want text as reaction

we have messages for text .. no need to abuse reactions for it

Agreed that it's not something tibspend effort trying to support

But I probably won't spend a lot of effort to prevent it either

but you provide no ui to make a text reaction or?

which client would do this? how would a text reaction even be a thing

maybe thats a good argument for not testing for emojis, because no client will offer text reactions anyway

so that leaves nerds who send custom stanzas

Exactly

still we will need somekind of emoji normalisation

because dino will send always with a emoji variant selector, and conversation maybe without

so 2 different strings, you want to count as one

yes. This is something one might want

also are ❤️ and ♥️ the same?

Or skin tones on thumbs up, count together or no?

this are different hearts with different codepoints

so no they are not the same

i dont understand your skin tone question, its a different topic

ah or you mean if you should add different skin tone variations of the same thumbs up

yeah valid question

i wouldnt to be honest

different skin tones are different emojis

the problem with the variant selectors is, they are not different emojis

you could simply strip all selectors for counting

i think i will strip them before putting them in the database

presentation selectors is just about presentation in the gui

as i already know how i want them to be presented, i can simply strip them on all incoming stuff, and this normalises it