[Wocky] Buddy Authorization

[Paul B. Hill]

Hi,

Jabber's "buddy" feature is closely tied to presence, hence has some privacy
concerns and requires a level of authorization. However, Jabber also has the
concept of a "roster" which provides some of the functionality that people
may be used to from AIM's buddies and some of the Zephyr features for
discovering people.

Below is some information that I found online. It is primarily aimed at
developers, but has some useful background information for people on this
list.

5. Managing Your Roster
Roster management is one of the most confusing areas of the protocol, or at
least of its current documentation. Here's an overview.

How the roster works.
The roster is the list of Jabber entities with whom the user has a presence
relationship. This includes people to whose status the user is subscribed
("buddies"), people who are subscribed to the user's status ("watchers"),
and people to whom the user wants to subscribe but who haven't yet approved
the request. The roster is thus the model of the GUI "buddy list".

The Jabber server stores the user's roster and notifies all logged-in
clients whenever it changes: when the user adds or removes a buddy, when
another user adds or removes the user as a buddy, and when a potential buddy
approves or rejects a subscription request. This is known as a roster push.
The change notifications are sent as <iq> elements using the
jabber:iq:roster namespace. The client can also manually request a complete
copy of the roster: it's necessary to do this just after logging in to
detect changes that may have been made since the last logout at this
computer.

[JPO 1.6.12]

Subscribing & unsubscribing buddies.
Confusingly enough, adding and removing buddies is not done via roster
manipulation but via <presence> elements. Here the type is subscribe or
unsubscribe and the request is sent to the buddy's address. Confirmation or
rejection is received as a reply <presence> element (with the same ID) with
a type of subscribed or unsubscribed.

Conversely, you'll also deal with other entities wanting to subscribe to
your presence. In this case it's exactly the opposite: you receive the
subscribe or unsubscribe and (after consulting with the user) reply with
subscribed or unsubscribed.

[JPO 1.4.1.3 -- 1.4.1.7]

In all these cases, since your roster is changed, the server will also send
another roster push to tell you about the roster element to change.

Manually updating the roster.
It's possible for you to update the server-side roster by sending <iq
type="set"> elements. You would do this not to add or remove buddies (see
the previous section for how to do that) but to add or change metadata
associated with a buddy, such as their nickname or group[s]. [JPO 1.6.12]

Actually, it is possible to add people to the roster this way, but it won't
subscribe you to their presence. They'll just be there passively, as in an
e-mail address book. You may or may not want to support this in your UI; it
doesn't seem especially useful to me, but it might be handy if there are
people the user wants to send messages to but doesn't need to know their
online status.

The documentation says it's also possible to remove people directly from the
roster by setting the "subscription" attribute to "remove". [JPG p.65] This
is the only way to remove an item added without a subscription (as in the
previous paragraph); but I'm not sure what happens if you remove a
subscribed buddy this way. Presumably it should unsubscribe you from their
presence notifications just as if you had sent a <presence
type="unsubscribe"> element.

Implementation tip.
Since the server will notify you of all changes in the roster, you can drive
the management of the GUI buddy list entirely from these pushes. For
example, when the user wants to add a buddy, you send out a <presence
type="subscribe"> element but don't update the buddy list yet; you'll
immediately receive a roster push from the server telling you about the
change and should update the buddy list when you receive it. By using roster
pushes to manage the buddy list, you ensure that the buddy list stays up to
date whether it's you or another simultaneously logged-in client making the
changes.

More roster info.
You may want to display more buddy information in your UI than simply the
Jabber ID, presence state and status message. As described above, a full
name/nickname can be associated with a buddy in the roster.

A whole lot more information about a buddy can be obtained by retrieving
their vCard via an <iq> query, if they've stored one on the server [JPO
1.6.26]. vCards are the Internet equivalent of business or Rolodex cards and
can contain any imaginable sort of personal and contact information such as
photos, birthdays, phone numbers...

Still more generally, the Jabber server as of version 1.4 allows users to
store arbitrary XML data tagged with any namespace, accessible to anyone who
queries their account using the same namespace. [JPO 1.6.10] I'm not aware
of any concrete usage of this, but it has great potential.


The preceding information comes from
<http://www.akeni.com/en/support/jabberclientcheatsheet.php>.