XSF Discussion - 2019-07-31


  1. jonas’

    I lack context

  2. Link Mauve

    jonas’, look up “420 blaze it”.

  3. jonas’

    do I want to at work?

  4. Link Mauve

    For science.

  5. jonas’

    I take that as a "heck no"

  6. flow

    420 implement it!

  7. Ge0rG

    flow, Guus: could you reconfigure the ignite discourse to not auto-close threads after three months?

  8. Guus

    Ge0rG: would you mind asking for that in that discourse, for the relevant people to be involved?

  9. Guus

    Fwiw, I don't have a preference

  10. Ge0rG

    Guus: does it have a "meta" tag?

  11. Ge0rG

    I've only posted "smack" issues so far :

  12. Ge0rG

    :>

  13. Ge0rG

    Guus: thanks, posted as https://discourse.igniterealtime.org/t/please-disable-auto-closing-of-threads-after-3-months/85765

  14. LNJ

    Could someone regenerate the website, https://xmpp.org/extensions/ is outdated.

  15. Ge0rG

    LNJ: it _should_ get auto-generated, with ~2 hours of delay, so probably something broke.

  16. jubalh

    who is writing the xmpp newsletter thingy? :)

  17. pep.

    commteam@muc.xmpp.org

  18. pep.

    There's also a wiki page you can edit if you want things to appear in the next one

  19. jubalh

    yep thats my goal

  20. jubalh

    however if writing to the team also does the same. maybe I'll prefer this :)

  21. jubalh

    thansk pep. I see the wiki link in the topic of that channel

  22. pep.

    They usually redirect you to the wiki because they can't remember everything people wanted to put in (which is fair enough) :)

  23. jonas’

    Ge0rG, the extension list is not coupled to the other generation process, it needs to be triggered manually

  24. jonas’

    someone with power (Guus maybe?) needs to kick the docker build job

  25. Guus

    I just did.

  26. Guus

    xsf/xeps was last built 19 hours ago

  27. Guus

    seemed to have been successful

  28. Guus

    I just kicked off a new build manually.

  29. jonas’

    Guus, maybe a race condition then

  30. jonas’

    thanks

  31. Ge0rG

    ah!

  32. Guus

    There's a webhook on that dockerhub build that I don't recognize: https://api.hub.sotecware.net

  33. Guus

    ah, Google reveals a likely culprit 🙂

  34. Guus

    the webhook has been failing for months though.

  35. jonas’

    Guus, that’s me

  36. jonas’

    the webhook is mine, and should be irrelevant

  37. jonas’

    I wanted to set something up which could do things when new XEPs are published

  38. jonas’

    but I didn’t get around to do it

  39. jonas’

    (sotecware.net is my domain)

  40. Guus

    sure, no problem.

  41. Guus

    my browser gives a security warning on that URL btw

  42. Guus

    cert probably outdated or not matching the domain or something.

  43. jonas’

    yeah

  44. jonas’

    I didn’t bother with maintaining that domain after I didn’t bother to write code for it ;)

  45. Guus

    I'll not bother bothering then 🙂

  46. Ge0rG

    it used to be sotecware, but now it's abandonware

  47. jonas’

    :P

  48. Guus

    > someone with power (Guus maybe?) needs to kick the docker build job @jonas` FWIW, I think you have the power too.

  49. Guus

    > someone with power (Guus maybe?) needs to kick the docker build job @jonas’ FWIW, I think you have the power too.

  50. jonas’

    Guus, yes, but I don’t have my credentials on my work machine :)

  51. Guus

    hey, Converse is having trouble doing the mention.

  52. Guus

    ah, k.

  53. edhelas

    in https://xmpp.org/extensions/xep-0060.html#entity-discoveritems, where is the definition of the "jid" attributes of items

  54. Link Mauve

    edhelas, in XEP-0030, disco#items.

  55. edhelas

    fair enough

  56. pep.

    The day disco+rsm is a thing, or featureX+rsm is a thing, if in the disco#info I get I see MAM, featureX, rsm, how do I know what I can do? Do we need a different NS per combination?

  57. Ge0rG

    Add sub elements to the feature element!

  58. pep.

    Is there such cases currently where it can be confusing?

  59. Kev

    Advertising RSM on its own doesn't really make any sense.

  60. Kev

    RSM-for-Disco does, or RSM-for-MAM (which is really ust MAM, as MAM requires it).

  61. Kev

    RSM-for-Disco does, or RSM-for-MAM (which is really ust MAM, as MAM requires it).

  62. Kev

    RSM-for-Disco does, or RSM-for-MAM (which is really just MAM, as MAM requires it).

  63. pep.

    I agree

  64. pep.

    Has this already been discussed somewhere? Something like Ge0rG said doesn't sound too bad :x

  65. Ge0rG

    RSM for president!

  66. pep.

    There could also be order-by, 413 :)

  67. flow

    Should a service even announce disco-with-rsm support? Wouldn't it be sufficient if the requesting entity would include i-can-do-disco-with-rsm flag into its disco request?

  68. pep.

    So you'd include rsm when requesting, and then?

  69. flow

    if the server supports it and the result set is large enough he will make use of it

  70. flow

    (that assumes we have defined, together with the i-understand-disco-responses-with-rsm flag, the semantic how that should exactly look like)

  71. flow

    right now the only reason I can come up with why a disco responser should announce that he supports rsm is to track how widespread the support is

  72. pep.

    OK, that's fine for rsm, now say order-by+disco is a thing

  73. flow

    brrrr

  74. pep.

    I need to have guarantees that the result is ordered

  75. Ge0rG

    We are speaking of disco#items only, right?

  76. pep.

    Ge0rG: yeah

  77. flow

    I don't want to go down that road right now. I would be happy if we had a solution to page through large disco result sets, like if you have a loooooot of pubsub nodes, using RSM

  78. Ge0rG

    I'm actually looking for disco+search

  79. flow

    Ge0rG, well there is nothing that prevents disco#info result from becoming too large for a single stanza (whatever "too large" is)

  80. pep.

    Lots of pubsub nodes is already a thing, edhelas says with comments the disco results easily becomes bloated

  81. pep.

    Lots of pubsub nodes is already a thing, edhelas says with comments disco results easily become bloated

  82. pep.

    That's one reason why disco+rsm would be desirable

  83. Ge0rG

    flow: but how are you going to split a single #info?

  84. pep.

    What does the disco#items look like on conference.jabber.org?

  85. flow

    Ge0rG, cut in half? But yes, the issue is more pressing for disco#items

  86. flow

    that is why I would start with that and get some implementations experience

  87. pep.

    Ge0rG: order-by might be something you want? You add a new condition "number of participants" for example :p

  88. flow

    Note that mongoose's muc light uses RSM with disco#item: https://mongooseim.readthedocs.io/en/latest/open-extensions/muc_light/

  89. flow

    but I am not sure if the way they describe it is the way I would do it

  90. Ge0rG

    pep.: disco#items doesn't even contain that number, so you end up doing disco#info on each individual node. Last time I did it from yaxim, it took two hours.

  91. pep.

    Ge0rG: have you read order-by?

  92. Ge0rG

    And the result wasn't really worth it

  93. pep.

    It would be too far-fetched to add that to disco#items

  94. Ge0rG

    Yeah, jonas’ just needs to XEPize the MUC search protocol.

  95. pep.

    And then you could do what you're asking for, (and with rsm)

  96. pep.

    I think it's doable with the more or less generic bricks we have

  97. pep.

    I wouldn't create yet another xep

  98. Ge0rG

    pep.: I'm looking for a certain subset of all disco#info results embedded into the domain's disco#items

  99. pep.

    Sure

  100. pep.

    Create another condition for the order tag, by='number-of-participants' or sth, and let the server do the work, they already have all that info

  101. Ge0rG

    That was the easy step. The hard one is: deploy to jabber.org

  102. MattJ

    Don't underestimate the power of a moving glacier!

  103. Zash

    Even the earth itself can't handle the pressure!

  104. Link Mauve

    Let’s just wait for it to be done melting, I’ve heard heat waves are going strong lately.

  105. Ge0rG

    Link Mauve: this year, Greenland will melt enough ice for a 0.68mm sea level rise.

  106. pep.

    so.. <feature var="urn:xmpp:order-by:0"><feature var="http://jabber.org/protocol/disco#items" /></feature> this would do it?

  107. pep.

    (Or rsm instead of order-by)

  108. pep.

    Ge0rG: you haven't heard the news, that's a Chinese hoax

  109. Ge0rG

    pep.: global warming?

  110. pep.

    Of course

  111. Ge0rG

    pep.: you swapped the namespaces. order-by is an option of disco#items, not vice versa

  112. pep.

    OK sure, I don't care which way as long as we talk the same :)

  113. Ge0rG

    It's not very elegant, and I'm not sure how far it's supported by anyone, but it's the most logical syntax

  114. Link Mauve

    It’s also not allowed by the schema, and will fail parsing in most parsers.

  115. pep.

    I find it elegant enough :/

  116. pep.

    Err

  117. flow

    hmm I don't like child elements in <feature/>

  118. flow

    partly due the reasons Link Mauve mentioned

  119. pep.

    What alternative is there?

  120. pep.

    Declare new NSs for these combinations?

  121. Link Mauve

    pep., for instance, a feature var='disco#info-with-order-by'.

  122. pep.

    Right :/

  123. Link Mauve

    It’s not a namespace, it’s a feature.

  124. pep.

    Yeah ok

  125. Ge0rG

    Add a comma separated list into the var, because why would you use xml syntax for it?

  126. edhelas

    JSON

  127. Ge0rG

    edhelas: thanks, I forgot.

  128. Ge0rG

    But then we rather should use DER.

  129. jonas’

    no that’d make zinid happy

  130. Zash

    CBOR is the future!

  131. edhelas

    jonas’ because you know how to make zinid happy ? 🤔

  132. jonas’

    edhelas, he *does* like ASN.1

  133. ralphm

    hehe