ralphm.net

ralphm's blog

Wednesday, 11 May 2005

Managing Profiles

Who knows what about me?

In a continuing effort, offline offlinestpeter makes some observations about managing profile data in Jabber. More specifically, how to do that using our publish-subscribe extention. Here are my thoughts.

What if you posted your profile information to just one node, having the fields distributed among various node items? Subscribers could select the desired fields by using subscription configuration, resulting in a content-based subscription. A subscriber would then only get notifications for those fields, and in the beginning fetch the complete view of the profile by just retrieving all node items (for his subscription).

What about access control? Well, you could base the access control on the supplied selection of fields. The authorization form for the subscription could include this information as a custom field (starting with x- as specified in Field Standardization for Data Forms or by registering it with the Jabber Registrar). After initial configuration, a subscriber may not change this configuration option (it would not show up when trying to reconfigure the subscription later on). Not sending a configuration form along with the initial subscription request would imply wanting access to all fields. This is partly because so-called unconfigured subscriptions have already passed the authorization phase.

To comment on general vs. application specific pubsub services, I suppose that many applications would need some customization in the service implementation. I think this is at least true for any content-based pubsub service (because you need to have a way to query the content). On the other hand, for simpler applications like extended presence, generic services should be sufficient.

Another possibility is pubsub applications that use only parts of the protocol. For example, one could have a service that does allow subscribing to nodes and receiving notifications, but denies the creation of new nodes or publishing via the pubsub protocol. Instead, a notification could be the result of some out-of-band event: a change in internal state or data received via another protocol (XMLRPC, e-mail, etc.). Or, my idea of how Mimír should be re-implemented as a customized pubsub service that allows plain-text notifications based on presence, and has side effects in the form of a personal news page.