Gajim - 2025-09-28

lovetox pushed 1 commits to branch gajim/master cfix: Use fast method to delete all history for a contact - https://dev.gajim.org/gajim/gajim/-/commit/0450f87460aa49a495dd0fba9423c7499a0b5d2e

lovetox pushed 1 commits to branch gajim/master cfix: Add more test for data deletion and fix deletion order - https://dev.gajim.org/gajim/gajim/-/commit/1fd46efaa6823d13a70fd1bc14e17e2ca752c59f

lovetox pushed 1 commits to branch gajim/master ci: Tests: Shutdown database correctly to silence warnings - https://dev.gajim.org/gajim/gajim/-/commit/cf2e365a557161648772cd54340b05dcd985909b

> I didn't fix anything About this issue: > lovetox: did you fix the issue with d&d pictures or did it fix itself because the latest gnome update changed something? I made an observation that if i d&d a picture open in firefox it works, if i try to d&d it when it is embedded in the page it doesn't. ↺

10:45 in germany, lovetox pushed commits and has now a breakfasty :)

Is Gajim available on android?

I need some help here, Im building an app that uses xmpp in qt, so I use QXmpp, my app was working fine, on armeabi-v7a, I mean android, and desktop before I had the qxmpp in it. Now, it doesnt work. I installed qxmpp through dnf for m fedora pc. But apparently if I want it for an android app, I need to build it for android? I need to know, how to make qxmpp work for android. ✏

I need some help here, Im building an app that uses xmpp in qt, so I use QXmpp. My app was working fine, on armeabi-v7a, I mean android, and desktop before I had the qxmpp in it. Now, it doesnt work. I installed qxmpp through dnf for m fedora pc. But apparently if I want it for an android app, I need to build it for android? I need to know, how to make qxmpp work for android. ✏

I need some help here, Im building an app that uses xmpp in qt, so I use QXmpp. My app was working fine, on armeabi-v7a, I mean android and alsdesktop before I had the qxmpp in it. Now, it doesnt work. I installed qxmpp through dnf for m fedora pc. But apparently if I want it for an android app, I need to build it for android? I need to know, how to make qxmpp work for android. ✏

I need some help here, Im building an app that uses xmpp in qt, so I use QXmpp. My app was working fine, on armeabi-v7a, I mean android and also desktop before I had the qxmpp in it. Now, it doesnt work. I installed qxmpp through dnf for m fedora pc. But apparently if I want it for an android app, I need to build it for android? I need to know, how to make qxmpp work for android. ✏

I need some help here, Im building an app that uses xmpp in qt, so I use QXmpp. My app was working fine, on armeabi-v7a, I mean android and also desktop before I had the qxmpp in it. Now, it doesnt work for android. I installed qxmpp through dnf for m fedora pc. But apparently if I want it for an android app, I need to build it for android? I need to know, how to make qxmpp work for android. ✏

I need some help here, Im building an app that uses xmpp in qt, so I use QXmpp. My app was working fine, on armeabi-v7a, I mean android and also desktop before I had the qxmpp in it. Now, it doesnt work for android. I installed qxmpp through dnf for my fedora pc. But apparently if I want it for an android app, I need to build it for android? I need to know, how to make qxmpp work for android. ✏

Mad Maestro: Can you cross compile qxmpp? GCC and binutils have ARM and Android targets.

I need to clone the repo, and cross compile, and add the path in CMAKE_MODULE_PATH?

Mad Maestro, xmpp:programming@chat.cluxia.eu?join is probably a more appropriate MUC.

I came here, because gajim uses qxmpp

I have not cross compiled anything for a couple of years, and then, it was only FreeBSD to MinGW-w64

Mad Maestro, Gajim does not use qxmpp, Kaidan does.

Okay, do u have the kaidan invite

No

I have no idea if Kaidan has a MUC

Surely, you would prefer a QXMPP MUC?

Anyways, you need a cross compiler toolchain for your host, and target, or you need to build one.

Yeah

