#775 mod_throttle_presence breaks MUC joins

Reporter Ge0rG
Owner Nobody
Stars โ˜…โ˜…โ˜… (4)
  • Component-Community
  • Type-Defect
  • Status-WontFix
  • Priority-Medium
  1. Ge0rG on

    When running 0.10 with mod_csi and mod_throttle_presence, a CSI-inactive client can not reliably join MUCs, and the resulting stanza order violates XEP-0045. A client-side MUC implementation typically only waits a certain time for the MUC join presence from the MUC, eventually timing out (due to the fact that there is no guarantee that a MUC join will ever be responded to). mod_throttle_presence unfortunately buffers this presence stanza (as well as the presence from room participants), causing a client-side timeout. If mod_throttle_presence is deactivated, joins work reliably irregardless of CSI state. In theory, the MUC subject presence should cause the participants' presence to flush out. However, in practice this does not happen. What I have seen looks like this instead: >>> join presence <<< history <<< subject [client-side join timeout] [5 minute pause] <<< presence for existing participants <<< presence for the joining client <<< presence updates since join This is clearly in violation of XEP-0045 ยง7.2.3: "After sending the presence broadcast (and only after doing so), the service MAY then send discussion history, the room subject, live messages, presence updates, and other in-room traffic."

  2. Thilo Molitor (tmolitor) on

    Just use mod_csi_battery_saver, this module will not reorder presences while still delaying them until a high priority stanza is sent.

  3. Zash on

    • tags Component-Community
  4. Zash on

    This probably won't get fixed, this approached proved too problematic.

    • tags Status-WontFix

New comment

Not published. Used for spam prevention and optional update notifications.