[Standards] DEFERRED: XEP-0209 (Metacontacts)

Pedro Melo melo at simplicidade.org
Fri Jan 23 11:47:54 UTC 2009


On Jan 22, 2009, at 9:05 PM, Remko Tronçon wrote:

>> Thus, I consider the Kopete behaviour rather bad.
> I wouldn't call it bad. It's a good enough poor-man's metacontact,
> especially in the case where private storage is not available on the
> server. However, I do think behavior like this should be optional. I
> for example have a few contacts with the same name in my roster (but
> in different groups).
> Leapfrog provides both approaches IIRC.

All SAPO clients use this method. We hash the lower case versions of  
the name and group name, and use that tag as a aggregation point.

If you move a new standalone jid in your roster to a meta-contact, we  
rename the standalone JID and move it to the same group as the others.

This might seem bad for some, but it is in production for 6 years now  
without complaints.

In the Mac version (Leapfrog), we implemented XEP-0209 and used it  
internally (friendly customers and those brace enough to use the  
nightly builds) but we rolled to the code back to the simpler version.

At the time, delays to retrieve the private storage items would cause  
temporary mis-aggregation of contacts, who look like "bugs" or erratic  
behavior. Also, the size of the iq set for each simple change to a  
meta-contact is also a negative aspect of the protocol as it stands.

The final nail was that some popular XMPP services out there don't  
have private storage. At the time, GTalk didn't have it, I don't know  
if they have it now.

So we went back to our roster-based approach: its simple, works  
sufficiently well (even with extra delays from rosters), and it is  
immune to out-of-sync issues.

As others noted, it does rename contacts. For our user base, that was  
a non-issue. We are mostly "home" customers.

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

More information about the Standards mailing list