> Mad Maestro, xmpp:programming@chat.cluxia.eu?join is probably a more appropriate MUC. is this qxmpp MUC? ↺

No.

Do you have the address of the qxmpp MUC?

Mad Maestro, what XMPP client are you using now?

Im using DIno

Oh the worst.

Mad Maestro, try this xmpp:qxmpp@muc.kaidan.im?join

> Oh the worst. what do u use? ↺

Conversations on Android, and Gajim on FreeBSD.

> Mad Maestro, try this xmpp:qxmpp@muc.kaidan.im?join didnt work ↺

The invite above works fine for me.

lovetox pushed 1 commits to branch gajim/master imprv: DebugConsole: Disable Stream Management by default - https://dev.gajim.org/gajim/gajim/-/commit/66bd414897b421631e9e4b3cad3f4572cadebb23

lovetox, apologies if this feels pushy, I am just not sure you noticed it: I updated the "unnamed private group" MR and the "displayed markers in MUC" one which have been opened for a long time, and about which we discussed a lot. I think all concerns were adressed. Since we recently exchanged a few messages on some newer ones, I want to say that ideally I would be really happy to actually close these ones first. I have been using them for a long time. It's usually trivial to rebase them on top of master, but I dread the potential commit(s) you push one day that will actually make rebasing a lot more painful. :-)

why is this gajim-git lag and consumes alot of cpu its taking 40.9% of my cpu

i am on arch linux

colinR: when does it do it? can you profile it?

``` [collins@archie ~/.local/bin]$ ps -p 358319 -o %cpu,%mem,comm %CPU %MEM COMMAND 27.5 7.1 gajim ```

as you can see there its now using 27.5 of my cpu and 7.1 memory

You might look into or share the profile file generated with: `python -m cProfile -o gajim.prof path/to/gajim/launch.py`

you'd start Gajim with this command, let it run for a short while, when the CPU usage is high and then quit it.

it has created a file

Great, you can visualize it eg with Snakeviz.

where do i get snakeviz

i dont know because the file is protected its like some sort of encryptation

you can install snakeviz via pip

https://jiffyclub.github.io/snakeviz/ you can also share the report, it doesn't contain any private data. ✏

or you use this little script: https://stackoverflow.com/a/53978443 to generate a static text file as an output, containing the profile stats

just replace profilingResults.cprof with gajim.prof

nicoco, yes thouse MRs are on the top of my list

regarding reactions, i dont understand you answer really, the disco info was made "entity specific" what do you mean by that

even the feature keys are named in a way that they make not much sense on a user disco info

"max_reactions_per_user"

this is text i would expect returned by a service

a MUC or a gateway service

if i receive that, then i know this service hat this feature or limitation

why would i need to query every user i encounter?

, output_path: Path, decompress: bool):

haha well I tried to give some context but I made it all confusing oops

so, in the current slidge (=only) implementation this reaction restriction dataform is in the disco#info of: - the MUCs - the "slidge" resource of 1:1 contact (a pseudo-client) It is not in the disco#info the gateway component itself, but I could add it.

> a MUC or a gateway service The intent of llarma was to not make these restrictions "service-wise" (which was my initial idea), but per-MUC. It could be something configurable by room owners, in the muc config dataform (even if there is no implementation so far). ↺

> why would i need to query every user i encounter? Since the spec does not define any "service-wise restrictions", for 1:1 chats it has to be something contact-specific. The disco#info of the "slidge" pseudo-client was the best fit I managed to come up with. Without caps, that would mean needing to disco#info query every contact; but since we have caps, one query to resolve the caps verstring to a disco#info — including the emoji:restrictions dataform — should be enough. I agree that it's not great to rely on the contact being available; in practice, in slidge, when contacts are offline it means the gateway is down and nothing can be routed to them anyway, but that is somehow slidge-specific. ↺

Anyway, what if gajim relied on: - the disco#info of MUCs; - the disco#info of the component for 1:1 contacts. Does that sound good to you?

contact-specific or client-specific ? Very different

