jdev - 2020-10-08

  1. lovetox

    can disco#items use rsm?

  2. lovetox

    is this its own XEP?

  3. lovetox

    if yes i dont find it

  4. lovetox

    ah its in 0059 described

  5. flow

    lovetox, its underspecified

  6. lovetox

    what part exactly flow?

  7. Zash

    Hmmmm, there's https://xmpp.org/extensions/xep-0059.html#examples

  8. lovetox

    Zash does prosody support that?

  9. Zash


  10. flow

    lovetox, looks like I was wrong. I remebered the interaction with xep30 and xep59 to be underspecified, but that disco#items case (and the example) look straight forward

  11. lovetox

    question is how to discover that a server supports rsm on disco items

  12. lovetox

    because if i send a disco#items to conference.jabber.org with a rsm page size of say 50

  13. lovetox

    i get ddos with 18000 items

  14. lovetox

    because it does not support rsm ^

  15. pep.

    lovetox, I think edhelas is interested in disco + rsm

  16. pep.

    because apparently (pubsub) comment nodes are also huge

  17. pep.

    or something

  18. flow

    lovetox, do you need to discover support for disco#info+rsm?

  19. jonas’

    please don’t implement disco#items+rsm, I don’t want to (have to do it in the s.j.n code) :D

  20. flow

    it appears to me the idea behind xep59 § 3 is that you do it opportunistically

  21. Zash

    Wouldn't it be opt-in?

  22. flow

    Zash, how could it be not opt-in?

  23. Zash

    send <{disco#items}query><{rsm}set/></query>

  24. Zash

    as per the example

  25. lovetox

    flow yes see my example above

  26. flow

    right, I don't think you can do it any other way?

  27. lovetox

    otherwise you get DDoS

  28. Zash

    so if you don't, either you get everything or a truncated result if the server really doesn't want to send everything

  29. flow

    lovetox, but what is your plan b?

  30. flow

    first you need to know that the result set is very large

  31. flow

    which you may or may not a priori

  32. flow

    which you may or may not know a priori

  33. lovetox

    plan b is not query disco#items

  34. flow

    so you tell your users, sorry can't list

  35. lovetox


  36. lovetox

    either server advertises it, or i dont display a list

  37. lovetox

    that was my idea

  38. flow

    I mean I think there no reason that we don't recommend services to announce that they support disco#info+rsm

  39. flow

    (of course we would have a discussion wether or note this announcement is recommended or required)

  40. flow

    (of course we would have a discussion whether or note this announcement is recommended or required)

  41. Zash

    There's no specific feature or pattern for this already tho?

  42. flow

    Zash, pattern?

  43. Zash

    flow: eg writing "to announce support for disco+rsm, add <feature var=http:etc/disco#info+rsm}"

  44. Zash


  45. flow

    Zash, yes that is what I had in mind, and I don't think we have that (yet)

  46. flow

    hmm I have a private disco-rsm branch in my xeps/ repo

  47. flow

    and I am pretty sure this was discussed before

  48. Zash

    flow: or rather, "to announce foo + rsm support, concantenate the feature with "+rsm" and announce that"~

  49. Zash

    that'd be a pattern

  50. flow

    ahh yes, but at least for some foo+rsm you'd probably need to clarify in foo's xep how it would interact with rsm

  51. pep.

    fwiw I think this discussion also popped up when I added pubsub#rsm. And I don't know if I did remove the standalone rsm in disco (which doesn't make sense)

  52. lovetox

    it would really be nice if i could query my own servers MUC list in a good way

  53. lovetox

    i implement the interface to muclumbus but for mall company servers for example, it would be better to just disco#items

  54. Zash

    What if you had the muclumbus xmpp protocol to your local MUC?

  55. pep.

    Do we also need a similar system for say pubsub nodes, etc.

  56. lovetox

    Zash would be fine, though a bit too much for my taste

  57. lovetox

    hm Zash, no would be fine

  58. lovetox

    lets make a XEP out of it :)

  59. Zash

    Like https://xmpp.org/extensions/xep-0433.html

  60. lovetox

    i wonder why we not just used jabber search

  61. lovetox


  62. lovetox

    i see not much difference

  63. lovetox

    or non at all

  64. lovetox

    except some error are defined

  65. lovetox

    but yeah Zash would be a nice addition in prosody :)

  66. Zash

    Does anyone implement this dataform thing: https://xmpp.org/extensions/xep-0055.html#example-9

  67. lovetox

    yes gajim i think

  68. lovetox

    in the service discovery browser

  69. Zash


  70. lovetox


  71. lovetox

    at least the last time i looked

  72. pep.

    lovetox, https://xmpp.org/extensions/xep-0433.html#design re jabber search

  73. lovetox

    i know only one server that has a user directory

  74. Kev


  75. Kev

    (Sorry, silly beta client, again) Zash: Yes, Swift and M-Link both do the data forms for that, unless I'm going mad.

  76. Kev

    (I can check in the morning for you if you want)

  77. Zash

    Kev: But including the <reported> stuff? I don't think I've ever seen that in action. Prosody doesn't support that part.

  78. Kev

    Oh. Uhm.

  79. lovetox

    Zash, without the reported its invalid

  80. lovetox

    the fields are encapsulated by <item>

  81. Kev

    Looks like Swift understands reported, at a glance.

  82. lovetox

    and you only have this in reported data forms

  83. lovetox

    thats not jabber search syntax

  84. lovetox

    thats XEP0004

  85. Kev

    Yep, M-Link also sends reported for xep55 as far as I can see (without doing much research).

  86. eta

    Kev: what beta client is this?

  87. Kev

    A heavy rework of Swift we're experimenting with.

  88. eta

    ah, nice