XSF Discussion - 2020-03-09

  1. flow

    just to check if my memory serves me right: there is no way to query the xmpp server for pending in subscription requests after you have send the initial presence, right?

  2. Ge0rG

    flow: you could do a roster pull I suppose

  3. flow

    Ge0rG, I don't think so

  4. flow

    as I believe I will only found the pending out subscription requests in the roster

  5. flow

    as I believe I will only find the pending out subscription requests in the roster

  6. Ge0rG

    I'm always struggling with corner cases of presence subscription management in multi-client situations, and each time I wonder whether it's a bug in my code, a bug in the other clients, a bug in the server or a bug in the spec

  7. MattJ

    Ge0rG, FWIW there are almost certainly bugs in Prosody regarding subscription stuff (edge cases that don't 100% match the spec, or potentially stuff not covered by the spec)

  8. MattJ

    But coming up with a test suite that covers everything is pretty hard, it's one of the things I wrote scansion for

  9. Ge0rG

    MattJ: my pet issues revolve around accepting / rejecting a request on device A and not seeing it on the simultaneously connected device B

  10. Ge0rG

    MattJ: not sure if you can scansion two parallel connections

  11. MattJ

    You can

  12. MattJ

    Most tests involve multiple connected clients

  13. Ge0rG

    MattJ: well then!

  14. Ge0rG

    Let me append that right to the end of your infinitely long TODO list.

  15. MattJ

    It's already on there, of course

  16. MattJ

    Being infinite

  17. jonas’

    nobody said that the entries are unique, also I’m pretty sure you can have an infinitely long TODO list with only unique items without all possible entries occuring

  18. jonas’

    for example, if your list consisted only of entries matching the regular expression a+

  19. flow

    To be fair, I don't think that this is an edge case and that it is actually not that bad that there is no method to query the server for pending in subscriptions, as it forces you to do the right thing™: setup a callback/listener/hook for pending in subscriptions, and after that, send the initial presence, handling the list of pending subscriptions client-side

  20. goffi

    Hi, I'm implementing "max_items" node configuration in my pubsub component, but I don't see any standardisation in XEP-0060 (it's just present in examples)

  21. Daniel

    goffi: it's registered

  22. Daniel

    I think

  23. jonas’

    for certain definitions of registered

  24. Daniel

    16.4.4 pubsub#node_config

  25. Daniel

    > for certain definitions of registered Yes

  26. goffi

    Daniel: I see it's there: https://xmpp.org/registrar/formtypes.html, but still, it's unclear

  27. goffi

    I have a few questions actually, mainly 2: 1) why using "max" which forces to use "text-single" for the field, instead of 0 or -1 for no max? Is there a legitimate reason to want a node with 0 for max items?

  28. goffi

    2) what do to when a config is changed and max_items become smaller than the actual number of items? Delete all extra ones? If so, there is a risk to delete accidentaly items (I think this happened to Movim with microblogging, because some buggy clients where changing max_items to 1)

  29. Daniel

    Pubsub is only a cache anyway

  30. Daniel

    So implementations just have to deal with vanishing items

  31. MattJ

    goffi, the 'max' thing has been discussed here a few times

  32. goffi

    what? No

  33. goffi

    it's definitely not "just a cache"

  34. Daniel

    You should read the xep again

  35. MattJ

    We (Prosody) are not happy with it, because we have form validation and there is no existing data type that matches "usually a positive integer, sometimes a string"

  36. goffi

    Daniel: I don't see where the XEP says that

  37. goffi

    MattJ: the type is quite bad indeed

  38. goffi

    Daniel: may be you should read the xep again :-/

  39. pep.

    Daniel: no it's not just a cache. Maybe that's true of omemo, not pubsub

  40. pep.

    (of the usage omemo does of pubsub, bot pubsub itself*)

  41. MattJ

    I certainly agree that pubsub is not just a cache

  42. pep.

    (of the usage omemo does of pubsub, not pubsub itself*)

  43. goffi

    I'll have to follow the thing and use text-single, but that's a really unfortunate choice.

  44. Daniel

    Can someone point me to normative language on how persistent items and Max items is supposed to work?

  45. goffi

    there is no normative for "max_items", that my point, it's only present in examples (and examples are not normative as far as I know)

  46. MattJ

    Yeah, it's lacking

  47. goffi

    Actually, most of pubsub config is not normalized properly.

  48. Daniel

    The language I can find leads me to believe it is a fifo cache

  49. MattJ

    There is also inconsistency between ejabberd and Prosody I believe

  50. Daniel

    > Note: If the service or node is configured so that there is a maximum number of items cached at the node and the maximum is reached when an item is published, the service MUST delete one of the existing items. It is RECOMMENDED for the service to follow the "first in, first out" rule and delete the oldest item.

  51. Daniel

    So you don't get an error on publish

  52. Daniel

    It Transparently deletes the oldest

  53. goffi

    Daniel: that when max_items is set indeed, that the behaviour I would expect (I'm not happy with the "MAY" result in sending a delete notification though)

  54. goffi

    but my issue is when the config is changed, not on publication

  55. goffi

    I think I'll not change the max_items and return an error if there are more items than the requested max_items, user will have to delete/purge manually before changing the settings. That's better than deleting items by accident.

  56. Daniel

    Right. But what's the default value for max_items

  57. Daniel

    You say it's only a cache when max items is set

  58. goffi

    my server doesn't have max_items for now, so I'll set a default to "max".

  59. Daniel

    So how does it behave if it's not set

  60. goffi


  61. Daniel

    I can't find normative language in the xep that tells me that max_items is by default unset or 'max'

  62. Daniel

    Therefor I conclude it's a cache by default

  63. Daniel

    Even if your implementation isn't

  64. goffi

    There is no normative language for max_items at all

  65. goffi

    that's one of the main issue with pubsub, it's not normalised enough and implementation differs on this kind of important points.

  66. Daniel

    Note that I don't want it to be a cache

  67. Daniel

    But I think there is a reading of the xep that leads you to believe it is

  68. goffi

    Daniel: I think we agree on the behaviour of "max_items", but I disagree when you said previously "implementations just have to deal with vanishing items"

  69. Daniel

    Also I think that prosody for example does in fact have a limit

  70. Daniel

    Which if it them adheres to the rest of the xep makes it a cache

  71. goffi

    Daniel: I have implemented many features on top of pubsub (blog, tickets, merge requests, etc), and it's clearly not an option that items are randomly disappearing.

  72. Daniel

    Maybe a large cache of 1000 of whatever the limit is in prosody

  73. Daniel

    goffi: I agree. But don't blame the messanger

  74. goffi

    Daniel: the config has to be checked (either with publish-options or by getting the config) by the client anyway, max_items need to be set by the client IMHO, we can't rely on supposed default behaviour.

  75. goffi

    Daniel: I'm not blaming you ;)

  76. Daniel

    Yes the max items has to be set. Especially for pubsub on the account

  77. Daniel

    Where the default is 1

  78. goffi

    anyway thanks all for the feedbacks, I have my answers :)

  79. pep.

    Time to PR pubsub? :p

  80. goffi

    pep.: yep, I can do that but I don't know when

  81. goffi

    I have a bunch of work on XEPs accumating in my TODO list, I guess I'll have to block a couple of days for that.

  82. pep.

    goffi, I guess even just mentioning that in the wiki or something would be great already. We have a page for pubsub I guess?

  83. pep.

    (without looking for normative language right away)

  84. pep.


  85. Daniel

    The thing is that even when a client sets it to max, it's still a cache

  86. Daniel

    Because Max is not defined as unlimited but as what ever the server internally has as a limit

  87. pep.

    It's not a "cache" then, we just need to make it obvious on publish that there's not space or sth :/

  88. Daniel

    So you have to change the normative section I quoted earlier

  89. MattJ

    Yeah, I think there should be a way to specify the behaviour

  90. pep.


  91. pep.

    I don't think I like the "When a new item gets published, delete whatever" part

  92. MattJ

    I don't want to change it - the current behaviour is often desired (though I agree "delete whatever" needs to be less vague)

  93. Daniel

    > It's not a "cache" then, we just need to make it obvious on publish that there's not space or sth :/ I agree that this is where we want to end up. But agreeing on that doesn't mean that it's already the case

  94. MattJ

    A related issue is when you publish an item with the same id as an existing item

  95. pep.

    I don't think deleting an item on publish is good for anything that goffi mentioned. blog, bug tracker, etc.

  96. pep.

    "Yo I published a comment and your article disappeared"

  97. pep.

    (might not happened because these two would probably be on different nodes, but fun nonetheless)

  98. Daniel

    Yes or bookmarks

  99. pep.


  100. pep.

    "I don't understand, whenever I'm joining a new groupchat, I'm leaving another" :p

  101. Daniel

    There is a discrepancy between what pubsub says and who we want to use it

  102. Zash

    Singleton node, FIFO of size n, fixed-size (conflict on publish if limit is reached)

  103. Zash

    I guess much of this comes from Pubsub being too generic to be usefuly without additional logic

  104. goffi

    MattJ: what is the issue with publishing on the same id as existing item? I belived the XEP explicitely says somewhere that it's then overwritting.

  105. Zash

    I thought that this was the same as removing that item and publishing a new one.

  106. MattJ

    goffi, I'm not aware of such text

  107. MattJ

    Ah, it does use the word "overwrite"

  108. MattJ

    It's in 7.1.3 Error Cases: https://xmpp.org/extensions/xep-0060.html#publisher-publish-error

  109. goffi

    MattJ: It's even in success case: https://xmpp.org/extensions/xep-0060.html#publisher-publish-success (the note under the example)