XSF Discussion - 2021-01-06


  1. Guus

    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?

  2. lovetox

    depends, are you going to implement a roomconfig_allowiq?

  3. lovetox

    The XEP says, its for allowing sending messages

  4. lovetox

    so i would say only messages

  5. lovetox

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

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

  7. Zash

    Isn't that how it works in some implementations?

  8. dwd

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

  9. dwd

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

  10. Zash

    This undocumented behavior everyone implement and expect....

  11. Guus

    is roomconfig_allowiq even a thing?

  12. dwd

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

  13. Guus

    XEP-0045 doesn't specify it, only roomconfig_allowpm

  14. lovetox

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

  15. lovetox

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

  16. lovetox

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

  17. MattJ

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

  18. Ge0rG

    0045 is very vague

  19. Zash

    NAFAIK

  20. Zash

    Or, maybe? 🤷️

  21. dwd

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

  22. Zash

    (unless the server hijacks full jid IQs)

  23. lovetox

    dwd, maybe you underestimate what hacks servers implemented

  24. lovetox

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

  25. lovetox

    this was discussed on the list

  26. larma

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

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

  28. Zash

    Where does it say that?

  29. larma

    xep 0054

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

  31. Zash

    note *bare JID*

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

  33. larma

    well, MUCs don't support IQs

  34. lovetox

    works quite well here :D

  35. larma

    MUC servers doing IQs operate outside the spec

  36. lovetox

    i even transfer jingle via MUCs

  37. lovetox

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

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

  39. larma

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

  40. larma

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

  41. MattJ

    We recently extended it to support PEP queries in Prosody

  42. larma

    yeah, even worse

  43. MattJ

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

  44. lovetox

    why do we need avatars in anonymous mucs?

  45. lovetox

    i would question that assumption

  46. larma

    lovetox, well, some users apparently want that feature

  47. lovetox

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

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

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

  50. Zash

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

  51. dwd

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

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

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

  54. lovetox

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

  55. lovetox

    and both will be in access_mode=presence by default

  56. lovetox

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

  57. Zash

    I saw the privacy control for that, really nice 😀

  58. lovetox

    setting

  59. MattJ

    Yay

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

  61. Zash

    I don't think that's accurate

  62. Zash

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

  63. larma

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

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

  65. larma

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

  66. Zash

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

  67. Zash

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

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

  69. Zash

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

  70. Zash

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

  71. larma

    yeah makes sense

  72. Zash

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

  73. larma

    well, it says "in the future" 🙂

  74. Zash

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