For real xmpp things, yes. For gateways (at least slidge ones), it's exactly the same. The reason there is a pseudo-client is to "behave as much as possible like any other XMPP contact", but really, it's the same.

nicoco, there is no real and unreal xmpp, the purpose of a gateway is that you behave like xmpp to clients, and clients dont need to care

> Since the spec does not define any "service-wise restrictions", for 1:1 chats it has to be something contact-specific.

the spec says any entity can limit reactions by advertising it in their disco info

a MUC is an entity, a MUC service is an entity, a gateway is an entity

does the user limit reactions in this scenario? no. Its the gateway service that limits reactions, so it should advertise it

If someone decides to implement an option for a MUC Admin to limit reaction, then the MUC entity needs to advertise it

there could still be another limit on the MUC component for example

an entity is responsible for something, and its their job to advertise it. If a user uses a client that only supports one reaction, the client needs to advertise this for its specific assigned resource

so i think its sensible for now to only support usecases that are currently in the wild, or very likely could be soon.

Which means your slidge usecase, which is the gateway itself who imposes that limit

i have a problem with gajim when i press add file button my file manager doesnt appear in short its not pressable what might be the issue

> i have a problem with gajim when i press add file button my file manager doesnt appear in short its not pressable what might be the issue ru using flatpak i had that the other day after i updated gajim but restarting my pc fixed it ↺

i am not using flatpak edition i am using the git version of it gajim-git installed from paru

> i am not using flatpak edition i am using the git version of it gajim-git installed from paru why ↺

because i honestly use latest git build i dont like flatpak

so how do i get this problem fixed sunglocto

isn't gajim in the regular arch extra repository?

it is there but its not stable as it was so much heavier and lag

you probably need to install some portal

so gajim can access the file dialog

which portal

good evening lovetox

xdg-desktop-portal xdg-desktop-portal-kde xdg-desktop-portal-gtk xdg-desktop-portal-gnome

one of these, depending on your system

i have them installed even before

but i can't access it either lovetox

is the button not pressable (disabled) or can you press it and nothing shows up?

its not clear from your message

> nicoco, there is no real and unreal xmpp, the purpose of a gateway is that you behave like xmpp to clients, and clients dont need to care This is precisely the spirit of everything I said? The only time I mentioned "real xmpp" was in reply to moparisthebest, that the contact-/client-specific distinction, in the context of (most, if not all) gateways, was not as straightforward as it is in the non-gateway context. ↺

i can press it and nothing shows up? ✏

> does the user limit reactions in this scenario? no. Its the gateway service that limits reactions, so it should advertise it Fine. As I said, this is what I wanted to do, but llarma thought it was a bad idea, and he's the XEP author. ↺

> a MUC is an entity, a MUC service is an entity, a gateway is an entity You can send chat messages with any entity, and unless specified, there is no automatic inheritance rule from your domain; e.g., my server does not advertise OMEMO support, but my clients do. As a general rule, we do a lot of things that the service does not have special support for, eg, muji (XEP-0272) works with any MUC service. XEP-0444, as it is written right now, says nothing about inheritance from the "bare domain" entity. So, if you read it as it is right now, if "something.example.com" has "allowlist={ 💩 }" it means that, if you implement XEP-0444 v0.2, you are not supposed to react with anything else than 💩 when you chat with xmpp:something.example.com — and the spec nothing says nothing about what it means for xmpp:someuser@something.example.com or xmpp:somegroup@something.example.com ↺

> If someone decides to implement an option for a MUC Admin to limit reaction, then the MUC entity needs to advertise it The MUC entity, meaning the room? Yes, I agree. Did you mean the MUC service, aka the "MUC component"? In this case I disagree, the spec says nothing about that. Maybe it should? It is experimental and easy to change (modulo convincing llarma that changes are worthwhile), so this is open for discussion. ↺

colinR: which DE or WM do you use? Glib uses dbus to request the file picker dialog. So you click on the attachement button, an overlay opens, where you click on "add file"?

