XMPP and Social Networks, part 1: Notifications
The use of XMPP publish-subscribe in federation and third-party applications deviates a bit from the standard use-case. Usually publishing, subscribing and receiving notifications happen through the same protocol on specific (leaf) nodes. Entities subscribe to a node that represents a particular thing they are interested in getting updates for, and when an item is published to that node, these subscribers will receive a notification for that item.
For federating social networks, the focus is on the exchange of updates on social objects or comments between services. For third-party applications, the most important thing is getting updates, preferably as soon as possible. So, for both of those use cases, receiving notifications through XMPP gives it an edge over HTTP: no polling, lower latency, less connections.
How these items are published, does not really matter that much. What you will typically see is that services somehow have a new item available (submission via the web, SMS, e-mail or a web-based API) and want to expose that through XMPP. Posting a new update through XMPP from a third-party client usually does not provide an advantage over existing web-based APIs.
For a service like Jaiku, Twitter or Identi.ca to provide XMPP publish-subscribe support, it is important to define the subscribable unit and provide that as a node. Such a node will usually not be published to directly, but is more of an aggregate node. Examples would be: all updates by a particular user, all updates in particular channel, all updates by a user and his contacts, all public updates. An other example could be: all comments on a particular social object.
Conceptually, all such aggregate nodes are internally
subscribed to a particular subset of new and updated social objects
and comments. You might even implement it exactly like that. Think
of a prospective search that is captured by a node: every time a
new item comes into the service, it is determined which of the
provided nodes would be a match for this item, based on author,
contact lists and permissions. Subsequently, for all of those
nodes, a notification will be sent out to its subscribers. Telling
items apart in this scenario is then likely not done using the
service JID, node identifier of item identifier, but using some
identifier in the payload, like Atom's id
element, although those other identifiers might provide a
context.
For those familiar with the concept of XMPP publish-subscribe collection nodes: those would be a special form of aggregate nodes that make it explicit what their relationship to the nodes they aggregate items for is.