MUC-wise, what type of stanza should be prevented from being sent based on `muc#roomconfig_allowpm` - all types of stanza, or only message stanzas?
chronosx88has left
chronosx88has joined
papatutuwawahas joined
lovetoxhas joined
moparisthebesthas left
moparisthebesthas joined
Neustradamushas joined
Arnehas left
paulhas left
paulhas joined
govanifyhas left
govanifyhas joined
lovetoxhas left
Arnehas joined
mdoschhas left
mdoschhas joined
lovetoxhas joined
mukt2has joined
peetahhas left
peetahhas joined
govanifyhas left
florettahas left
govanifyhas joined
moparisthebesthas left
papatutuwawahas left
krauqhas left
krauqhas joined
moparisthebesthas joined
florettahas joined
debaclehas joined
mukt2has left
Steve Killehas left
Steve Killehas joined
mukt2has joined
Andrzejhas left
Andrzejhas joined
lovetoxhas left
Andrzejhas left
Arnehas left
Arnehas joined
krauqhas left
krauqhas joined
govanifyhas left
govanifyhas joined
x51has joined
eevvoorhas joined
nycohas left
andrey.ghas joined
mukt2has left
lovetoxhas joined
Yagizahas joined
neshtaxmpphas left
andyhas left
debaclehas left
alacerhas left
alacerhas joined
mukt2has joined
nycohas joined
Adihas left
serge90has joined
Adihas joined
govanifyhas left
govanifyhas joined
Guushas left
Guushas joined
alameyohas joined
mukt2has left
mukt2has joined
mukt2has left
Marandahas left
waqashas joined
alacerhas left
alacerhas joined
stpeterhas joined
stpeterhas left
alacerhas left
Marandahas joined
alacerhas joined
alacerhas left
andyhas joined
mukt2has joined
Wojtekhas joined
lovetox
depends, are you going to implement a roomconfig_allowiq?
lovetox
The XEP says, its for allowing sending messages
lovetox
so i would say only messages
chronosx88has left
chronosx88has joined
lovetox
if you block IQ this would break other stuff, like avatars for example
govanifyhas left
govanifyhas joined
dwd
Avatar IQs shouldn't get passed through directly anyway - otherwise you're querying the full jid not the bare. So they get handled differently.
andrey.ghas left
Zash
Isn't that how it works in some implementations?
dwd
I think some implementations intercept vCard to full jid, yes.
dwd
And some (most, these days?) intercept MUC vCard IQs.
Zash
This undocumented behavior everyone implement and expect....
Guus
is roomconfig_allowiq even a thing?
dwd
It is if you want it to be. ;-)
Guus
XEP-0045 doesn't specify it, only roomconfig_allowpm
mukt2has left
Andrzejhas joined
chronosx88has left
chronosx88has joined
mukt2has joined
Lancehas joined
lovetox
Guus, MUC also does not specify passing IQs on, but i guess you do it?
lovetox
dwd, why would you say Avatar IQs should not get passed through?
lovetox
is there any part of the XEP that sepcifically allows Vcard IQs but not all other IQs?
MattJ
Is there any part of the XEP that says iqs should be routed at all?
Ge0rG
0045 is very vague
Zash
NAFAIK
Zash
Or, maybe? 🤷️
dwd
lovetox, Well if you simply pass them through, they hit the server with a full jid and don't work.
Zash
(unless the server hijacks full jid IQs)
lovetox
dwd, maybe you underestimate what hacks servers implemented
lovetox
last time this topic came up you could even query pubusb of anonymous users :D
lovetox
this was discussed on the list
larma
Zash, the server is supposed to hijack iqs to full jid for vcard iirc
larma
> In accordance with XMPP Core [5], a compliant server MUST respond on behalf of the requestor and not forward the IQ to the requestee's connected resource.
Zash
Where does it say that?
larma
xep 0054
Zash
That's just under
> A user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID.
Zash
note *bare JID*
lovetox
larma, but if you send a iq to an anonymous muc jid, nothing says the server needs to map this to real jids and then answer
Steve Killehas left
larma
well, MUCs don't support IQs
lovetox
works quite well here :D
larma
MUC servers doing IQs operate outside the spec
lovetox
i even transfer jingle via MUCs
lovetox
yeah but all that was discussed anyway, but it seem to be stalled
MattJ
> MUC servers doing IQs operate outside the spec
100% agree that it's not in the spec, but all the servers are doing it and all the clients are expecting it
larma
well, we only need it for avatars in semi-anon mucs anyway
larma
maybe we should just solve this one thing and then stop again doing iqs in mucs
MattJ
We recently extended it to support PEP queries in Prosody
larma
yeah, even worse
MattJ
Well we're working to deprecate vcard-temp, so choose "worse"
lovetox
why do we need avatars in anonymous mucs?
lovetox
i would question that assumption
larma
lovetox, well, some users apparently want that feature
lovetox
i think they want avatars, and dont care about anonmous mucs
larma
IQ routing in MUCs only make sense for semi-anon MUCs, but exactly in semi-anon MUCs you actually typicall don't want them because they often break anonymity.
It would be okish if servers would not route them to bare JIDs for vcard/pep because then the client can decide that they want to not share their vcard/avatar with certain user. The current Prosody behavior basically means semi-anon MUCs are broken in Prosody (because most users have public PEP nodes for OMEMO with their public key on it which uniquely identify them).
Arnehas left
lovetoxhas left
larma
I mean, we can probably argue if semi-anon MUCs are needed at all. Many messengers don't have them. But I also know multiple persons that decided they don't want to use Matrix specifically because it doesn't have semi-anon group chats, so there seems to be some amount of users interested in this feature
mukt2has left
mukt2has joined
mukt2has left
mukt2has joined
Zash
I'm open for having the iq routing stuff be configurable per room.
Steve Killehas joined
dwd
In most cases, semi-anon rooms seem to be used to shield the Jid, rather than hide the identity.
mimi89999
Please keep semi anon rooms or everybody who ever joins any popular MUC will be flooded with spam and will never get rid of it.
emushas left
emushas joined
neshtaxmpphas joined
Steve Killehas left
govanifyhas left
govanifyhas joined
Steve Killehas joined
deuillhas left
Andrzejhas left
Andrzejhas joined
mukt2has left
andyhas left
chronosx88has left
chronosx88has joined
andyhas joined
marekhas left
marekhas joined
lovetoxhas joined
eevvoorhas left
eevvoorhas joined
Tobiashas left
Tobiashas joined
lovetoxhas left
govanifyhas left
govanifyhas joined
eevvoorhas left
eevvoorhas joined
Andrzejhas left
debaclehas joined
Andrzejhas joined
goffihas left
Yagizahas left
marekhas left
marekhas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
lovetoxhas joined
krauqhas left
krauqhas joined
lovetox
larma, this people thats so absolutely need semi anonmous mucs, are probably fine when we tell them they dont have the nice things there
lovetox
Gajim 1.3, will not use vcard-temp anymore, only pep for vcard and avatar
lovetox
and both will be in access_mode=presence by default
lovetox
so no avatars anymore in rooms for these users, except they specifically set the "i want to make it public"
Zash
I saw the privacy control for that, really nice 😀
lovetox
setting
Andrzejhas left
Andrzejhas joined
krauqhas left
krauqhas joined
eevvoorhas left
papatutuwawahas joined
andrey.ghas joined
MattJ
Yay
chronosx88has left
larma
lovetox, that's great. unfortunately, many servers now convert presence-only 0084 avatars to world-public 0153 avatars due to 0398 (80% of servers according to https://compliance.conversations.im/test/xep0398/)
Zash
I don't think that's accurate
Zash
At least the 398 implementation shipped with Prosody respects the permissions on the 0084 node(s) when handling a vcard-temp query.
larma
wait, what? You added a out-of-spec permission system to vcard-temp?
Zash
You could say that. It's a view over pep avatar+vcard4 tho, and the whole thing is meant to go in the trash once vcard-temp is gone.
Andrzejhas left
larma
ah, there is mod_vcard and mod_vcard_legacy and they both implement vcard-temp, just in different ways
Zash
You can make the avatar public the same way you make OMEMO stuff public
Zash
Yeah, mod_vcard_legacy is meant as a transition mechanism to PEP-only
Zash
So with the data stored in PEP, it made sense to respect the PEP permission model when composing the legacy vcard from PEP parts
Zash
If you only use vcard-temp, things stay public, but if you use PEP you get more control
Zash
Whether the "you" here is the client or user is up to the client/-devs 🙂
larma
yeah makes sense
Zash
Isn't this covered by (or at least implied by) https://xmpp.org/extensions/xep-0398.html#security
larma
well, it says "in the future" 🙂
Zash
> Last Updated 2018-08-27
It's 2021, the future is now!