XSF Discussion - 2021-03-01


  1. ralphm

    Zash: which one, avatar presence from the room, or the room sending unavailable when you leave?

  2. Ge0rG

    If you have room presence, can you switch the room to DnD then?

  3. ralphm

    Sure, but maybe a bit silly.

  4. ralphm

    The thing is, if anything sent you (available) presence for whatever reason, it makes sense to send unavailable once you are no longer 'subscribed'.

  5. Ge0rG

    ralphm: that's a good point. From a protocol point of view, it probably makes sense to have it behave symmetrically. However, given that you receive presence-unavailable from your occupant JID, another presence-unavailable from the bare JID might be superfluous

  6. ralphm

    Not really. Strictly speaking there are two different entities represented by the bare JID (room) and the full JID (your presence in said room). Of course the model is odd and we'd be much better off having this properly specified from scratch (hello MIX).

  7. ralphm

    (I understand that if you take my point to the extreme, a room would have to send unavailable for all occupants and one might say that the bare JID should be assumed to also be unavailable, but sending the unavailable from the room is just a bit more explicit)

  8. Kev

    This is somewhat complicated by bare JID unavailable having a special meaning.

  9. Kev

    (Which is that all resources are also unavailable)

  10. Kev

    So, basically, overloading a room’s bare JID presence is icky and bad and wrong.

  11. jonas’

    to be fair, all resource overloading in MUC is icky and bad and wrong if you look at it too closely

  12. Kev

    Where ‘too closely’ is anything in the same solar system. And possibly beyond.

  13. Kev

    But using bare JID is especially bad, even by normal MUC standards.

  14. jonas’

    Kev, good thing that this use of the bare JID is not standardised then ;)

  15. ralphm

    Kev: while I mostly agree, what is the bad effect of having a bare JID unavailable being sent after you left the room?

  16. ralphm

    Also, is the special meaning you mention actually in a spec?

  17. ralphm

    The only thing I could find was https://xmpp.org/rfcs/rfc6121.html#presence-unavailable-client, but that specifically is about contacts.

  18. Ge0rG

    Kev: well, sending presence-unavailable from the room JID to a leaving client will ensure resource cleanup even on servers that don't track their users' MUC presence, right?

  19. Kev

    Ralph: Yes, but at the same time, it doesn’t say the sender has to be a contact of the receiver, merely that the receiver must treat bare JID unavailable as applying to all resources. Just that the receiver be a contact of the sender.

  20. Kev

    Ge0rG: Servers must track their users’ MUC presence, no?

  21. Ge0rG

    Kev: yes and no. They must track outgoing presence, but that doesn't mean they need to follow nickname changes, whether originated from the client or from the MUC

  22. Ge0rG

    And they don't have to follow "MUC occupancy" but rather "outgoing directed presence", so it's not quite the same thing

  23. Kev

    Oh, yes, nickname changes are completely broken.

  24. Ge0rG

    I wouldn't go that far.

  25. dream chaser

    Hello, please i was looking for a particular seller group, i dont know how to navigate my way, please can someone help me

  26. mathieui

    what is a seller group?

  27. dream chaser

    wellsfargo@exploit.im

  28. dream chaser

    wells.support@zloy.im

  29. dream chaser

    Any of them

  30. mathieui

    I still don’t know what is a seller group

  31. purplebeetroot

    Exploits

  32. Ge0rG

    that looks very much like people facilitating identity theft, something illegal in most countries.

  33. purplebeetroot

    just ban and report to admin.

  34. dream chaser

    the group is banned?

  35. mdosch

    MattJ, Kev, ralphm ^

  36. mdosch

    Time for the Bannhammaren.

  37. ralphm

    dream chaser: The primary topic of this room is discussion on XMPP protocols and/or XMPP Standards Foundation matters. The addresses you listed appear to be malicious actors and we're not associated with anything you mentioned.