Privacy Rewrite GSoC Project

[Felipe Contreras]

On Sun, Jul 19, 2009 at 3:04 PM, Will Thompson<will at willthompson.co.uk> wrote:
> Sulabh Mahajan wrote:
>> Hey guys,
>>
>> So what method I have adopted is that, I am storing all the privacy
>> information in the blist itself.
>> Now we have a list of buddies and list of other contacts, with block
>> message, block presence, and information being local only as flags to
>> the buddy.
>>
>> To store contacts not on the buddy list, we have a group specifically
>> assigned, I have for the time being named this group _Privacy.
>> I modified the code in blist.c so that public API remains the same, and
>> buddies from _Privacy aren't referenced when we call functions like
>> purple_find_buddy().
>
> :'(
>
> This sounds like a really bad idea to me. Any name you pick for a group
> to hold these contacts is going to run the risk of clashing with a real
> group name. Given that you're taking the path of storing these contacts
> on the blist, the real issues would seem to be:
>
> a. There's no way to store contacts who aren't in any group.
> b. The UI can't decide for itself whether to display a buddy (based on
> their subscription state, etc.) because there's no generic way to find out.
>
> The first problem is a special case of the more general problem that the
> buddy list's design, as a strict List -> Group -> Meta-contact -> Buddy
> hierarchy, is basically wrong for most protocols. On XMPP, groups are
> more like tags; I don't know of any protocol which forces you to have
> contacts in exactly one group, so I'm going to stick my neck out and
> suggest that the XMPP model is the right one. So rather than trying to
> decide on a pseudo-group into which to put contacts to whom the user is
> not subscribed, but has blocked or whatever, the correct solution would
> be to fix the buddy list's design so that you don't have to.
>
> Felipe touched on this: it's silly that one can and does have several
> PurpleBuddy structs representing the same buddy on the same account.
>
> In my mind, the contact list should basically be a set of contacts
> annotated with the set of groups they're in, the directionality of
> presence subscription (if any), whether they're blocked, etc etc. If
> this were the case, the UI could say "aha, the user has no subscription
> to this contact, and they're blocked; I won't bother to show them", and
> then you wouldn't need to make blist methods skip certain contacts.

Perhaps it would make sense to read a bit of historical discussions
about the privacy redesign:
http://sourceforge.net/mailarchive/message.php?msg_id=94a0d45305022712511bf84726%40mail.gmail.com
http://sourceforge.net/mailarchive/message.php?msg_id=94a0d453050204233713dc8e1a%40mail.gmail.com

Curiously, my proposal for a specific account/contact-id structure was
discredited at the time...

-- 
Felipe Contreras