I was just reading through XEP-0060 and came across a blurb recommending how to handle multiple pubsub subscriptions to the same node. In my testing I see that Openfire (very nicely!) creates multiple subid’s and groups them into the same pubsub event when sending updates to jids that have subscribed to the same node multiple times, just as is recommended in the document.
However, for my current deployment I would like to turn off this multi-subscribe feature if possible. I would like jids to have only one subscription to each node. Does anyone know of a way to do this?
Here is the text from XEP-0060:
An entity may wish to subscribe using different subscription options, which it can do by subscribing multiple times to the same node. Support for this feature (“multi-subscribe”) is OPTIONAL.
If multiple subscriptions for the same JID are allowed, the service MUST use the ‘subid’ attribute to differentiate between subscriptions for the same entity (therefore the SubID MUST be unique for each node+JID combination and the SubID MUST be present on the entity element any time it is sent to the subscriber). It is NOT RECOMMENDED for clients to generate SubIDs, since collisions might result; therefore a service SHOULD generate the SubID on behalf of the subscriber and MAY overwrite SubIDs if they are provided by subscribers. If the service does not allow multiple subscriptions for the same entity and it receives an additional subscription request, the service MUST return the current subscription state (as if the subscription was just approved).
When the pubsub service generates notifications, it SHOULD send only one notification to an entity that has multiple subscriptions, rather than one notification for each subscription. By “entity” here is meant the JID specified for the subscription, whether bare JID or full JID; however, if the same bare JID has multiple subscriptions but those subscriptions are for different full JIDs (e.g., one subscription for email@example.com./foo and another subscription for firstname.lastname@example.org/bar), the service MUST treat those as separate JIDs for the purpose of generating notifications.