Privacy Rewrite GSoC Project

Felipe Contreras felipe.contreras at
Tue Jul 21 16:07:58 EDT 2009

On Tue, Jul 21, 2009 at 10:45 PM, Sulabh Mahajan< at> wrote:
> 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:

I disagree. The main issue is that some protocols don't support some
options, you simply need to avoid showing them, that's it.

MSN supports "Allow users below" and "Block users below", so you
should show only those options.

Now, there are ways you can improve the visibility on what's going on
with the privacy stuff. I can elaborate if you wish, but that's UI
stuff, nothing to do with libpurple.

> [ ] 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

There's already a way to block file transfers: click on the "Cancel"
button when you receive one. And why would you want to block file
transfers but not chats? And why would you want to block chats, but
not block the user?

I really don't see the point of those options.

Felipe Contreras

More information about the Devel mailing list