My proposal in the MR thread BTW, was precisely to be able to explicitly define an inheritance rule for all entities on a domain, the "domain-wide" restictions. It could be on the disco#info of something.example.com with the dataform we have, but I think it is cleaner if we add an explicit field meaning "these restriction are applied to all entities in this domain", eg, a "scope" field with a value of "domain-wide".

Just so we're clear, I really have no strong opinion about how it should be. I just know that I implement bridges to some networks where the emoji list is a subset of all emojis, and/or only a single reaction per user per message is possible. My discussions with llarma turned my suggestion of "gateway advertises the restrictions on reactions and these apply to all JIDs @gateway" to something that is not gateway-specific at all, and could be configurable on a per MUC basis, or even something that clients could advertise (although it is a bit weird, why not? maybe I don't want anyone to react with 🇫🇷 when they chat with me because I hate baguettes or something)

> colinR: which DE or WM do you use? Glib uses dbus to request the file picker dialog. So you click on the attachement button, an overlay opens, where you click on "add file"? I am using dwm ↺

nicoco, larma said specifically the gateway should not advertise any reaction limits?

nicoco, lovetox: does it make sense for that to be disco vs the entity to respond with an error when they get one they don't like?

AFAIR (this was a while ago now), he said if the gateway advertises reaction limits, it means these limits apply to chatting with the gateway (which is not a human, but you can send chat messages to it nevertheless) ✏

thats a very weird thing to say

why?

especially with regard to limits, I mean in that case it's a race, you don't know if you can react or not? You gotta send and handle an error anyway no?

so if i query a domain.com and it advertises a stanza-limit of 10kb, this means it applies to message i send to domain.com, but not user@domain.ocm

> especially with regard to limits, I mean in that case it's a race, you don't know if you can react or not? You gotta send and handle an error anyway no? slidge sends error messages in reply to reaction it does not accept ↺

in MUCs it's easy, slidge never "echoes" the bogus reaction

in 1:1 though, AFAIK all clients just drop that error message because it is not attached to a message with a body and they don't have any UI to display them (well, psi displays all errors I think)

> so if i query a domain.com and it advertises a stanza-limit of 10kb, this means it applies to message i send to domain.com, but not user@domain.ocm Doesn't the XEP explicitly say "the stanza-limit applies to all JIDs @domain"? ↺

let me word it a different way, a client sees a remote entity can only accept 1 reaction, what's it supposed to do with this info?

moparisthebest, send only one reaction, ...

if there is currently 0 reactions it can send 1... but what if one was already sent from elsewhere?

its one reaction per user

not one reaction all together

and your user has how many clients connected?

> especially with regard to limits, I mean in that case it's a race, you don't know if you can react or not? You gotta send and handle an error anyway no? errors are implemented, for the full story if slidge is a "privileged entity" it will even impersonate you to "sync the XMPP reaction state with the bridged network" to avoid inconsistencies, but ideally clients do better than that ↺

> and your user has how many clients connected? how is that relevant ↺

because it's a race right?

if you go on a tangent about race conditions, this is irrelevant for the topic

only because a race condition could exists, does not mean we should not provide proper GUI that tells the user what they can do

it's very relevant, my point is knowing you can send at most 1 isn't a full solution, you also have to handle the error when the one you sent didn't win right?

nobody said its a full solution

nobody needs a full solution

so if you have to handle that, why not just send the limit there

we just need to know when i disable the button

because then i need to display errors for reactions, and i can not prevent the user from sending it

the way I see it, we don't disable the button, we just change the behaviour from "add another emoji" to "replace the current emoji"?

colinR: sorry, no idea then and no time to help debugging this further unfortunately.

No problem I will find a way soon

> because then i need to display errors for reactions, and i can not prevent the user from sending it you have to display errors anyway for when you lose the race ↺

no i dont have to

its not even possible to interpret that error currently

we dont store the message id for non-body messages

hence i cannot find anything related to that error

that seems to make this useless then?

you send a reaction, it may or may not be applied, you don't know

