jdev - 2026-02-05

How would that work in a MUC, prosody cannot know who in the MUC will request

> if I wouldn't allow the target jid to see the photo, then I shouldn't tell it about the photo hash in presence I 100% agree ↺

> How would that work in a MUC, prosody cannot know who in the MUC will request i'm not aware of a usage where someone would be in a semianon muc and give only specific members an avatar. if its not semi-anon id figure they can just request it directly or whatever else ↺

That is automatic, if I configured my node for contacts only, then only users of the anon MUC can request which are also my contacts

what?

how would they request your contacts only pfp without revealing their jid

The MUC relays it

But I'm not sure about the details as this is a s2s process

Or are you saying even a contact should not be able to request?

if the muc is relaying it... you either share the hash AND the photo to the muc... or you dont share either to the muc... because its the same entity

> Or are you saying even a contact should not be able to request? how would a semianon be in your contacts? ↺

It is not but it depends what the MUC does with the iq

The MUC knows your real jid

It can relay the iq with your real jid

https://downloadable.pain.agency/file_share/019c2cae-9c30-74e6-9f5d-38492b280c1f/the-concept-of.gif

But. Not sure if it does, If not than indeed it would be useless to send the hash, because nobody will be able to request the avatar

But I was under the impression that it relays the iq as coming from your real jid

> But I was under the impression that it relays the iq as coming from your real jid wouldnt that effectively make semianon useless? ↺

if i think about it, that cannot work, if the muc would change the "from" of the iq to the real jid, the pubsub server would answer it to the real jid and not to the MUC

lets wait for someone who knows what really is happening :)

so if we assume its the anon jid, then the server could know that the "to" attribute of the presence is not in the contacts, and not inject the hash

but then it would look like you have no avatar even in non-anon rooms

where half the people are maybe your contacts, and the other half is not

now you could say the contacts get the presence also to their real jid anyway because they are contacts

but this would then mean the client needs to ignore the missing hash in the muc and take the one from the presence to his server

but only for contacts, for non contacts it would need to still respect the presence in the muc

all quite complicated, i rather query every hash once a session, and maybe get nothing in return

> all quite complicated, i rather query every hash once a session, and maybe get nothing in return I think that is correct for a client, this is more a discussion on what the correct server behavior would be ↺

what is correct depends here on what the client wants to do

my understanding is the server is the one injecting the hash

yes, but there is no right way, one solution makes server/client code easy, but sometimes you will receive an empty avatar. The other makes client/server code more complicated, but there will be no requests which are empty

depends on what you value more

lovetox: how does gajim store users in a muc? does it store them by resource or by occupantid?

resource

as occupant-id is not always available

but depends on what you mean by "store"

as in what is the primary key

i dont store users to the database

so .. yes there is a contact object and it has a dictonary where the key is the resource, of all participants

alright. thank you

i have a occupants table where the primary key is (account, jid, occupant-id) where i store occupant related data of the message, like nickname, avatar hash, real jid etc

but these are considererd metadata for a particular message, and i dont use that table to get participants of a MUC

https://dev.gajim.org/gajim/gajim/-/blob/master/gajim/common/storage/archive/models.py?ref_type=heads

feel free to take a look at the database layout

if the request is relayed via MUC then it comes from a non contact jid. Unless the MUC is in your contacts which generally would do other bad things so no one does that. There's no way for your server to know if a muc participant is a contact or not so none of them can even get your avatar. Since none of them can get it there's no point in advertising to them that you even have one. Nothing needs to change in the client it's a server side fix

Except for the part where I'm told some clients add this hash themselves. I'm not sure if anyone does this anymore? But apparently everyone used to and indeed I had to find the code to prove the server does it at all

https://xmpp.org/extensions/xep-0153.html#bizrules-presence "If a client supports the protocol defined herein, it MUST include the update child element in every presence broadcast it sends and SHOULD also include the update child in directed presence stanzas (e.g., directed presence sent when joining Multi-User Chat (XEP-0045) rooms)."

The server-assisted behaviour is mentioned in XEP-0398: https://xmpp.org/extensions/xep-0398.html#presence

yes, if you argue thats why you include the hash, there are other options > If a client is not yet ready to advertise an image, it MUST send an empty update child element

and when these XEPs where written and discussed, i dont remember anyone considering pubsub permissions

altough the xep talks about the access model

https://xmpp.org/extensions/xep-0398.html#security

but not in relation to presences

> yes, if you argue thats why you include the hash, there are other options I'm not arguing anything, just trying to provide context. I didn't write any of the code involved, and haven't had much to do with avatars generally (possibly because none of my primary clients display them)

I think it makes sense to consider the access model on outgoing presence, and that should be easy enough to do