[Standards] Meta-Contacts: implementation notes

[Pedro Melo]

Hi,

On Apr 3, 2008, at 8:52 AM, Remko Tronçon wrote:
>>  For more than 5 years now, this is being used in production at  
>> SAPO. If
>> several contacts have the same hash (based on the algorithm above)  
>> then the
>> client displays them in the same meta-contact.
>
> This poor man's metacontacts approach could be enough, indeed. I don't
> really understand yet why you would do the complex hashing thing, I
> would just (optionally) group all contacts with the same name within
> the same group into one metacontact. This would mean that, if one of
> the sub-contacts is in two groups, it would be in a meta-contact in
> one group, and be separated in the other. As far as I understand, with
> your approach, it wouldn't be in any metacontact at all?

The hashing is a mere implementation detail, actually. As long as you  
specify the you must compare the lower-case versions of the name and  
the groups (in a specific order) it will work out ok.

I don't like the term lower-case. I prefer some sort of case-ignoring  
stuff, but I'll leave that for native speakers to sort out. The point  
is to compare ignoring case.

As for the difference in group membership given rise to two meta- 
contacts, yes, it would.

Right now, I don't have a strong opinion against your way of doing  
things, but in your scenario, it seems to me that each meta-contact  
is a per-group entity. So a single roster item could belong to  
different meta-contacts, if he belongs to several groups. This is a  
problem for me in two situations:

  * renames: if I rename one meta-contact, I need to rename the  
roster items that belong to it, and this will undo the meta-contact  
in the other group;
  * group-less roster displays: if your client has an option not to  
display groups and just bunch the contacts in a single list, ordered  
by some metric like <show> or other complex rule, then you get N meta- 
contacts, one per group.

In the end, I still prefer to have a strict rule (name and groups  
must match). I think a more loose rule like yours will open up  
problems when you start to think about renaming and stuff.


> Things become more complex when you stop displaying the roster name to
> the user, and only display the names that the user assigned to himself
> (nickname xep). Maybe in that case, you would have to make sure that
> the roster name is something sensible initially, and you create
> metacontacts by dragging & dropping contacts on each other, which as a
> result would rename the contact to the item you dragged onto it. The
> user would never see the actual assigned 'names' in his client, but
> they should be sensible because other clients might show it.

I like to show the nicknames and other info the contact has chosen  
with lower priority to my client, to prevent spoofing attacks. The  
user (my client user) will see the information that he chooses (name,  
group), and optionally, in lower contrast colors, information under  
the contact control.

If I give too much relevance to the user nickname or other  
information in control of the contact, then I think we are opening up  
a lot of avenues of attack. Just showing the avatar is problem enough.

I think clients would be better off showing that information as a  
"More information"-pane at the time of subscription and in context- 
menus, but ask the user to choose the name for the meta-contact.

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