jdev - 2020-01-21

  1. lovetox

    rfc says https://tools.ietf.org/html/rfc6120#section-4.4 when closing a stream the side that closes has to wait for a closing in return

  2. lovetox

    but does that make sense in the case of a stream error?

  3. lovetox

    i get if i close the stream normally i want to give the other side the oppurtunity to send everything out it was going to send

  4. lovetox

    but in the case of a stream error, i will ignore anything anyway

  5. MattJ

    lovetox: if you'll ignore then yes. But does the RFC even allow clients to send stream errors?

  6. lovetox

    yes MattJ why not

  7. flow

    lovetox, why do you have to ignroe any inbound stanzas on stream errors?

  8. lovetox

    if i receive not well formed xml from the server

  9. lovetox

    and end the stream with a stream error

  10. lovetox

    why or how would it make sense to wait for more xml from the server?

  11. lovetox

    stream errors are not recoverable, means to me, all xml parsing ends right there

  12. flow

    ok, but thinking about the generic case, not the specific case where you can't recover from an ill formed xml stream

  13. flow

    nothing forces you to not wait for the other side to close the stream and continue processing inbound stanzas

  14. lovetox

    nothing forces me, but then i would ignore the "unrecoverable" rule for stream errors

  15. lovetox

    as i would still wait and parse inbound stanzas even after an stream error

  16. flow

    I think the rule leaves room for interpretation

  17. lovetox

    that was not my question, if i *could* do it

  18. lovetox

    may question was does it make sense

  19. lovetox

    is there a case where i want data from the server even after he violated basic rules of a stream

  20. flow

    If you can process the data, then I don't see and advantage by not doing it

  21. flow

    *an advantage

  22. flow

    If you can process the data, then I don't see an advantage by not doing it

  23. flow hast to learn how poezio does autocorrect

  24. lovetox

    but there is no stream error other than malformed xml ones

  25. lovetox

    that client could send

  26. lovetox

    most stream errors are related to server actions

  27. lovetox

    like conflict, host-gone, not-authorized

  28. lovetox


  29. lovetox

    but yeah from the examples, i think its expected to send a close stream back even on error

  30. lovetox

    maybe malformed-xml is the exception where it really makes no sense

  31. flow

    What about errors on the layer above xml, like using XML mixed content, which is allowed by XML but disallowed in XMPP

  32. pep.

    flow, /correct

  33. flow

    pep., and then I have to type the whole message again? Or is the idea that I select the message from the history, prefix it with '/correct', then correct it and hit enter?

  34. pep.

    /correct <tab>

  35. pep.

    Then you can edit and resend

  36. pep.

    But you can also /correct anothermessageinstead

  37. flow


  38. flow


  39. flow


  40. pep.

    And poezio doesn't yet implement the LMC "clarification"

  41. flow

    the "strike the last" from LMC?

  42. pep.

    no, the "always use the first id"

  43. pep.

    Otherwise yes in reading we do "Message Correction", not Last Message Correction.

  44. pep.

    We only send the last via /correct, but you can do /rawxml :x

  45. lovetox

    another problem, say i send close stream

  46. lovetox

    and the server answers with more stanzas because i let him like the XEP suggests

  47. lovetox

    i cant ack these messages anmore via streammanagement

  48. lovetox

    so the server will think i didnt get those messages

  49. lovetox


  50. MattJ

    You can if you resume

  51. lovetox

    does close stream not mean i cant resume?

  52. MattJ

    Oh, right :)

  53. MattJ


  54. lovetox

    i think it causes more complexity and problems if after stream close, i wait for a stream close in return or any other stanza

  55. lovetox

    i dont see any benefit for client or server

  56. jonas’

    lovetox, the stanzas could still have been in flight

  57. jonas’

    if your link has latency

  58. jonas’

    you need some way to deal with this, even though "drop everything and log errors" may be a valid way

  59. Zash

    Resource-*un*-binding before /stream?

  60. jonas’

    you still have to deal with stanzas which are in-flight when you send your unbind

  61. jonas’

    same difference

  62. Zash

    send un-bind, maybe receive stanzas, receive unbind-ack, send /stream, receive /stream

  63. jonas’

    how’s that different from send /stream, maybe receive stanzas, receive /stream?

  64. Zash

    you can maybe send sm:a?

  65. jonas’

    ah, that

  66. jonas’


  67. Zash

    more roundtrips!

  68. Zash

    gotta add some after removing from the start

  69. flow

    Zash, I thought about that too, sure adds complexitly, which always opens up the discussion if its worth it

  70. Zash

    probably not

  71. flow

    Zash, I thought about that too, sure adds complexitly, which always opens up the discussion if it's worth it

  72. Zash

    can get Close Enough ™ with unavailable presence I guess

  73. flow

    yeah, but nice to think about it

  74. leosbrf

    Hi all, when an user join a private room, I don't want him to have access to previous messages, only new messages. Is there a way I can accomplish that?

  75. Zash

    Yes, this can be implemented

  76. Zash

    Not aware of any publicly available such implementations tho

  77. leosbrf

    Thank you, Zash. So I would have to write a module for this? I'm new to XMPP and currently I'm using ejabberd. Could you give me some references on how to get started on that?

  78. leosbrf

    links with docs or tutorials, besides ejabberd website itself, if any.

  79. Zash

    I can't do better than your favorite search engine I'm afraid

  80. leosbrf

    no problem, thanks anyway

  81. flow

    leosbrf, you may also want to ask this in the official ejabberd muc

  82. marc0s

    hi, is there some XEP or part of Core that defines capabilities for registered accounts? something like userA cannot make use of the MAM or Carbons, for instance? Something like different kind of accounts with different sets of permissions

  83. Ge0rG

    marc0s: that sounds like a policy configuration, not a protocol. What would you write down in the xep?

  84. marc0s

    Ge0rG, that sounds right, indeed. Maybe I'd like to have a way to query that policy. We've been asked for some weird (IMHO) requirement where some kind of accounts would only be allowed to receive messages, not sending them, but at the same time, senders should be aware of the recipient will not be able to answer because of that policy. I was just wondering if something already existed for that before inventing our own (basically doing that check out of band)

  85. Ge0rG

    marc0s: you might be able to appropriate https://xmpp.org/extensions/xep-0317.html (Hats) or https://xmpp.org/extensions/xep-0310.html Presence State Annotations

  86. Ge0rG

    but I'm sure there is no in-the-wild client support for either

  87. marc0s

    thanks Ge0rG. Client support is not an issue, we're rolling our own, based on stanzajs. Will have a look at that XEPs

  88. lovetox

    em, disco info comes to mind?

  89. lovetox

    but instead of routing it to the users, let the server answer with the caps for this account

  90. lovetox

    so a little server addon :)

  91. moparisthebest

    A: "can you send messages" B: "no but since I can't send messages I can't reply" A: *still waiting for response*

  92. marc0s

    lovetox, yes, disco can be another way of solving this. Actually the XEP states than when querying a bare jid, it's the server who should answer, if I didn't misread it... so maybe yes, that's something a module can solve

  93. marc0s

    moparisthebest, :D