Increasing supply of PIP/PEP nodes

My favorite XEPs of last year where PIP (XEP-0223) and PEP (XEP-0163). These two made Publish-Subscribe (XEP-0060) trivial to implement on XMPP clients, and pave the way for rich-presence clients.

One problem was that open-source servers did not implement PIP/PEP. Recently this has changed, with both Openfire and ejabberd having decent implementations. Other servers, though, are still MIA.

Also of note, GTalk does not supported it yet. This is a bit of a problem due to his visibility in the XMPP community.

So if you do implement it in your client (and I think you should, really), it seems that you have to keep using the current protocols for avatar (for better or worse XEP-0054 plus XEP-0153) and server-side storage (XEP-0049).

There is something that servers could do to improve this situation though. There is a small change that would give client authors even more good reasons to implement PIP/PEP today.

If private storage and vCards are implemented on top of PIP and PEP, we could have the best of both worlds.

From the point-of-view of current clients, nothing will change: they will still use XEP-0049 to set and get their private storage nodes, and they will still use XEP-0054 to publish and retrieve their vCard. But at the same time, each private storage item would also be available in a PIP node, and the user vCard would be available in a PEP node.

This would allow PIP/PEP-capable clients to announce support for vcard-temp+nofity namespace in their disco response, and get instant notifications of vCard changes. Also, announce storage:bookmarks+notify and clients that only support version 1.0 of XEP-0048 will immediately support version 1.1.

This could be a easy way to increase supply of nodes, to see if we can reach critical mass sooner, in the move to a pubsub-world.