XEP-0402: Fix issues found during Stockholm XMPP Sprint #835
This PR might be more easily read commit per commit.
Rendered version: https://linkmauve.fr/extensions/xep-0402.html
I was extremely surprised at the difference of treatment for notifications between publishing an item (XEP-0060 §22.214.171.124) and purging all items (§8.5.2), both sending a notification if the node is configured for that, and retracting an item (§126.96.36.199) where the publisher additionally has to include a
Another issue we’ve identified during the Sprint is password migration, as much as I dislike this feature there are existing MUCs being protected by passwords, and we most likely keep those until we decide on either removing this feature from MUC altogether, or find a more secure way to store passwords on the server.
Otherwise, this specification is pretty nice and should be ready for advancing to draft soon I think.
Also all clients will have to agree on one value because otherwise your preconditons will constantly fail when other clients have used a different value before. Which in turn means we really need support for max_items=0 to mean server side max.
In order not to replace old bookmarks when pushing a new one, we need to request a good max_items value. This one has been picked as some random large enough number, bikeshed welcome! TODO: add support for unlimited values?
PubSub §188.8.131.52 says “If no error occurs and the <retract/> element included a 'notify' attribute with a value of "true" or "1", then the service MUST delete the item and MUST notify all subscribers as shown below.” This means the publishing entity, not the server or the subscription state, is responsible for properly enabling notifications to other resources, which makes no sense. See https://xmpp.org/extensions/xep-0060.xml#publisher-delete-success-notify
There is no rationale for this, and as it overrides the room name “forever” it shouldn’t necessarily be encouraged.