Pubsub Public Subscriptions

%ents; ]>

Pubsub Public Subscriptions This specification provides a way to make subscriptions to a node public &LEGALNOTICE; 0465 Experimental Standards Track Standards Council XMPP Core XEP-0001 XEP-0060 XEP-0376 pps Jérôme Poisson goffi@goffi.org goffi@jabber.fr 0.1.0 2022-05-17 XEP Editor (jsc) Accepted by vote of Council on 2022-04-13. 0.0.1 2022-03-30 jp

First draft.

&xep0060; as its name states has a mechanism to subscribe to a node. Only the owner of the node can retrieve the list of subscribers

It may be interesting for users to share publicly the nodes they have subscribed to, or who is subscribed to theirs: it's a quick way to discover center of interest of a user, or to discover new accounts/nodes related to a specific center of interest. This kind of feature is common in modern social networks and often named "following" and "followers". This XEP proposes a solution to implement this feature in XMPP while respecting privacy of users.

There is currently a XEP partially covering this problem with &xep0330;. This XEP has the advantage to be usable with a generic Pubsub service, but it has 2 flaws:

it's only covering half of the problem: we get the pubsub nodes to which an entity is subscribed, but we don't know who is subscribed to a node
clients need to keep the 'urn:xmpp:pubsub:subscription' node synchronized with subscriptions: if a subscription is removed from a node, it may stay present by mistake in 'urn:xmpp:pubsub:subscription' node.

This XEP fixes both issues.

The design goal of this XEP are:

let a user discover to which node an other user is publicly subscribed
let a user discover who is publicly subscribed to a node
take care of privacy: a user must declare a subscription public on purpose
keep public subscription synchronized with nodes subscriptions

This XEP uses &xep0376; as only way to subscribe to a node and unsubscribe from a node, as it is necessary to keep track of subscriptions.

In this documentation, PAM service refers to a PEP service implementing &xep0376;.

Romeo wants to subscribe to the blog of his cousin Benvolio and he wants to make it public, so other peoples can discover Benvolio blog more easily.

He does that as usual by sending a subscription request as explained in XEP-0376 §Subscribing but he adds a <public> element with the 'urn:xmpp:pps:0' namespace:

]]>

Romeo also wants to follow the blog of this girl that he met at the ball, however, he doesn't want yet to make it public for political reasons. He then does the subscription as usual and does not include the <public> element:

]]>

Mercutio is a friend of Romeo and he wants to know which nodes Romeo is subscribed to, as it may be a way to discover new and interesting peoples. To do this, Romeo's PAM service manages a special node named 'urn:xmpp:pps:subscriptions:0'. This node is created and managed by the PAM service itself, it can be subscribed to and unsubscribed from as an usual PubSub node, and it contains an item for each public subscription that has been made by node owner (Romeo in our example). Each items payload is a <subscription> element with the 'urn:xmpp:pps:0' namespace containing a 'node' attribute with the name of the subscribed node, and a 'jid' attribute with the JID of the pubsub service containing the subscribed node.

The node owner can't add or retract items directly on the node: if Romeo wants to add or public subscription, it does this by doing a public subscription as explained in Public Subscription, and if he wants to retract a public subscription, he can do as explained in the next section. &xep0059; and &xep0442; apply normally if they are implemented.

]]> ]]>

Romeo can retract a public subscription in 2 ways:

by unsubscribing entirely from the node as explained in XEP-0376 §Unsubscribing. In this case the PAM service remove the node from public subscriptions (it won't appear anymore if somebody retrieves subscriptions) and unsubscribe from the node.
by subscribing again to the node without the <public> element, as explained in https://xmpp.org/extensions/xep-0376.html#subs. In this case the PAM service remove the node from public subscriptions, and forward the request to the pubsub service (so the pubsub service also knows that the subscription is not public anymore).

If Mercutio wants to know who is publicly subscribing to Romeo's blog, he request the PAM Service by using a special node managed by the service in a similar way as 'urn:xmpp:pps:0' node from Retrieving Public Subscriptions section (i.e. a node which can be subscribed to normally, but whose items can't be publised or retracted directly). This node is named by prefixing the name of the target node with 'urn:xmpp:pps:subscribers:0/'. So to check who is subscribed to Romeo's blog, Mercutio must request 'urn:xmpp:pps:subscribers:0/urn:xmpp:microblog:0' node. The service will answer with items whose payload is a <subscriber> element with the 'urn:xmpp:pps:0' namespace, and a 'jid' attribute whose value is the JID of the public subscriber:

]]> ]]>

note:Public subscribers is not restricted to PAM service, if a generic pubsub service implements this XEP, it MUST also returns the public subscribers when the special node is requested.

If a user wants to create, purge or delete a special node used in this XEP, or if they want to manually publish or retract items, the service MUST return a &forbidden; error to the user.

If a PEP or Pubsub service supports the "Pubsub Public Subscriptions" protocol, it must advertize it by including the "urn:xmpp:pps:0" discovery feature &NSNOTE; in response to a &xep0030; information request:

]]> … … ]]>

Publishing publicly subscriptions of a user has pricacy implications: those public subscriptions may be used by someone to get a user interests or to know they network of contacts.

It may be used by bad actors for many reasons like advertising, or it may even be life threating in some countries/situation as it may be used to known political opinion, religion, sexual orientation, etc. A client SHOULD make the subscription public only if there is no doubt that this is what the user wants, by using an opt-in system, and SHOULD display a well visible warning about the consequences of making a subscription public.

TODO