MUC: Make allow_query_users discoverable

[lovetox]

Is your feature request related to a problem? Please describe.

• If a client joins a MUC, he starts to query disco info of users after receiving a caps hash
• Also vcard-temp avatars are queried after receiving the hash

This is not possible if allow_query_users is enabled.

If this roomconfig would be announced in the rooms disco info, clients could discover this before join and hence react accordingly (not query a hundred users)

Describe the solution you'd like
Announce the setting on the room disco info

Describe alternatives you've considered
Writing some ugly complex trial and error code to work around this.

[badlop]

This is not possible if allow_query_users is enabled.

I guess you mean if the option is set to false. In that case, can you edit your message?

[badlop]

If a client joins a MUC, he starts to query disco info of users after receiving a caps hash

Well, that may be a feature of some clients.

If this roomconfig would be announced in the rooms disco info, clients could discover this before join and hence react accordingly (not query a hundred users)

But that would require an additional implementation in the client.

I was looking in https://xmpp.org/extensions/xep-0045.html#disco-roominfo and elsewhere that document, and found no standard method to inform in the server (and determine in the client) when that feature is enabled or disabled.

If there's no standard method, we can implement one in ejabberd, but obviously client wouldn't support it, and would require implementing it, which probably won't happen if only ejabberd implements it and isn't standarized yet.

Maybe other servers inform this option (on an equivalent one) in some way that is a de-facto standard and ejabberd could follow it?

Or maybe those clients that query room occupants should be clever enough to query only a few occupants (for example five), and abort the process if all those initial five fail...

[lovetox]

No not only when it is false it should be either way announced.

Yes exactly that section you link describes that room config options can be put into the disco info answer, this is well standardized, and ejabberd uses this already, see the disco info of your support muc.

See the many roomconfig* fields.

What i ask is simply adding one more as it is useful to know before join.

other servers add custom config options with clark notation

 <field type="boolean" var="{xmpp:prosody.im}muc#roomconfig_unaffiliated_media">
        <value>1</value>
</field>

so i propose something like

 <field type="boolean" var="{xmpp:ejabberd.im}muc#roomconfig_allow_query_users">
        <value>1</value>
</field>

Disco Info: ejabberd support room

<iq xmlns="jabber:client" xml:lang="en" to="myjid/gajim.5TB7H4TI" from="[email protected]" type="result" id="86ab8abd-a949-4452-8d12-8804065474b2">
  <query xmlns="http://jabber.org/protocol/disco#info">
    <identity name="ejabberd" type="text" category="conference" />
    <feature var="vcard-temp" />
    <feature var="http://jabber.org/protocol/muc" />
    <feature var="http://jabber.org/protocol/disco#info" />
    <feature var="http://jabber.org/protocol/disco#items" />
    <feature var="muc_public" />
    <feature var="muc_persistent" />
    <feature var="muc_open" />
    <feature var="muc_semianonymous" />
    <feature var="muc_moderated" />
    <feature var="muc_unsecured" />
    <feature var="urn:xmpp:mam:tmp" />
    <feature var="urn:xmpp:mam:0" />
    <feature var="urn:xmpp:mam:1" />
    <feature var="urn:xmpp:mam:2" />
    <feature var="urn:xmpp:sid:0" />
    <x xmlns="jabber:x:data" type="result">
      <field var="FORM_TYPE" type="hidden">
        <value>http://jabber.org/protocol/muc#roominfo</value>
</field>
      <field var="muc#roominfo_occupants" type="text-single" label="Number of occupants">
        <value>151</value>
</field>
      <field var="muc#roomconfig_roomname" type="text-single" label="Natural-Language Room Name">
        <value>ejabberd</value>
</field>
      <field var="muc#roominfo_description" type="text-single" label="Room description">
        <value>ejabberd discussions</value>
</field>
      <field var="muc#roominfo_contactjid" type="jid-multi" label="Contact Addresses (normally, room owner or owners)" />
      <field var="muc#roominfo_changesubject" type="boolean" label="Occupants May Change the Subject">
        <value>0</value>
</field>
      <field var="muc#roomconfig_allowinvites" type="boolean" label="Occupants are allowed to invite others">
        <value>0</value>
