[Standards] PupSub max_items field has no "max" value

Timothée Jaussoin edhelas at movim.eu
Sat Sep 28 20:02:10 UTC 2019


One little precision, I've also added the multi-items feature to 0060 a 
few months ago. This allows clients to know if servers actually supports 
more than one item per node. Some servers are actually basing their 
Pubsub implementation on PEP and only limit max_items to 1 without 
actually telling it.

But I think there's a way to make clients work together on Pubsub 
configurations as well. Basically we simply have to set a fix max_items 
in the XEP itself and enforce the configuration server side (and maybe 
expose it to the clients this way). It's already possible to do it on 
ejabberd. This also prevents some clients to change some node 
configuration and, for example, expose some content publicly or destroy 

             access_model: open
             access_model: whitelist
             max_items: 50000
             access_model: presence
             notify_retract: true

I have lost many times Movim nodes configuration because of some 
misconfigured clients :p



On 28/09/2019 20:12, Philipp Hörist wrote:
> Hi,
> There is currently no value that says make it the maximum the server 
> supports.
> This causes some problems, for example when we want to store bookmarks 
> in different items like in XEP-0402 proposed.
> Default on most servers is max_items=1. So first i try with publish 
> options and already here its not clear what value i should set for 
> max_items. There is no way to discover what the amount the server 
> supports is, so i take an arbitrary number i think is good.
> But a different client might think another number is better, so on 
> each publish each client pulls the node configuration and reconfigures 
> the node to whatever value he finds useful.
> This looks like a bad process. Usually i want to conifgure a node 
> once, and not every few days because another client thinks a different 
> config is better.
> Writing max_items down in the XEP is also not optiimal. We run into 
> the same problem if we later change the number in the XEP. Older 
> clients will configure the node always back to where it was.
> I see the same problem with item_expiry, if a server supports that 
> suddenly it gets impossible to have a item not expire.
> Now we could imagine setting the value to 0 means forever or max. But 
> i didnt find this documented anywhere.
> Regards
> Philipp
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190928/0aa3848e/attachment.html>

More information about the Standards mailing list