Privacy Rewrite GSoC Project

[Mark Doliner]

For the most part everything being discussed here sounds reasonable,
and I don't see anything that would cause a problem from Meebo's point
of view.

I'm strongly in favor of faking blocking messages for protocols that
don't support.  It's what most users expect.  I don't think it is
necessary to notify UIs when a message is blocked, but I don't object
to it.

Other responses inline:

On Sun, Jul 19, 2009 at 5:04 AM, Will Thompson<will at willthompson.co.uk> wrote:
> Sulabh Mahajan wrote:
>> 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.

I agree with Ethan and Will here--we should not pick a "magic" group
name like _Privacy.  If privacy info is going to be stored in
blist.xml then there should be some flag or something that that
specifies whether the group is visible.

But more importantly: I'm not sure I understand the reasoning for
storing privacy info in the buddy list.  They seem like two logically
different pieces of information.  Combining them seems to make things
more complicated.  Could someone maybe explain the reasoning for this?

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

I very much agree with this.  The XMPP model would make things easier
for libpurple and easier for the UI.  We would have one PurpleBuddy
struct for a given account-buddyname combination instead of a
PurpleBuddy struct for each group where the buddy exists.  It would
eliminate a lot of little workarounds we've added all over the place
(e.g. when you find out a buddy's server alias you have to set it on
every PurpleBuddy node if the buddy is in more than one group).

-Mark