Over the weekend, I had an interesting thought: what if every user's Jabber ID were a pubsub node? Right now, in order for a user (let's say, our old favorite Romeo) to publish his geolocation, mood, activity, or other forms of extended presence, he needs to find a service that implements JEP-0060, create a dedicated pubsub node for each data type he wants to publish, perform a disco-publish, and so on (this whole dance is described is JEP-0119). Plus, when someone (let's say, Juliet) receives an event notification from such a pubsub node, she needs to somehow correlate it with the publisher, either by keeping track of all the nodes to which she is subscribed (including its metadata) or the publisher needs to include an appropriate SHIM header. Is this really in keeping with the Tao of Jabber?
Now let's visualize what the world would be like if pubsub were more tightly integrated into Jabber server implementations. Romeo could simply publish information to his own JID, at nodes identified by the appropriate protocol namespace names (his geolocation data is at JIDfirstname.lastname@example.org' + node='http://jabber.org/protocol/geoloc' etc.). When Juliet receives data from these nodes, she doesn't have to guess who the data is about -- obviously, it's about Romeo. We could do the same for any information about Romeo -- his vCard, his avatar, syndication feeds for his weblog (can you say Atom-over-XMPP?), and so on (perhaps someday even including network availability, i.e., presence, though that might be overkill). Romeo will probably still need to complete a disco-publish so that each of his pubsub nodes is also a disco node, but the server implementation could also be written to handle that transparently (every pubsub node created at a user's JID is also a disco node).
I'm not saying that every Jabber server should or would do things this way -- that train has left the station. But it might be a neat way to implement things if one were writing a new server from scratch.
Peter Saint-Andre > Journal