[Standards] Meta-Contacts: implementation notes
melo at simplicidade.org
Thu Apr 3 11:13:18 UTC 2008
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.
XMPP ID: melo at simplicidade.org
More information about the Standards