[PubSub] Brussels report

Peter Saint-Andre stpeter at stpeter.im
Mon Apr 20 15:45:14 CDT 2009

Hash: SHA1

On 2/11/09 8:02 AM, Ralph Meijer wrote:
> On 2009-02-11 15:21, Dirk Meyer wrote:
>> Ralph Meijer wrote:
>>> Nevertheless, the concept of providing nodes linked to user accounts,
>>> where the those user accounts have their own jid of the form
>>> user at service, still has great appeal.
>>> The general consensus seemed to be that we should keep PEP for the
>>> limited use cases, while expanding server side implementations with
>>> more features from XEP-0060.
>>> I'd really like a good short name/acronym for nodes on a user account,
>>> by the way. It seems that a lot of confusion is there because some
>>> people refer to just that feature as PEP.
>> Right. I prefer PEP over "raw" PubSub because I do not have to search
>> for a PubSub server and do not need to figure out where I can store
>> stuff. 
> You've just proven my point. One of the features of PEP is that nodes
> are tied to user accounts (xmpp:ralphm at example.org?;node=mynode) instead
> of a generic publish-subscribe service that has its own JID
> (xmpp:pubsub.example.org?;node=ralphm_node).
> Having nodes associated with a JID explicitly, makes discovery easier
> for subscribers. For publishers, the advantage is that you can use
> well-known node identifiers that are identical for each user. You still
> have to discover that your server supports PEP. In the same manner it
> could discover where your server's pubsub service is, although this
> requires more queries.
> That said, nodes tied to a user account are not a feature unique to PEP,
> but are defined in section 9 of XEP-0060. Maybe we need to define a
> discovery feature to make this feature explicitly discoverable.

This is what we like to call "pubsub-on-a-jid" which means that the bare
JID of your IM account is a virtual pubsub service. That's not as catchy
as "PEP", though. I think it would be good to have a disco feature for this.

>> E.g. ejabberd uses pubsub.server.tld and the (default) root node
>> for a user is home/server.tld/username. How can a client know that?
> I want to make one point here about ejabberd's organisation of nodes,
> although I don't know if recent versions still do this. In my opinion,
> making node identifiers non-opaque in this way for a generic publish
> subscribe service is confusing, limiting and sets a bad example.
> Limiting because particular use cases, like transferring ownership of a
> node, are impossible. I would even go as far as rating it broken.
>> IMHO a server should provide a user PubSub tree with standardized
>> names. I want to know where a PubSub tree is a can write my keys to
>> and I also want to know where the PubSub nodes for my friend's are.
> Assuming nodes-tied-to-a-user-account is available, you still need some
> way to know about the node names. This could be through discovery or a
> search (XEP-0055 with data forms). However, well-known names seem to
> have a strong preference. In this case, as you add support for a
> particular feature in your client (e.g. User Tune), the node identifier
> is known because it is defined by the specification.
> Stated differently: you cannot implement publish-subscribe generically
> in a client. You always implement a particular use of publish-subscribe,
> with its associated payload format(s), well-known node identifier(s) or
> a way to discover them, etc.

Right. And that's why client developers explicitly add support for a
given XEP. So I think that well-known NodeIDs are fine.

> As for subscribing to nodes, PEP uses the automatic subscription and
> namespace filtering features via Entity Capabilities (XEP-0115) from
> XEP-0060 to make this easier. Unfortunately this uncovers the following
> issue:
> Recently, the text in section 9.2 (Filtered Notifications) was updated
> to clarify how this feature works exactly, with this in a nice box:
>   Note: In the context of personal eventing, the +notify feature means
>   that the subscriber will receive notifications only from the node
>   whose NodeID matches the desired namespace, because there is one node
>   per namespace and one namespace per node.
> Upon rethinking that phrase, it means that +notify breaks as soon as a
> service implements more than just PEP and allows for more than one node
> that publishes in a particular namespace (e.g. a Buddycloud-like service
> that publishes to also publishes to a node that keeps a location
> history). Unsuspecting PEP-only clients will suddenly receive
> notifications from other nodes.

I've clarified this in XEP-0060 now -- it's all about NodeIDs, not


- --
Peter Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the PubSub mailing list