Privacy Rewrite GSoC Project

[Sulabh Mahajan]

 I have discussed this with Ethan, and we think its best to concentrate on
Privacy subsystem right now, and handle storing blist (and privacy
information attached to the contacts) in accordance with the XMPP model
later. I am only concerned with the privacy aspects right now, and in the
current model of our blist or in the XMPP model that we want to follow, the
privacy information associated with a contact is stored in the form of
flags. In a way privacy subsystem is independent to the way we store blist.

For now, lets focus on the UI aspect, here is the portion from my previous
email:

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

Thanks,

Sulabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090722/3ad0e8dc/attachment.html>