(slidge could attach some more info in the "reaction error" stanza btw, this was your suggestion lovetox on the gajim tracker and plan to experiment with that too)

if you only accept 100% solutions, yes this is not a 100% solution

but i also implement 90% solutions, if the 10% mean work i dont want to do

This isn't a 1% solution though lol

don't they say "perfect is the enemy of good"?

If reactions matter and you can't accept some for some reason it seems you should have a way to convey that

yes we are working on that currently, the service can convey that via disco info

approach it from that angle, and you have a full solution and don't need this disco hack in the first place

> This isn't a 1% solution though lol yes it is. I have not had witnessed a single occurence of something going wrong with reactions since they're implemented in XMPP clients. What we have is a 99,9999% solution. ↺

>> This isn't a 1% solution though lol > yes it is. I have not had witnessed a single occurence of something going wrong with reactions since they're implemented in XMPP clients. What we have is a 99,9999% solution. This isn't implemented anywhere though? ↺

(I mean, nothing going wrong, except the cheogram fallback/conversations conendrum but this isn't related to what we're talking about :))

> This isn't implemented anywhere though? AFAIK, all clients just drop errors in relation to reactions, so yes, what you are worried about is widely out there already. ✏ ↺

but nobody except your service sends errors, because servers dont care about reactions normally

connectivity issues are a whole world of things, aren't they?

this was not a accusation, i just mean practically there are not many services that even would implement limits

so this is a solution basically just for gateways

what I meant was you can get an error from your server because the remote server you're sending a message to is offlin

>> This isn't implemented anywhere though? > AFAIK, all clients just drop errors in relation to reactions, so yes, what you are worried about is widely out there already. right, I thought you were trying to fix that though? Hence my suggestion as to a real fix vs a more complicated thing that won't fix it ↺

open a 1:1 chat with me, let me shutdown my prosody, send a reaction, your server will reply with an error saying my server cannot be reached, but right now, gajim silently drops it, doesn't it?

yes

> right, I thought you were trying to fix that though? Hence my suggestion as to a real fix vs a more complicated thing that won't fix it these are not mutually exclusive. ↺

i mean .. we could show the error

it does not fix the gui problem that the user then needs first remove his reaction, then change it to something else

> i mean .. we could show the error (I have a local branch where I do, and also opened a nbxmpp MR related to that) ↺

instead of just clicking on something else

>> right, I thought you were trying to fix that though? Hence my suggestion as to a real fix vs a more complicated thing that won't fix it > these are not mutually exclusive. but the real fix means you don't need to do the partial fix, vs needing both ↺

which the disco info would allow

the disco info allows for better UX

but realisticly the error showing is also necessary at some point

> (I have a local branch where I do, and also opened a nbxmpp MR related to that) this one <https://dev.gajim.org/gajim/python-nbxmpp/-/merge_requests/103> — it is very weird that when we fallback to the first available language, we remove the error message. I am almost 100% convinced this was an unintended side effect of using popitem here ↺

> but realisticly the error showing is also necessary at some point 👍 ↺

ah yes it was

i must have been drunk

or not drunk enough

also why index 1 is popped

because it returns a tuple (key, value)

😂 obligatory https://xkcd.com/323/

ah, yeah

maybe i thought popitem, does not infact remove it from the dict for some reason

getting _a_ value from a dict is surprisingly convoluted in python

ah you cannot access a dict by index

i wanted the first element

so this is the only way, except for yours converting the dict to a list

as ugly as it looks, `next(iter(dictionary.values()))` seems to be the canonical way

yes .. even the values obj is not subscriptable

dicts only guarantee ordering of ~elements~ items since 3.9 or something like that, before that there was no ordering, and we still have https://docs.python.org/3/library/collections.html#collections.OrderedDict in the stdlib as a relic of that time ✏

lovetox pushed 1 commits to branch python-nbxmpp/master fix: Leave text condition in place in CommonError.get_text() - https://dev.gajim.org/gajim/python-nbxmpp/-/commit/0846e1729815b8c62d1a52877842aad9fae0fd6c

