Privacy Rewrite GSoC Project

[Sulabh Mahajan]

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

Right now, I use the name "_Privacy" to differentiate it from the other
groups, rather than any flag, I have used the name itself. Also, to
differentiate buddies in the buddy list from the contacts in privacy list, I
check whether this contact/buddy rests in _Privacy or not. I again haven't
used any flag here.

Ethan has the following view over the issue:

" I think it would be better to flag the group as private in some way, such
that its namespace does not interfere with public groups. Perhaps you should
bring this up on devel@ and see what others think. I dislike magic names,
and I suspect that hidden groups may have other uses. "

So help me with this:

   -  How should I differentiate the hidden group _Privacy from other
   groups. I think a flag to denote the group hidden should be fine.
   -  How should I name the group (currently named "_Privacy"), so that
   there is minimum conflict with the names of the groups created by the users.

Another issue that needs to be talked is, should we move away from the way
we handle privacy states, where we present the user with options like allow
all, allow users on buddy list, block all, block users below, allow users
below. Should we keep following this interface and fake those states which
the protocol doesn't provide, or should we scrap it and redesign a new
interface, that allows us to tune features beyond that can be provided by
the older interface.

Ethan has to say the following over this topic:

"I think that we all agree that we want to move away from the "Allow all
below", "Block all below", etc. etc. to something more coherent. I have been
thinking something like:

[ ] Block messages from all users not on my buddy list

[ ] Block {chat invitations, subscription requests, etc.} from all users not
on my buddy list

[ ] Allow users who are not on my list to see my presence

etc.

Per-buddy settings
+------------------+---------+--------------+-------------------------+
| Buddy name       | Block   | Block Chat   | Block File Transfer     |
+------------------+---------+--------------+-------------------------+
| Ethan Blanton    |         | X            | X                       |
| Sulabh Mahajan   |         |              | X                       |
| Richard Stallman | X       | -            | -                       |
+------------------+---------+--------------+-------------------------+

(This final table would almost certainly have more columns.)

The settings applied to each prpl, specifically, would then be computed from
the union of all of these settings. The user should not have to know that a
particular protocol is set to "Allow only listed", with the items of the
list being the buddy list. We should hide all of that from them.  As you
suggest, we should then "clean up" anything that the protocol itself cannot
handle with local policy.

There does remain a question of what to do about, for example, protocols
which simply have no "invisible" type state, or cannot block subscription
information; we should probably discuss this as a group. "

So please present you views over these issues.

Thanks

-- Sulabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090713/6eb58f86/attachment.html>