XSF Discussion - 2018-04-15


  1. pep.

    Ge0rG, re MUC self-ping/removal of gc1, that won't fix clients that don't show presence? like Conversations. But there's not much we can do for that I suppose.

  2. jonasw

    what does showing presence have to do with removal of GC1?

  3. pep.

    One of the goals was to let the user know they've lost the connection to the room and their are not silently being reconnected to it, with possibly history loss in between

  4. pep.

    *they are not

  5. jonasw

    yes

  6. jonasw

    conversations *does* show when you get removed from a room

  7. jonasw

    (it shows a "You are no longer in this room [Join]" blob at the bottom of the message view)

  8. pep.

    well but if it self-pings, and then reconnects to it, you'll be reconnected in the end

  9. jonasw

    yes

  10. jonasw

    so?

  11. jonasw

    ahh

  12. pep.

    So it needs a way to clearly show the break

  13. jonasw

    no, the point is that the reconnect is well-defined

  14. jonasw

    it can easily do that

  15. jonasw

    it would request history since the last message it got and/or MAM

  16. pep.

    yes but that might not cover all messages

  17. jonasw

    adding a marker in there that messages might’ve been lost due to server issues would be trivial, I presume

  18. pep.

    ok

  19. jonasw

    but again this has nothing to do with showing presence

  20. pep.

    well kind of, I mean poezio doesn't have much to do about this self-ping thing, I see part/joins already, and I already get errors displayed

  21. jonasw

    it has to do a lot about it

  22. jonasw

    or it already odes

  23. pep.

    There is self-ping already

  24. jonasw

    what happens with poezio without self-ping is that the next message you send to the MUC is just not sent

  25. pep.

    Maybe not exactly the same that Ge0rG wants?

  26. jonasw

    and you have to realize that yourself and /cycle

  27. jonasw

    yeah, the self-ping of poezio has the issue (which poezio can’t do anything about) that it might end up at another resource of yours which cannot reply, thus timing out, thus cycling you unnecessarily

  28. pep.

    or latency, and unnecessary cycling :(

  29. Kev

    Ping timeout doesn't matter, does it? It's not until you start getting errors that you need to cycle.

  30. jonasw

    Kev, if the s2s link is broken badly you’ll also want to let the user know.

  31. jonasw

    which is generally a timeout condition. also, you’ll probably have to re-join, so you need to cycle

  32. Kev

    If the s2s link is broken badly, you get a ping response.

  33. Kev

    And there's no point rejoining while it's down.

  34. Kev

    So I think the right thing is to only cycle on an error.

  35. Kev

    You can warn the user on a slow response, but leave them 'in' the room.

  36. jonasw

    hm

  37. jonasw

    I’m confused

  38. jonasw

    if the s2slink is broken badly, you don’t get a response, at all

  39. Kev

    If it's 'broken', you get remote not found.

  40. jonasw

    with badly, I mean it’s blackholed and waiting for a two days TCP timeout or The Prosody Bug or something like that

  41. Kev

    If it's up but blackholing, you get no response.

  42. Kev

    In that state, cycling achieves nothing.

  43. jonasw

    what else would you do though?

  44. jonasw

    start cycling until you’re back in

  45. Kev

    Nothing.

  46. Kev

    Wait until you get an error to cycle.

  47. jonasw

    so you continue to ping

  48. Kev

    Yes.

  49. jonasw

    hm

  50. Kev

    Avoids the 'sent to a disconnected resource that isn't you' issue too.

  51. jonasw

    the advantage being that (a) you don’t get dropped out by other clients getting your IQ and not being able to reply and (b) if the s2slink actually has stream management or something fancy you don’t lose anything

  52. Kev

    The disadvantage of all this is that if you're in a MUC that doesn't allow IQ, you're going to be perpetually cycling.

  53. Maranda

    MUC that doesn't allow IQ?

  54. Maranda attempts to picture the case in his mind.

  55. Kev

    Some MUCs disallow all PM traffic.

  56. Kev

    Because it'd be a nuisance, e.g. getting arbitrary file transfer requests or whathaveyou.

  57. jonasw

    is it specified what type of error such a MUC returns?

  58. Maranda

    service-unavailable me thinks?

  59. jonasw

    service-unavailable would be treated as success by MUC-self-ping implementations ala Ge0rG

  60. Maranda

    but I vaguely recalls forbidden too

  61. Maranda

    also that ping implementations should treat all errors as *success*

  62. jonasw

    Maranda, no

  63. jonasw

    not-allowed is supposedly returned if you’re not joined

  64. Maranda

    are we talking about the keepalive pings or something else?

  65. Maranda

    oh

  66. Maranda

    nm

  67. Maranda

    because for mod_s2s_keepalive or whatever it was called as long as a IQ reply is returned it shouldn't matter.

  68. jonasw

    yeah, that’s not the topic though

  69. Maranda

    but if it's about being into the room

  70. Maranda

    on a slightly different topic is poezio the only *still in development* thing using GC1.0?

  71. jonasw

    I’m pretty sure that poezio doesn’t use GC1.0

  72. Zash

    Nothing uses GC 1.0

  73. jonasw

    yeah, it doesn’t, Maranda

  74. Zash

    Only thing we found that did was the prosody web chat, and it's been fixed.

  75. Maranda

    I'm not sure why I remember a talk about sending presences without x

  76. Maranda

    I'm not sure why I remember a talk about it sending presences without x

  77. Maranda

    for joins

  78. Maranda

    ah well

  79. Maranda

    all the GC1.0 junk is covered anyways

  80. Maranda

    (now at least)

  81. Maranda

    Zash, hmm so the data Link Mauve and Ge0rG got about GC1.0 were about the web chat only?

  82. Zash

    Huh?

  83. Maranda

    they collected statistics about GC1.0 joins

  84. Maranda

    You said "that the only thing we found was the prosody web chat"

  85. Zash

    I collected some stats from conference.prosody.im

  86. Maranda

    Oh ok.

  87. Ge0rG

    Kev: will rooms that forbid PMs also forbid IQs?

  88. Steve Kille

    IQ seems a lower level thing, which should not have control coupled to PMs

  89. Ge0rG

    I'm pretty sure one of the XSF MUCs disallowed PMs in the past, but self-ping did work

  90. Maranda

    Ge0rG, you mean jdev@conference.jabber.org that's the only one that comes to mind.

  91. Maranda is tempted to tinker with 363

  92. Ge0rG

    Maranda: well possible.

  93. Kev

    Ge0rG: Depends. But if PMs are disabled for not getting spammed reasons, blocking IQs makes sense too, because file transfer, Jingle call, etc.

  94. Ge0rG

    Kev: I'm looking for answers from real implementations