> lovetox pushed 1 commits to branch python-nbxmpp/master > > fix: Leave text condition in place in CommonError.get_text() - https://dev.gajim.org/gajim/python-nbxmpp/-/commit/0846e1729815b8c62d1a52877842aad9fae0fd6c > > I made <https://dev.gajim.org/nicoco/gajim/-/commit/63d277a0c6e3d263887be0db0cd058bc7ad0f0f9> in relation to that, but did not submit it as a MR yet because I wanted to test for a few days and make sure all conversation views don't end up filled with useless errors. it does not seem to be the case so far, but I have not been running it for long. ↺

but its against the concept

back then when i remade the db layout

the idea was to have it work, so it does not matter in what direction you request messages

exactly for this purpose that one day we could scroll up and load messages from the server in reverse order

such a change, would then show all errors in the message view

because you did not receive the message for the error yet

oh interesting

well, I did not submit a MR for it anyway ;)

thats why the concept is

store all data without checks in the database

if a message with body comes in i want to display, i join everything thats up to that point in the database

that works for the reverse case

but of course it makes not much sense for reactions

in this case i would filter out in the join reactions that have an error attached

but i have no good way to tell the user the story that back then he send a reaction but it was not received ..

maybe we dont need to do that

maybe reaction errors should be just shown in-time, when they really happen

not when we receive them via MAM

to show them in-time, i dont actually need to store them to the db, i just need to find the reaction it belongs to, at point of receiving

for that the only thing we need to do is, store the message-id under which the reaction was sent

or .. depend on the server adding the context to the error

which is a good enough solution for me

so simply display all errors that have a reaction namespace in it, and are not received via MAM

but with the message-id stored in the db, we could also remove the error reaction from the db

in https://xmpp.org/extensions/xep-0444.html#example-10 there is no reaction namespace anywhere, but I guess you're saying the error-inducing stanza should be "echoed" in there somewhere, right?

errors are allowed to have the offending stanza attached to it

ejabberd does that always to my knowledge

yes, slidge does not do it ATM but I can definitely add it

some other servers dont, its optional

I just have had no good reason to do so yet, but it looks like I'll soon have one :P

but the right solution would be to add a column and store the message id

because without that even when you add the context

i cannot find the reaction in the db

it could be any reaction to messages from that user

(wow, I wrote a unit test for the unnamed-chats branch, applying your suggestion I broke it without noticing, then it was detected by the gitlab pipelin. professionnal software dev stuff happening tonight)

ahhh the context includes the message-id

...

hmmm i tend to think we can get through with just error context

in my opinion all servers should add the context

its just not a must in the rfc

haven't dived into it much but it feels like you're right

The reason slidge does not do it is that slixmpp does not make it easy. Right now to reply to incoming stanzas with errors in slix, you just `raise XMPPError(condition, text)` in some handler which is quite neat but… adding the error-inducing stanza is either quite complex or I just have not found out how. It feels like this is more a slixmpp enhancement than a slidge enhancement to write. ✏

i got it fixed already

> i got it fixed already and what was it? ↺

nicoco, question is if we still needthe disco stuff ...

if we have the error stuff

i dont think we cache errors also, so if you switch away from the chat the user never sees the error

but hard to reach a perfect solution here

> nicoco, question is if we still needthe disco stuff ... I take it you don't like the idea of changing the behaviour of "clicking on a second emoji" depending on this? I think it was a good way of solving max_reaction_per_user=1. ✏ ↺

> and what was it? i think i did not start dbus sessions and xdg-portal ↺

no i have no problem with discoing the domain

i just dont follow the argument that some limitation a service advertises does not apply to the user accounts the service hosts

thats really a weird idea to me

I was talking about GUI here

lovetox but the file picker is not resized as its home directory is not seen what would be the issue

we dont offer the file picker, we just send a dbus message to your system to open it

What my MR does is: if max_reaction_per_user=1, then clicking on an emoji when we already sent one does not send <reaction>1st</reaction><reaction>2nd</reaction> but only <reaction>2nd</reaction>

