<div class="gmail_quote">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.<br>
<br>For now, lets focus on the UI aspect, here is the portion from my previous email:<div class="im"><br><br>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.<br>
<br>Ethan has to say the following over this topic:<br><br>"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:<br>
<br>
[ ] Block messages from all users not on my buddy list<br><br>
[ ] Block {chat invitations, subscription requests, etc.} from all users not on my buddy list<br><br>
[ ] Allow users who are not on my list to see my presence<br><br>
etc.<br><br>
Per-buddy settings<br>
+------------------+---------+<div style="margin-left: 40px;">--------------+-------------------------+<br>
| Buddy name       | Block   | Block Chat   | Block File Transfer     |<br>
+------------------+---------+--------------+-------------------------+<br>
| Ethan Blanton    |         | X            | X                       |<br>
| Sulabh Mahajan   |         |              | X                       |<br>
| Richard Stallman | X       | -            | -                       |<br>
+------------------+---------+--------------+-------------------------+<br><br>
(This final table would almost certainly have more columns.)<br><br>
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.<br>
<br>
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. "<br><br></div></div>Thanks,<br><font color="#888888"><br>Sulabh<br>
</font></div><br>