XSF Discussion - 2018-11-18


  1. jonas’

    what the heck is the jabber:x:signed namespace?

  2. jonas’

    https://xmpp.org/extensions/xep-0027.html oh-kay

  3. jonas’

    so conversations does emit that on presences

  4. daniel

    That's how 27 works?!

  5. jonas’

    I didn’t even know about '27 until I saw that huge jabber:x:signed blob on a presence stanza

  6. Zash

    jonas’: thank glob for PEP

  7. Link Mauve

    Wasn’t it around the time of 0027 that PEP got invented?

  8. Link Mauve

    Because it was clearly getting out of hand.

  9. flow

    regarding xep198 'max': Smack throws away the session after min(max-client, max-server), to releaes resources because it assumes the session is no longer resumeable

  10. jonas’

    mmm

  11. jonas’

    I thought about that, but then I figured that the gain in resource consumption is most likely neglectible and giving the stream another chance might be worth it

  12. jonas’

    (also, I imagine servers might keep the ack counter around longer than max and return it on failed resumption which is nice)

  13. MattJ

    Yes

  14. Holger

    flow: Hmm, I guess I should no longer include the 'max' attribute with `<enabled/>`.

  15. jonas’

    the @max isn’t used in aioxmpp at all, actually.

  16. flow

    jonas’, right, the implementation is before xep198 had that ack counter

  17. flow

    I cleary see why would try oportunistic resumption in any case

  18. flow

    which leads to the question what the use case for 'max' actually is

  19. jonas’

    if you requested zero, you can check whether you got it

  20. jonas’

    if you ask why would anyone want that: https://github.com/horazont/aioxmpp/issues/114

  21. flow

    Most likely the use case for the client 'max' is to limit the duration of the ghost presence

  22. jonas’

    yes

  23. Holger

    But why check whether it worked?

  24. jonas’

    Holger, dunno? :)

  25. flow

    jonas’, I only had a quick look at #114, but doesn't the user simply want to disable resumption?

  26. jonas’

    flow, yes

  27. flow

    ahh wait, let me guess, the only way to disable resumption with <enable/> is max=0?

  28. jonas’

    :)

  29. jonas’

    actually, no

  30. flow

    max=-1? ;)

  31. jonas’

    > If the client wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false [5]. For information about resuming a previous session, see the Resumption section of this document.

  32. Holger

    resume='false', no?

  33. jonas’

    > If the client wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false [5]. For information about resuming a previous session, see the Resumption section of this document.

  34. Holger

    Right.

  35. flow

    phew, I thought I remember that the attribute exists, but a quick look at the example didn't reveal it

  36. jonas’

    in fact, aioxmpp makes resumption_timeout=0 and request_resumption=False equivalent

  37. jonas’

    flow, you need to look at Example 8

  38. jonas’

    the first one is for resumption-less SM

  39. flow

    so ok, and I guess it is also sensible that the server announces a his 'max'

  40. flow

    which means I may want to introduce a switch in smack to enable opportunistic resumption

  41. flow

    because Holger does dirty things

  42. daniel

    Do you not want to resume anyway just to get the h count?

  43. daniel

    Even if the time has run up

  44. flow

    daniel, it depends: if you want to minimize resource usage you may want to release the resources as soon as possible, if you want to get the 'h', then not. That is why I'm thinking about a switch to make the behavior configurable in Smack

  45. Ge0rG

    flow: and then there is the situation where the client clock is running differently from the server clock

  46. Zash

    Is https://xmpp.org/registrar/formtypes.html missing muc#roominfo or am I looking in the wrong place?

  47. jonas’

    you’re looking at an outdated page

  48. jonas’

    most likely

  49. Zash

    ... and why is there a menu at the top *and* at the bottom of https://xmpp.org/ ?

  50. Zash

    And how do you find the registry in this piece of marketing material?

  51. jonas’

    you are at the right place for the registry

  52. jonas’

    unfortunately, it’s not being maintained

  53. Zash

    :<

  54. jonas’

    yes

  55. jonas’

    https://github.com/xsf/registrar this is the source

  56. Zash

    Please use your own neural network to synthesize my reaction to this.

  57. Zash

    Anyways, the answer to my question is "no, there's no field for a web chat URL registered already"

  58. Ge0rG

    And I'm not convinced there needs to be