[Psi-devel] Re: Re: Privacy

[Jeroen Vaes]

On Tuesday 26 April 2005 17:40, Remko Troncon wrote:
> > I can't really come up with an example that can't be mapped to this
> > format. Maybe it's not easy to implement, but not that it can't be done.
> > The server has to parse different privacy lists too, this is quite the
> > same thing.
>
> For starters, it misses features such as filtering based on
> subscription, filtering based on resource, ...

Those are all possible to implement. Like I said, it's just a start.

> Something tells me that a set of if-then-else rules is more powerful
> than a representation of a list with groups and jids, and that i can
> make up rules which are not representable.

It might be more powerful, but it won't be usable.

> I also am not sure i understand correctly what the semantics of the list
> is. If there is an icon, does it mean 'Allow', and if there is no icon,
> does it mean 'deny' ? Or is there a third state (i sure hope so).

As I said in the first mail: "When an icon is present, it 
means the event is blocked. when it it not, the event is allowed.". There is 
no third state (I assume you mean by third state that there is no rule?).

Psi should be able to figure out if it should write a rule or not. That's the 
whole point. And yes, generating a list like this probably would be 
sub-optimal, but it's a small price to pay.

> What does a group with an icon mean, and a subitem
> of that group with also an icon ? And a subitem with no icon ?

A group with an icon means "block everything for this group". If you set this 
"rule", all icons for the contacts of this group will appear (every contact 
is blocked). Think of it like a shortcut for selecting every user by hand.

A little example: suppose I block messages from the "friends"-group, Psi 
should write a rule like this:

"If group = friends deny messages"

If I select every contact in a group except Friend 1, Psi should make a list 
like this:

"If contact = friend 1 allow messages"
"If group = friends deny messages"

> > My dialog is far from perfect, but I still think it's the most easy way
> > for a user to configure his privacy settings.
>
> Sure, it has some good ideas. But i would like to stress again that we
> first need a dialog with *full* power (as in anything that can occur),
> and that we can then move on to easier to use methods.

I'm sure it can have full power. But I think we should stop thinking about 
"how can I implement privacy lists" and start thinking about "how can I 
present privacy settings to the user and map them to Jabber's privacy lists". 
What good it is to have a full privacy lists implementation if 90% of our 
users can't use it?

-- 
Jeroen Vaes
Mail: jeroen.vaes at telenet.be
Jabber: jeroenv at amessage.de