jdev - 2024-04-02


  1. jonas’

    singpolyma, seems like we have a cheogram instance looping messages in prosody@.

  2. jonas’

    (you're involved with cheogram development, right?)

  3. singpolyma

    jonas’: a client you mean? Looping how?

  4. jonas’

    it repeats the same message over and over (with a <delay/> marker)

  5. jonas’

    posting more messages causes these to also be repeatet

  6. jonas’

    posting more messages causes these to also be repeated

  7. jonas’

    only seems to affect that one MUC, the same client in xmpp@ doesn't exhibit the behaviour

  8. singpolyma

    Can the user try doing clear conversation history on the prosody MUC?

  9. jonas’

    they can, if that's helpful

  10. singpolyma

    I don't know but I expect it might be

  11. jonas’

    you can directly talk to them in xmpp:xmpp@chat.yax.im?join, or let me know where they should join :)

  12. singpolyma

    I am muted there

  13. jonas’

    (not anymore)

  14. edhelas

    https://github.com/fabiang/sasl/releases/tag/v1.4.0

  15. edhelas

    Got the feature integrated in my lib :) !

  16. singpolyma

    Woo!

  17. nicoco

    Is there any mechanism to inform clients of changes in the affiliations of a MUC? Most clients do not display join/leaves by default, which is a good thing I think. But then you're never informed if someone is added to a private group, which is not great UX wise, especially when the participant lists are usually hidden from the client UI. Consider this: - I join a new private MUC I'm invited to - I look at the participants: A, B, C - I type "D is complete moron" - Before I hit Enter, D has been added to the participants and has joined, but I don't see anything in the "main chat view" of my client - D sees my message, which triggers WW3

  18. singpolyma

    Yes there is definitely some kind of notification when affiliations change

  19. nicoco

    Besides the joining presence of the new member?

  20. edhelas

    Movim is actually displaying those changes indeed, I find the feature kinda useful

  21. edhelas

    https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/clRs5G6qfNr4/image.png

  22. singpolyma

    Yeah. That's good

  23. singpolyma

    I think gajim does also

  24. singpolyma

    Or can

  25. nicoco

    no it does not: https://dev.gajim.org/gajim/gajim/-/merge_requests/1028 ;)

  26. nicoco

    edhelas: what "xmpp event" do you use for that?

  27. singpolyma

    It definitely used to 😂

  28. Zash

    https://xmpp.org/extensions/xep-0045.html#grantmember & https://xmpp.org/extensions/xep-0045.html#example-123

  29. edhelas

    Well just the affiliation changes somehow

  30. nicoco

    Zash: but this only works if the client actually joins the MUC after having their affiliation changed, doesn't it?

  31. Zash

    IIRC you can get those in messages too

  32. Zash

    Somewhere, deep in XEP-0045

  33. nicoco

    edhelas: my guess is that you fetch and cache the affiliation on joining a MUC, cache them, and when a participant joins, you check whether you know they were a participant or not. is that it?

  34. singpolyma

    nicoco: it's not related to joie

  35. singpolyma

    nicoco: it's not related to join

  36. rion

    Psi supports such notifications for decades. Probably some other old clients too

  37. Zash

    nicoco, https://xmpp.org/extensions/xep-0045.html#example-176

  38. nicoco

    Zash: that example looks relevant

  39. Zash

    also https://xmpp.org/extensions/xep-0045.html#example-195

  40. nicoco

    <x/item> in a <message> then, I wonder if clients really react to that, I'll check gajim.

  41. Daniel

    Conversations does. It's somewhat relavant for omemo as well.

  42. Daniel

    (maintaining an accurate and up to date list of who is actually in the room)

  43. Zash

    A sensible thing would be including such things in MAM

  44. Daniel

    So in your above scenario there wouldn't have been a status message but in an omemo enabled group Conversations would have asked the user to confirm that D is now in the group as well

  45. lovetox

    Zash: so prosody sends a unavailable presence when I change a affiliation of a user which is not joined, to all users of the MUC?

  46. lovetox

    Doubtful, a presence normally needs a resource, but as the user is not joined, what would that be?

  47. Zash

    I am not certain, not without reading the code

  48. singpolyma

    > A sensible thing would be including such things in MAM Maybe? Just so you can show when a change happened if you were out?

  49. Zash

    singpolyma, yes. Well, if you cache the presence-carried affiliations you can tell that, but when, ordering, reason messages etc

  50. singpolyma

    Sure

  51. Zash

    Sure would be a lot more useful to show than clients going offline and online again like https://logs.xmpp.org/jdev/2024-04-02?p=s

  52. singpolyma

    Yeah I think I will try adding aff change lines. Will show when someone is banned too which is useful

  53. nicoco_

    lovetox: Zash pointed to https://xmpp.org/extensions/xep-0045.html#example-176 which shows that affiliation changes can be part of a <message> too. If I read https://hg.prosody.im/trunk/file/tip/plugins/muc/muc.lib.lua#l1526 correctly, then prosody will emit those type of messages for affiliated that are not currently joined in the room.

  54. nicoco_

    lovetox: Zash pointed to https://xmpp.org/extensions/xep-0045.html#example-176 which shows that affiliation changes can be part of a <message> too. If I read https://hg.prosody.im/trunk/file/tip/plugins/muc/muc.lib.lua#l1526 correctly, then prosody will emit those type of messages for affiliated entities that are not currently joined in the room.

  55. nicoco_

    If we want archivable affiliation changes, I guess we could *always* send this type of message stanza with a <store> hint?

  56. lovetox

    on reason which is bad in the MUC XEP is in my opinion, that separation by "use cases"

  57. lovetox

    one reason which is bad in the MUC XEP is in my opinion, that separation by "use cases"

  58. lovetox

    thats one reason you dont often find the example and thing you are searching for

  59. lovetox

    for this particular case, it would be a fair interpretation of the XEP to assume on changing affiliation to "member" no messages must be sent. Because the relevant use case "Modifying the Member List" does not say anything about it

  60. singpolyma

    nicoco_: don't need the store hint if it's in the MUC mam

  61. singpolyma

    I agree the xep is big and could be organized a bit better

  62. lovetox

    i tested this on prosody and ejabberd, and both send the message for the affiliation change, luckily :)

  63. nicoco_

    Sending the affiliation change message for non-joined members is a MAY, doesn’t a SHOULD or even a MUST sound more reasonable?

  64. lovetox

    ? looking with todays knowledge onto a 20 year old spec, many things seem reasonable today, which they did not back then

  65. nicoco_

    Oh if prosody and ejabberd already do it, then it’s great 😊

  66. singpolyma

    Should send even if joined I'd expect? But some interpretations of SHOULD are very close to MUST so I think MAY is reasonable here

  67. lovetox

    there is no reason to send it when joined, because you receive the presence with the information

  68. singpolyma

    Hmm... I guess so?

  69. lovetox

    but if a user is not joined, you cannot send a presence, so they decided for a message

  70. Zash

    assuming all their resources are joined

  71. nicoco_

    Are there really cases where you’re joined as ‘none’ and then you become a member? This only only work for memberships in public groups, because if it’s private and you’re ‘none’ you can’t join anyway, or am I still misunderstanding something?

  72. singpolyma

    Means you need to check on presence if aff ir different than previous but I guess that's doable

  73. singpolyma

    nicoco_: yes, for public as you say

  74. singpolyma

    Private you can't be none

  75. lovetox

    > nicoco_: don't need the store hint if it's in the MUC mam dont understand that comment, its not in MUC mam because no body, not type chat

  76. singpolyma

    Surely that's up to the muc

  77. lovetox

    ah but hints are only for clients when they send something

  78. lovetox

    server does not need to add a hint for itself

  79. singpolyma

    Right

  80. lovetox

    yeah, i guess issing the message on any aff change, and adding it to the mam archive, will not break clients

  81. lovetox

    yeah, i guess issuing the message on any aff change, and adding it to the mam archive, will not break clients

  82. lovetox

    and would help that one case where a member was added while you were offline