so any problem that you have within the file-picker is nothing gajim can solve

nicoco, yeah i know

im fine with this MR but only if we query the domain

are you fine with this part or not?

ok I understood you right then :)

i think its not worth it if it does only work if a user is "online"

btw, does your gateway convey the status? so removing the resource if someone is offline?

or are the people always online

ok, then we can have both better error handling and a nicer UX for max_reaction=1 then, can't we?

> btw, does your gateway convey the status? so removing the resource if someone is offline? I think no chat service I bridge really has an "offline" concept, but there are "deleted accounts" instead ↺

everybody seems to use "last seen on XXX" now ✏

not sure what you mean by "removing the resource"?

no i mean if presence=unavailable

in xmpp a client that is offline, then there is no resource

meaning no disco

i need to check but it is highly possible that even when the bridged contact sends presence=unavailable, slidge will still reply to disco directed at the offline resource, which is not really consistent but has not caused any issue so far

but no client would do this

yup

I tend to use presence show="xa" instead of offline, as it is a nice hack to have better participant lists in most XMPP clients… ✏

anyway, i think larma is wrong here, saying a gateway cannot advertise its limitations on its own disco info, because one would interpret it as only applying to chats with the gateway itself is absurd to me

there is also no need to add any "server-wide" stuff, if i find a reaction limit on a gateway

any sane developer knows thats a limitation of the gateway which applies obviously to all entities reachable over it

and not just to chat messages to the gateway it self

and further the XEP specifically mentions limitations on gateways as the use case for this disco info

i mean if i read the XEP in a vaccum

I'd rather we ask him directly, but IIRC, it's not so much that he had strong opinions about how it should be for a gateway, but rather that he wanted an addition that could work for something else than gateways

how would you even get the idea to advertise this on the resource

i actually think that he doesnt think this is a problem

thats why i asked you if he specifically said this

i also see the problem for you personally here

you can include it on all contacts

i dont care, gajim does not care

i dont see how it can be hurtful to add it on the domain

it does not hurt, but adding a third field "scope" does not hurt either IMHO ✏

you can add it, but i dont want Gajim querying it, for me there is no confusion what that limit means

this is so far edge case, when would that ever become relevant

only when users could configure themself the limitations on their clients

and that would never be something i would even consider supporting

I'm entirely fine with it and did not expect to check for the scope field whenever I get back to working on this MR :)

I do believe that we might see per-muc emoji restrictions at some point if (a) xmpp becomes more popular for public large groups and/or (b) someone specs and implements "custom emoji reactions" but I am not going to be the one working on that

that's a "later" problem anyway

i mean if a muc defines specific emojis as allowed, i guess they are not many

right now there exists only a allowlist

i can imagine building a custom emoji picker for something like that

its a difference if you need to provide a performant emoji picker for 4000 emojis or for 10

so kind of reverting my statement from earlier that this is not an option in Gajim

when i back then thought about it, i thought you can disallow one or two emojis

thats a different story

for the dissallow case, error handling is probably the better solution

FWIW, I only encountered this emoji subset thing with telegram, where if you don't pay for telegram premium you can only react with 🤓🤬👌🥱🎉💋🖕😍👀😈🎃🙈😇🎅😂❤‍🔥😴🤷‍♀🍓🤔😡🏆🎄🕊🤡🤮😱😁💔👎🆒🤷‍♂👻🫡💩👨‍💻☃👏✍🥰🌭🤣💊🌚🔥💯🐳🤗⚡💘🥴🙏🤝😎🤷🙉🍾🙊❤🤩😘🦄🗿😭🤯👍🍌👾😨😐🤪💅🤨😢 In discord, AFAIK when you pay you have access to custom emojis, mostly

sorry nicoco, i had more comments, just didnt click finish review

damn, good catches

nicoco, so affiliation messages have real jids, so we use now for the groupchat name then the localpart or the nickname we have for this contact assuming we have them in the roster

yes? I believe in most private groups, you are actually presence sub=both with all people in the group. At least that's true for me.

