XSF Discussion - 2021-01-06

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?

depends, are you going to implement a roomconfig_allowiq?

The XEP says, its for allowing sending messages

so i would say only messages

if you block IQ this would break other stuff, like avatars for example

Avatar IQs shouldn't get passed through directly anyway - otherwise you're querying the full jid not the bare. So they get handled differently.

Isn't that how it works in some implementations?

I think some implementations intercept vCard to full jid, yes.

And some (most, these days?) intercept MUC vCard IQs.

This undocumented behavior everyone implement and expect....

is roomconfig_allowiq even a thing?

It is if you want it to be. ;-)

XEP-0045 doesn't specify it, only roomconfig_allowpm

Guus, MUC also does not specify passing IQs on, but i guess you do it?

dwd, why would you say Avatar IQs should not get passed through?

is there any part of the XEP that sepcifically allows Vcard IQs but not all other IQs?

Is there any part of the XEP that says iqs should be routed at all?

0045 is very vague

NAFAIK

Or, maybe? 🤷️

lovetox, Well if you simply pass them through, they hit the server with a full jid and don't work.

(unless the server hijacks full jid IQs)

dwd, maybe you underestimate what hacks servers implemented

last time this topic came up you could even query pubusb of anonymous users :D

this was discussed on the list

Zash, the server is supposed to hijack iqs to full jid for vcard iirc

> 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.

Where does it say that?

xep 0054

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.

note *bare JID*

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

well, MUCs don't support IQs

works quite well here :D

MUC servers doing IQs operate outside the spec

i even transfer jingle via MUCs

yeah but all that was discussed anyway, but it seem to be stalled

> 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

well, we only need it for avatars in semi-anon mucs anyway

maybe we should just solve this one thing and then stop again doing iqs in mucs

We recently extended it to support PEP queries in Prosody

yeah, even worse

Well we're working to deprecate vcard-temp, so choose "worse"

why do we need avatars in anonymous mucs?

i would question that assumption

lovetox, well, some users apparently want that feature

i think they want avatars, and dont care about anonmous mucs

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).

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

I'm open for having the iq routing stuff be configurable per room.

In most cases, semi-anon rooms seem to be used to shield the Jid, rather than hide the identity.

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.

larma, this people thats so absolutely need semi anonmous mucs, are probably fine when we tell them they dont have the nice things there

Gajim 1.3, will not use vcard-temp anymore, only pep for vcard and avatar

and both will be in access_mode=presence by default

so no avatars anymore in rooms for these users, except they specifically set the "i want to make it public"

I saw the privacy control for that, really nice 😀

setting

Yay

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/)

I don't think that's accurate

At least the 398 implementation shipped with Prosody respects the permissions on the 0084 node(s) when handling a vcard-temp query.

wait, what? You added a out-of-spec permission system to vcard-temp?

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.

ah, there is mod_vcard and mod_vcard_legacy and they both implement vcard-temp, just in different ways

You can make the avatar public the same way you make OMEMO stuff public

Yeah, mod_vcard_legacy is meant as a transition mechanism to PEP-only

So with the data stored in PEP, it made sense to respect the PEP permission model when composing the legacy vcard from PEP parts

If you only use vcard-temp, things stay public, but if you use PEP you get more control

Whether the "you" here is the client or user is up to the client/-devs 🙂

yeah makes sense

Isn't this covered by (or at least implied by) https://xmpp.org/extensions/xep-0398.html#security

well, it says "in the future" 🙂

> Last Updated 2018-08-27 It's 2021, the future is now!