Difference between revisions of "XEP-Remarks/XEP-0060: PubSub"
| Line 5: | Line 5: | ||
* Adding a new access model 'local'. See [http://buddycloud.github.io/buddycloud-xep/#default-roles Buddycloud-XEP: Channel Access Models] vs. [http://www.xmpp.org/extensions/xep-0060.html#accessmodels XEP-60 4.5 Node Access Models] | * Adding a new access model 'local'. See [http://buddycloud.github.io/buddycloud-xep/#default-roles Buddycloud-XEP: Channel Access Models] vs. [http://www.xmpp.org/extensions/xep-0060.html#accessmodels XEP-60 4.5 Node Access Models] | ||
but intosi points out: "For nodes with an access model of "authorize", subscription requests MUST be approved by one of the node owners unless service policy allows entities with affiliations other than "none" to auto-subscribe" -> so BC could've just used this, and add an affiliation for the local domain jid to the node, and let your service treat a domain match as a fallback in case there's no affiliation for the user bare jid. | |||
Revision as of 16:34, 11 May 2015
Missing functionality
XEP-60 appears to be missing some important use cases, so that some implementations have to resort to using their own flavor of PubSub, e.g. Buddycloud. Which prevents those projects from using standard compliant PubSub implementations (e.g. Buddycloud uses a patched version of Smack's PubSub implementation).
Examples include
- Adding a new access model 'local'. See Buddycloud-XEP: Channel Access Models vs. XEP-60 4.5 Node Access Models
but intosi points out: "For nodes with an access model of "authorize", subscription requests MUST be approved by one of the node owners unless service policy allows entities with affiliations other than "none" to auto-subscribe" -> so BC could've just used this, and add an affiliation for the local domain jid to the node, and let your service treat a domain match as a fallback in case there's no affiliation for the user bare jid.