[Standards] Meta-Contacts: implementation notes

Pedro Melo melo at simplicidade.org
Sat Mar 29 19:44:51 UTC 2008


Hi,

during the last couple of weeks, the SAPO Messenger Mac client  
implemented the Meta-Contacts XEP-0209. This is report of the issues  
found. Sorry for the long email btw :).


1. The storage angle

The protocol is using private storage. I talked to one of the  
authors, Kevin, that told me that a PEP-powered version will be  
available sometime in the future. Using private storage is not a big  
problem, except for the lack of notification on update.

With multiple resources connected, the other resource needs to be  
notified somehow to re-fetch the meta-contact data. The workaround  
that we used was a no-op roster push. Basically we set a roster item  
(our own) with the same information that he has already. This roster  
push is broadcasted to all resources and this signals the clients to  
re-fetch the data. This is of course a hack, that only works with our  
client, and the real solution is to move to PEP as soon as it becomes  
available.

The second issue we found with the storage of meta-contacts is a bit  
worse, and unsolved so far. This protocol will fail for servers that  
don't support private storage. One such server is unfortunately  
GTalk. So if one of your accounts is a GTalk acount, you cannot store  
the meta-contact information.

The only workaround (and its not even complete) that I see for this  
is if we relax the second point of the requirements. If we store the  
full meta-contact data on all accounts, with a version attribute,  
then we only need one of the accounts with private storage available.  
If multiple representations get out-of-sync, we should use the most  
recent (using the version attribute) one. I myself see several  
problems that might happen when only a part of your accounts is  
available, but they are no different than the ones with the current  
spec in the same scenario. Even the current spec can get out-of-sync  
between accounts.


2. Attribute selection

Each roster item has several "attributes" that a client keeps track:  
the name of the contact, the groups it belongs to, the current active  
avatar, and the current presence (status and show).

There are no clear rules on which of these we should use for the meta- 
contact in case they differ between each contact. For now, we are  
using this rules (but they can change at any time based on feedback  
from our users):

1. name, groups and avatar: we use the name of the highest order  
contact, even if he is offline.

     this was done to minimize flash behavior (a contact changing  
name, avatar or group) when we logged on. By itself it does not  
prevent it, but its pretty close;

  2. the presence (show/status): we use the first non-offline  
presence based on the order of the contacts.

     we used the "best" (aka most available) presence for a while,  
but this *seems* more reliable for our day-to-day usage.

We don't support noneof the new PEP-based protocols. When we do, we  
must also cross those with the meta-contact information to know which  
ones to show the user. For example, if two different contacts inside  
the same meta-contact announce different geo-locations, you should

   a) use the most "recent" one;
   b) use the one from the highest ordered contact;
   c) talk to a hard-core physicist about the Heisenberg principle.


3. Attribute change

If we change the name of a meta-contact, what should we do to the  
contacts inside?

Right now, we opted to rename all the contacts, but it is debatable  
if this is not a excessive behavior.

This applies to any attribute change: name and groups.


4. meta-contact tag algorithm

The spec does not suggest any method of creating the tag attribute.

To ease our users to move to a XEP-0209-powered client, we opted to  
use the following:

  tag = sha1( lc(name) + apply( +, apply( lc, sort(groups) ) )

That is to say: concat the lower-case version of the name with the  
lower case version of each group, alphabetically ordered.

This works very well if you already keep you contacts with the same  
name inside the same group before moving to a meta-contact-aware client.


5. Final thoughts

I must admit that the lack of private storage in the GTalk service is  
a big turn off for us.

If we are willing to loose the order attribute (and I would not like  
that, but I want something that just works), there is a fallback  
protocol that requires only the usual roster to keep meta-contacts.  
If we assume that roster items with the same name + groups  
(basically, if the tag algorithm above yields the same hash for your  
roster entries) belong to the same meta-contact, we can implement  
meta-contacts without the need of any extra storage, just the roster.

The two down-sides are:

  1. you must rename the roster entries and stick them in the same  
groups if they belong to the same meta-contact: personally I have no  
problems with this, because it works pretty well even if I log in  
with a contact without meta-data support.
  2. you loose the user-order of contacts inside a meta-contact: so  
you have to revert to the usual presence priority.

We used this method (client-side calc of hash based on the above  
algorithm) in our windows client for 5 years now, with good results.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!





More information about the Standards mailing list