</field>
      <field var="muc#roomconfig_allowpm" type="list-single" label="Roles that May Send Private Messages">
        <value>anyone</value>
        <option label="Anyone">
          <value>anyone</value>
</option>
        <option label="Anyone with Voice">
          <value>participants</value>
</option>
        <option label="Moderators Only">
          <value>moderators</value>
</option>
        <option label="Nobody">
          <value>none</value>
</option>
</field>
      <field var="muc#roominfo_lang" type="text-single" label="Natural Language for Room Discussions">
        <value>en</value>
</field>
</x>
</query>
</iq>

[badlop]

First of all: what client are you using that shows this behaviour?

so i propose something like

<field type="boolean" var="{xmpp:ejabberd.im}muc#roomconfig_allow_query_users">
        <value>1</value>
</field>

This is my point: muc#roomconfig_allow_query_users is not standard, it's what ejabberd uses. And obviously, for this feature to be useful, clients would need to implement the client part. And I expect they will only care implementing it if it's described in the protocol, or at least a de facto standard that several servers implement.

Writing some ugly complex trial and error code to work around this.

If you are using an aggressive client that sends queries to all occupants in a room... that same client could be improved to behave more politely: when it joins a room, send a query to one occupant; if that returns error, then don't query the remaining occupants.

[lovetox]

Every client that supports vcard-avatars does show that behavior.

If we receive a hash via presence, we query the avatar. Why? Because users want to see avatars.

Its fine by me if you break that standard with a non-standard config option. But at least have the courtesy to tell clients about it and not tell them to find out by trial and error themself.

XMPP is an extensible protocol, nothing stops you from putting this custom extension into your disco info, you dont need to standardize it.

Further its not standardized what "not-allowed" even means when i query a single JID. How would i interpret this as IQ querys in general are not allowed? The next server does only allow certain IQ querys and reacts with the same not-allowed error, which would not mean all IQ querys are forbidden.

Either way clients have to implement code here that takes into account that this custom setting exists in ejabberd.
And my ask is don't let everybody play guessing games that obviously will fail in edge cases.

Disco info is the place where you tell the world about this object. And not allowing any IQ querys which means, no avatars, no vcards and bunch of other things, is an important information that i want the user to know. It has the same importance like the "allow_pms" settings, which you happily disclose.

[badlop]

I'll take a look at the feature and hopefully upload here a patch for testing. What ejabberd version, install method, and what client are you able to implement the corresponding client part?

[lovetox]

I would implement it in Gajim. If you tell me upfront the var name, i can implement this and push it in the next version, then you could see for yourself if your patch is working, as i want to display that info to the user.

Or you have some testserver i could test it against, would also be ok.

I want to avoid compiling ejabberd myself and apply a patch as im not well versed with servers. If i must i would use the debian package or the docker hub install method.

[badlop]

Ah, ejabberd already provides a lot of custom fields in disco#info. Let's just add another one. For testing, I committed changes in my xmpp and ejabberd forks, and tested with Tkabber to change the room option and checked disco#info shows it.

You have installers and deb in https://github.com/badlop/ejabberd/actions/runs/2434116766

But maybe the easiest way is using the container in Docker:

1. Download image and start interactively with default settings (includes a self-signed cert, MUC, etc):

docker run -it --name ejabberd -p 5222:5222 ghcr.io/badlop/ejabberd:3830

...
2022-06-03 11:17:07.854337+00:00 [info] ejabberd 22.5.37 is started in the node ejabberd@localhost in 4.13s
2022-06-03 11:17:07.857653+00:00 [info] Start accepting TCP connections at [::]:5222 for ejabberd_c2s

2. If you want to register a pair of accounts:

docker exec ejabberd ejabberdctl register admin localhost mypass
docker exec ejabberd ejabberdctl register user2 localhost mypass

3. Login with Gajim 1.4.1 worked with those settings

[lovetox]

Hi,

works for me

<field var="muc#roomconfig_allow_query_users" type="boolean" label="Occupants are allowed to query others">
        <value>0</value>
</field>

[Neustradamus]

@lovetox: Can you look for this part too? Thanks in advance.

• XEP-0045: muc#roomconfig_allowpm does not exist in ejabberd #3736

[lovetox]

@badlop humble reminder, i tested this change, as there is no PR attached to this issue, i hope your changes dont get lost. LTGM.