Revision as of 13:06, 12 October 2017

No mechanism to query all items after an item with a certain ID

This makes it hard and very inefficient to catch up on a PubSub node, after an client comes online again.

Sometimes you want to know who actually published the item.

@@ Line 1: / Line 1: @@
-= Missing functionality =
+= No mechanism to query all items after an item with a certain ID =
-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
+This makes it hard and very inefficient to catch up on a PubSub node, after an client comes online again.
-* 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]
+= XMPP address of publisher is not included in the notification =
-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.
+Sometimes you want to know who actually published the item.