jdev - 2024-01-01


  1. nicoco

    Happy new year, love, success, whatever, blah blah blah, but more importantly… In https://xmpp.org/extensions/xep-0045.html#example-202 aren't the example presences missing a `<status code="110"/>`? This is after room destruction, the service is supposed to send to each occupant a presence type="unavailable", participant=none, role=none.

  2. MattJ

    Yes, I think so

  3. nicoco

    Thanks MattJ. I guess for extra modernness they will also have an `<occupant-id>` but that one's not mandatory

  4. wgreenhouse

    is there any reason why a particular server's MUC component would not return presence from each occupant when a client joins and probes presence?

  5. wgreenhouse

    there's one particular prosody installation that behaves this way for me. I even have an account on the server and am an admin of one of the MUCs showing the behavior

  6. singpolyma

    It should just on join without probe

  7. wgreenhouse

    I wonder what's happeninh

  8. wgreenhouse

    I wonder what's happening

  9. singpolyma

    Does it think your fulljid is already joined?

  10. wgreenhouse

    I am usually present on two clients; different fulljid ofc because resource part differs

  11. singpolyma

    Right, that's fine but if it thinks this fulljid is already there it would behave as you say

  12. wgreenhouse

    hmm.

  13. wgreenhouse

    disconnecting everybody and reconnecting fron a heretofore-unseen resource didn't help

  14. wgreenhouse

    one client still doesn't get presence from most of the MUC

  15. wgreenhouse

    hmm. xmlconsole in jabber.el shows it gets unavailable presence on join from most members of the channel

  16. wgreenhouse

    only for MUCs of this one server

  17. singpolyma

    So you get available from some members unavailable from others and then your 110?

  18. wgreenhouse

    singpolyma: the long block of unavailables always seems to be first

  19. wgreenhouse

    but yes

  20. wgreenhouse

    then thereafter I do get normal presence changes, so over time the occupant list eventually has almost everybody

  21. singpolyma

    Prosody version?

  22. wgreenhouse

    singpolyma: "0.12 nightly build 204 (2023-05-31, 332e95f75dbb)"

  23. wgreenhouse

    ok, inexplicable wrinkle: joining same MUC from my other account gets correct initial presences from the MUC

  24. singpolyma

    Other account on different server?

  25. wgreenhouse

    yes, running ejabberd on debian stable

  26. singpolyma

    So maybe some internal optimization biting you when both on same server

  27. wgreenhouse

    yes, possibly

  28. wgreenhouse

    and an internal optimization that cheogram android copes with and jabber.el doesn't

  29. MattJ

    I'd be inclined to suspect server configuration, e.g. if it has mod_throttle_presence enabled or something like that