XSF Discussion - 2018-07-10

  1. MattJ

    Should a MUC room require a password for affiliated JIDs?

  2. MattJ

    XEP-0045 is silent on the matter as far as I can tell

  3. Ge0rG

    I'd say yes, for consistency reasons.

  4. Ge0rG

    But then again... 🤔

  5. Kev

    I think xep45 should be inconsistent, for consistency reasons.

  6. jonasw

    well played

  7. MattJ

    and another case I just hit... if a password is supplied but the room isn't password-protected...? :)

  8. Ge0rG

    is that due to process consistency, or due to consistency process?

  9. jonasw

    MattJ, uh... ignore?

  10. Kev

    Ge0rG: Not sure, but I think so.

  11. Ge0rG

    MattJ: I'd say: if the joining user is admin/owner, the room should be updated to use the password, otherwise, the user join be rejected.

  12. Zash

    What if a password is given in the room creation stanza?

  13. Ge0rG


  14. Kev

    MattJ: There's an argument for rejecting, I think.

  15. Kev

    If the security properties of the room have changed unexpectedly.

  16. MattJ

    That's what Prosody currently does, it seems

  17. Ge0rG

    This is the kind of argument that we owe proxy JIDs to.

  18. MattJ

    But it doesn't seem very useful (or requiring a password for owner/admin/member)

  19. Ge0rG

    Yeah, I can see how it might be useful to let the admins in without a password.

  20. Kev

    Or at least owners.

  21. Ge0rG

    if the owner wants to exclude admins, they should remove them from the affiliation list first?

  22. Kev


  23. Ge0rG

    maybe we should deprecate passwords for the sake of explicit affiliation management and namespace-bump?

  24. MattJ

    No thanks

  25. MattJ

    I just used passwords for something

  26. Ge0rG

    for whatthing?

  27. jonasw

    namespace-bump XEP-0045.

  28. MattJ

    jonasw, good idea

  29. jonasw

    can we tempban Ge0rG from all MUCs for this day? he’s trolling too much :)

  30. MattJ

    Ge0rG, a system where you invite one JID, but a different JID will join

  31. MattJ

    So I made a module that injects an invite token into the outgoing invite's password field, and validates the token provided as the password of the joining user

  32. jonasw


  33. jonasw

    I’m interested

  34. jonasw

    I want MUC invites

  35. jonasw

    to members only MUCs

  36. Ge0rG

    jonasw: I was just going to say that this isn't possible due to the federated nature of XMPP, but then I realized that there is a person in this MUC who could disable my access to yax.im and firewall me off.

  37. jonasw

    in onboarding

  38. Ge0rG

    MattJ: that's... interesting.

  39. Ge0rG

    MattJ: but please use PARS instead.

  40. Ge0rG

    I mean, technically you could just have per-user "passwords" for a MUC, but it feels wrong.

  41. Ge0rG

    It's a hack.

  42. Ge0rG

    Actually, I like it.

  43. jonasw


  44. jonasw

    reminds me that I need to try my per-device password SASL authcid hack

  45. MattJ

    Ge0rG, PARS isn't suitable here, the invite is accepted by a machine

  46. jonasw

    MattJ, what’s wrong with that?

  47. Ge0rG

    MattJ: use the PARS wire format to pass tokens along.

  48. MattJ

    Ge0rG, so you mean use a <preauth> element instead of a <password> element?

  49. Ge0rG

    MattJ: essentially yes, also you could use the URI parameter to carry such invitations via HTTPS

  50. MattJ

    Maybe in a future version

  51. MattJ

    The nice things about passwords is that all the code I was dealing with already supported them

  52. MattJ

    (except in reality each component had a bug, such as looking for or putting the password in the wrong place in the stanza)

  53. MattJ

    Turns out it's not a child of the <invite> element

  54. Ge0rG

    MattJ: you could change the server to use the pars token as the primary mechanism but to allow passing the token in the password field

  55. Ge0rG

    yeah, invitations with passwords are funny.

  56. Ge0rG

    nobody is checking corner cases

  57. Zash

    I'm trying to implement tombstones for MUC. How am I supposed to signal that?

  58. MattJ

    Isn't it in XEP-0045?

  59. Zash

    Not really

  60. Zash

    Not that I could see at least.

  61. MattJ

    Oh, you mean signal that the service implements tombstones?

  62. Zash

    To signal that, when joining/creating a room, that it's already been destroyed.

  63. Zash

    Hm, this seems to work with Gajim

  64. Zash

    Just needed to not reply with weird <messages>