[Standards] Meta-Contacts: implementation notes

Kevin Smith kevin at kismith.co.uk
Fri Apr 25 22:11:33 UTC 2008

Finally replying...

On Sat, Mar 29, 2008 at 8:44 PM, Pedro Melo <melo at simplicidade.org> wrote:
>  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.

Yep, but PEP where available is nicer.
>  This protocol will fail for servers that don't support
> private storage.
>  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.

Well, we can also set a 'master' account to look after servers which
don't support a useful storage mechanism yet. This avoids getting out
of sync between accounts, and allows us to cope until servers are

>  2. Attribute selection
>  Each roster item has several "attributes" that a client keeps track:
>  There are no clear rules on which of these we should use for the
> meta-contact in case they differ between each contact.

If the contacts are ordered, you pick the dominant order.

>  For example, if two different contacts inside the same
> meta-contact announce different geo-locations,

How is one person going to have two geolocs? :)

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

Prompt the user?

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

That seems overkill, to me.

>  This applies to any attribute change: name and groups.

It seems more than overkill for groups - it seems unhelpful.

>  4. meta-contact tag algorithm
>  The spec does not suggest any method of creating the tag attribute.

Right, I think you can use what you like

>  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.

It's a clearly inferior solution, but I don't see this is an awful
workaround if people must use such servers - proxying another of your
servers for storage seems a bit cleaner to me.

Certainly, I'd get very irritated very quickly with any client which
automatically renamed and regrouped my contacts for me. It irritates
me enough when clients change my avatar automatically.


More information about the Standards mailing list