oh, there might be a "nick" attribute in the affiliation list, but that's rarely used AFAIK, notably because not all clients actually play nice with the MUC renaming you. I recently had an issue with a quicksy ios user because I set a reserved nickname for them, and it broke quicksy ios: https://github.com/monal-im/Monal/issues/1397

there can be no nick if the user is not joined

reserved nicknames are a thing

what i meant to say is, there are situations where there will be no nick

oh right

yes, fallback to the local part sounds reasonable here, right?

oh I see your concern I think

we actually never use the nickname if the participant is online…

my concern was that currently we use roster nick or localpart

question is if it should be roster -> resource -> localpart

but we fall back to the issue of having to calc on all joins/leaves, don't we? this was the major concern on the previous iteration ✏

but we fall back to the issue of having to calc on all joins/leaves, don't we? this was the major concern on the previous iteration ✏

no, because we calc only on join

i would not change that

but yeah ..

ok, we have a slight inconsistency for the group name depending on who's online when we join then, but we already have an inconsistency depending on who's in our roster anyway

no actually it would be a problem

on each join the name would potentially change

depending on whos online currently

i dont like that

technically we could fetch the pep nickname of members not in our roster too but this feels unnecessary, right?

keep it simple and lets role with what you have now

we can always extend this logic if its necessary

similarly to the previous discussion, I believe this is a 95% solution

you are usually "friend" with people in your private groups in my experience

yes, lets leave it at that

and we will also make it easier to rename a chat

maybe with context menu

then people that think it bothers them, can give the chat a descriptive name anyway

sounds good to me

all this is a for a sensible fallback

the optimal case of course is people naming their chats

the only time i not name them are, quick adhoc chats that have no purpose a few days later

we don't control what other clients do, and I think there are groupchat creation flows in Conversations that don't offer to set a name for the chat on creation.

In my experience, non-tech users tend to create a lot of groups, and not name them.

yeah, the point is they can if they are not happy

like, we dont offer a feature here that makes naming chats obsolete

we just improve the default

and we're in line with what other modern clients do, too

one other thing i noticed

you just check if its members only

i wonder if thats a problem

like it needs to be disco_info.muc_is_members_only and disco_info.muc_is_nonanonymous

if its anonymous we will not receive affiliations

I think you're right

It's rare to not have both set, but it can happen

nonanonymous is a preconditions for the name calculation even working

members_only is when we want to use it

that said, if `muc_data.affiliations` is empty we fallback to the local part, but we might as well not send the queries

I'm looking at the XEP and I wonder if muc#roomconfig_getmemberlist isn't what we actually need to check?

thats some custom thing or?

i dont think thats official

xep-0045 yes https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owner

ah yeah but its useless

since omemo came every server needs to return that for chats, otherwise omemo is broken

yes it can theoretically configured to not do this

but this should be a rare enough case, that we can live with IQs returning an error

its a few lines to add this check though ..

a bit more I think?

i think its good enough that we dont send the affil requests when its anonmous

then affil will be empty and we return local

roomconfig_getmemberlist is a list-multi, so we need a bit more than a few lines I think, because there is no property related to that, and need to check against our own affiliation/role too. not that many lines, probably.

but you're saying we don't need it, so let's just turn `if disco_info.muc_is_members_only` to `... and disco_info.muc_is_nonanonymous` in the two occurences of this check?

or do you want an helper for that, to keep it DRYer?

i think its enough if we add the condition to the affil request

damn I already pushed

because as you said if the affils are empty, we anyway fall back to local

yeah .. no hard opinion

then check in both is also ok

leave it

maybe we can have our own affiliation in there?

maybe not

i discovered another problem now that we changed the approach of storing the name in the database

there are 2 more events that change the name

1. when a bookmark is changed 2. when name in disco is changed

both modules would now need to trigger the calc code

and store then result in the database

damn. I will look into this then, but not tonight because my eyes do not want to stay open :)

yes i try to write down my thoughts how this should be handled in the mr