jdev - 2023-05-17

  1. pep.

    Should "Setting someone's affiliation from 'none' to something else" be considered an affiliation change?

  2. pep.

    What's the use-case for this https://xmpp.org/extensions/xep-0045.html#example-176 (the <message/>)

  3. pep.

    What was the idea behind it

  4. pep.

    Anything to be worried about if someone discovers the address of a MUC this way by getting affiliated?

  5. lovetox

    pep., affiliation "none" is a normal user joined in a non-members-only chat

  6. lovetox

    if you change his affiliation to "owner"

  7. lovetox

    you dont want to inform him?

  8. pep.

    affiliation "none" is the absence of affiliation, really. So that's the entire XMPP world in a non-members-only chat that isn't affiliated with the room :P

  9. pep.

    Note the <message/>, it's not a presence, the user isn't joined in this case.

  10. lovetox

    yeah and if you affiliate someone, and he is not joined, the room tells him via message

  11. lovetox

    because it cant via presence

  12. lovetox

    i think the intention is quite clear

  13. lovetox

    users which get affiliated in a room should be notified about it

  14. pep.

    Why is it a MAY and why would a room not notify though?

  15. lovetox

    because its a optional feature

  16. lovetox

    which is not a MUST

  17. pep.

    Thanks captain :)

  18. pep.

    My question was, is there any reason this shouldn't be implemented

  19. lovetox

    that was not your question at all, if you ask me, you posted an example and asked

  20. lovetox

    > What was the idea behind it

  21. pep.

    Anyway, now that's my question

  22. lovetox

    if you take a guess from me, a xmpp spec should only enforce things which are essential for it to work, this thing seems not essential to MUCs working

  23. lovetox

    especially in the light that "invites" also exist

  24. lovetox

    though that may be not exactly the same

  25. pep.

    Yeah ok that's not what I'm asking, still, sorry. I'm wondering if there's a reason someone would be against implementing this

  26. lovetox

    The implementation note says: Out of courtesy, a MUC service MAY send an out-of-room <message/> if a user's affiliation changes while the user is not in the room; the message SHOULD be sent from the room to the user's bare JID, MAY contain a <body/> element describing the affiliation change, and MUST contain a status code of 101.

  27. lovetox

    this was added very early in the spec

  28. lovetox

    so i would say from the word "courtesy", it was regarded as something thats not necessary at all, just a nice thing someone could do, but nothing someone should be forced to

  29. lovetox

    but of course thats all guessing :) maybe you find the one who put it there

  30. pep.

    Yeah.. and no security considerations or anything it seems. The thing is I added that as a MUST in 0463, I remember there was a reason for it, but I can't remember it. I'm trying to now :x

  31. lovetox

    from reading that xep, it seems not essential to inform out of room members

  32. moparisthebest

    Yea that sounds fun security wise, I bet there exist clients you can force join to a room with an affiliation change

  33. lovetox

    moparisthebest, you receive a message and trigger a very specific join presence?

  34. lovetox

    this can not happen on accident

  35. lovetox

    a developer wanted it that way

  36. lovetox

    i dont see any problem here, even IF the client would join

  37. lovetox

    i mean many client join if you send them an invite to a room automatically

  38. lovetox

    thats a basic feature

  39. pep.

    I guess if someone is added in affiliations it's that it's ok for them to learn the JID, I guess.

  40. lovetox

    i wonder though which server has implemented this out of bound notificaiton

  41. lovetox

    i would like to test if Gajim acts correctly

  42. lovetox

    i definitly never tested that

  43. pep.

    I guess if someone is added in affiliations it's that it's ok for them to learn the JID

  44. pep.

    Yeah me neither. I learned of it when I wrote the spec, talking with people

  45. moparisthebest

    Joining unsolicited MUCs would be a bad thing no? iirc clients should only accept invites from people on their roster at most

  46. moparisthebest

    Otherwise it'd be great for spam and other kinds of abuse

  47. lovetox

    of course, you can limit that

  48. lovetox

    but if a family member opens a groupchat, i dont want to be asked if i want to join

  49. lovetox

    or at least a client should offer a option where i can set auto accept

  50. lovetox

    whatsapp does not ask you if you want to join for example

  51. lovetox

    im not sure how it would benefit a spammer if instead of sending you the spam directly

  52. lovetox

    adds you to a muc

  53. lovetox

    but i guess maybe someone wants to have many people joined or something

  54. Zash

    https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/ again?

  55. moparisthebest

    Actually it'd be a kind of great way to spam

  56. pep.

    Ok, the reasoning behind sending a message for affiliation updates is so that clients don't have to poll.

  57. moparisthebest

    I can mass invite people to a muc on some remote server, spam them, and none know my jid

  58. pep.

    If someone wants to have many people joined they can already send invites

  59. moparisthebest

    (without looking into their server logs or XML console)

  60. Zash

    why you don't auto-accept invites from non-contacts

  61. moparisthebest


  62. pep. eyes Conversations

  63. moparisthebest

    But I bet clients exist that take affiliation change like "oh a change for a muc, oh I'm not in that muc, better join"

  64. moparisthebest

    Anyway a fun thing to test one day

  65. pep.

    Actually I doubt this specific feature is implemented much

  66. lovetox

    moparisthebest, i bet no client does anything on that message

  67. pep.

    "oh yeah another message with payloads I don't understand"

  68. lovetox

    its really a obscure feature, i dont even know which server supports it

  69. lovetox

    the chance is more likely that you break a client or surface a bug with that message

  70. lovetox

    because devs will not have accounted for that

  71. lovetox

    funny zash that article about fractal

  72. pep.

    I'm reading logs saying prosody 0.12 possibly does

  73. lovetox

    i went through the same thought process vs rooms and private chats

  74. Zash

    lovetox, it's been posted here before I'm sure :)

  75. lovetox

    the author cam to the conclusion they need to separate apps

  76. lovetox

    i think the "Workspace" feature does deal with that propblem rather well

  77. lovetox

    in Gajim for example

  78. Zash

    probably not even the first to come to that conclusion, but they blaged it and I have in it in my browser history

  79. Zash


  80. Zash

    lovetox, are you saying per-workspace setting for whether to auto-follow invites?

  81. lovetox

    what, no the article says, because they only have one side bar they dont want group chats and private chats fight for real estate

  82. lovetox

    and activity sorting is useless

  83. lovetox

    because mucs have much noise

  84. lovetox

    to their conclusion whas, make 2 apps, one focused on private chats, one on group chats

  85. lovetox

    while in Gajim we simply made workspaces, and now you can switch between your group chat workspace, and private worksapce

  86. lovetox

    and we dont need two apps

  87. Zash

    I mean that it makes more sense to auto-join when you get an invite from a contact in the private chat use case, while in a work team chat app might make less sense to follow invites by default

  88. pep.

    What was the saying again? You can solve any problem by adding one more abstraction layer?

  89. lovetox

    its exactly the opposite

  90. lovetox

    in a work env you need to follow all invites

  91. lovetox

    and thats als what MS Teams does

  92. lovetox

    i heard never complain anyone about it

  93. lovetox

    there is no spam in work env

  94. pep.

    It may be tricky to know it's a work env though and invites can be followed without worries? If people aren't in your contacts

  95. Zash

    either way, could it not make sense to have a setting per workspace then?

  96. lovetox

    yes im not saying the idea is bad, i just talked about completely other thing

  97. lovetox

    the problem is though

  98. Zash

    or should we just go back to the IRC way of having the server decide what channels you are in? :P

  99. lovetox

    a workspace in Gajim does not group contacts per see

  100. lovetox

    it just has open conversations

  101. lovetox

    i would say a account setting is better

  102. lovetox

    this is my work account, so accept all invites

  103. lovetox

    this is my private, so dont

  104. lovetox

    but i think the "contact is in my roster" is also good enough

  105. Maranda

    Oops wrong room

  106. Maranda

    Sorry 😅

  107. Maranda

    So having the registered FTTH SFP module inclusive of VLAN and PPPoE parameters and a thing with 12 SFP ports is there a reason to not just bypass the ISP CPE...? 🤔

  108. pep.

    Wrong message order?

  109. Zash

    Brought to you by eventual consistency?

  110. pep.

    fwiw, I figured out that <message/> affiliation update thing.

  111. pep.

    And I have an update coming for 463. > The introduction of a MUST on &MESSAGE; updates is necessary to ensure an observer (joined in the room) sees affiliation updates for offline users too, as these don't have any presence and thus their affiliation change wouldn't be broadcasted otherwise.

  112. pep.

    It's not meant to notify users outside the room

  113. pep.

    (Took me some time to figure out again)