Default left as 'never' in mod_pubsub to preserve the previous behavior.
Unclear if this is desirable, but can always be changed later.
In mod_pep this allows turning off the automatic resending of most
recent item.
XEP-0060 says that this the way to indicate that 'persistent-items' is
unsupported, but doesn't explicitly say if it being disabled in the node
configuration also counts as unsupported.
When set to 'false' there is no need for a persistence interface at all,
since items are not persisted after being broadcast.
Had started wondering if maybe the behavior was wrong, after reading
parts of XEP-0060 that pointed in that direction.
Some discussion of this can be found in logs of
xmpp:xsf@muc.xmpp.org?join from around 2021-07-20
Thanks to Ralph for confirming.
Since nodes were always persistent according to the XEP-0060 definition.
Whether data is stored in memory or on disk was not what this setting
was meant for.
This is in preparation for fixing the behavior of 'persist_items', which
was misunderstood at some point. In mod_pep it toggles between
persistent storage and in-memory storage, while the correct behavior
would be to toggle whether published items are stored at all or
forgotten after being broadcast.
It's uncertain whether item not existing should be success and
nil, or fail with an error.
XEP-0060's "fetch most recent item" actually fetches a list of up
to N items. N here is a maximum, not a minimum. The feeling is that
no items is simply an empty list, not a failure of the operation.
This moves some XEP-0060 awkwardness out of util.pubsub and into mod_pubsub
A retraction is broadcast in an <items> container, whereas most other
kinds of broadcasts are in a container with a name matching the 'kind'
attribute.
This allows entities without an explicit affiliation to retrieve items,
which is specified by the XEP. Table 6: "Node Access Models" states that
for 'open' nodes, "any entity may retrieve items from the node".
See also discussion at:
https://mail.jabber.org/pipermail/standards/2018-August/035320.html
11:56:59 MattJ> Someone who has the ability to subscribe does not have the "subscriber"
affiliation until they actually subscribe, they just have the normal "none" affiliation
(which has permission to subscribe)
11:58:05 MattJ> However if the access model is whitelist, then anyone not on the whitelist
has an implicit negative affiliation, which we don't currently have, so I just named "restricted"
11:58:16 MattJ> Since it doesn't exist in any code yet, it has no permissions
