Here is an approach that comes to my mind:

1. Figure out an exhaustive set of privacy features that are supported by the protocols, and assign them certain values, maybe something similar to current PurplePrivacyType? enum datatype

typedef enum _PurplePrivacyType
{
     /* An exhaustive list of possible privacy operations */
     PURPLE_PRIVACY_FEATURE_1
     PURPLE_PRIVACY_FEATURE_2
     .......
     PURPLE_PRIVACY_FEATURE_X
} PurplePrivacyType;

Then each protocol will define an array of “n” variables of type PurplePrivacyType?, where n would be the privacy features supported by the protocol. This array will hold the n values possible for that protocol.

PurplePrivacyType? protocol_privacy_features[n] = {<comma separated values of n features>};

2. Each protocol will register with the privacy subsystem a set of privacy features it supports. This can be done when the protocol plugin is loaded by passing the above mentioned array as a structure member of PurplePluginProtocolInfo?. Also we can have an initialize function called by each protocol plugin, the array being an argument to this function. Out of the features supported, each protocol can register a default privacy feature.

3. The privacy API now defines functions that operate on each of the features in that exhaustive list. Mostly there will be functions to add or remove contacts for most of the operations. There can be a separate function that operates on multiple contacts (like the whole buddy list). Eg—

purple_privacy_feature_X_add(...) , purple_privacy_feature_X_remove(...) ,

purple_privacy_repeated_call(<feature_function_pointer>, <list of contacts/buddy list>).

4. Each protocol will implement the functions to actually carry out the privacy work, and these functions will be registered with the privacy API in the name of PurplePrivacyUIOps, which will look something like:

typedef struct
{
     ....
     void (*feature_X_function_Y)(.....);
     ....
} PurplePrivacyUIOps;

API will also define functions to map the UI Ops with the protocol level functions, something like:

purple_privacy_set_feature_x_function_y(.., void (*feature_X_function_Y)(.....));

5. In some protocols there are some operations, only implementable on the client side. Eg – IRC doesn’t provide any privacy features, yet we can provide simple blocking of IMs from specific contacts, everyone except the buddy list, and so on. In yahoo “block everyone not on list” is implemented client side, or a feature “permanent visible list” can be implemented, where certain contacts will receive presence information in spite of being invisible. Hence we can provide features above those provided by the basic protocol without sending anything to the server which we normally don’t send.

(I have read on the mailing list views of developers regarding implementation of such features, about whether they suit in the core or as a plugin. I would say that those that fit in that exhaustive list go in the core, rest in plugins. This issue will also be clear after further discussion on the mailing list)

6. Most settings for the privacy are stored at the server side, but there might be some that need to be stored locally (like if we implement the above mentioned case), libpurple preferences API will be used for that purpose.

7. Finally, Pidgin in the Tools > Privacy menu will display the above implementation in a non confusing manner. For each enabled account, Pidgin will query what privacy features are supported (out of that exhaustive list), and display them. This is better than displaying all the features as we do now, which creates the illusion that we provide all the features for all the protocols.

Also we can define in the protocol plugin, the exact words to be displayed for each privacy feature. This set of char arrays will be passed to the libpurple/Pidgin either through PurplePluginProtocolInfo? or through the privacy initialize function called by each protocol plugin. This will help us use the same words/phrases that the official clients use, and further reduce the confusion between features to the bare minimum.

Also, we can follow the same procedure to define what privacy features would be displayed when we right click a buddy, but I have a feeling that it won’t be any more than block messages and/or block presence and/or block both messages and presence. We can query which protocol a contact belongs to and which of the three it supports.

8. Some other issues:

Allow drag and drop of contacts to the privacy lists
Add an “ignore forever” button to the authorization requests to prevent them from occurring repeatedly
Add a block/ignore/some-privacy-feature button at the top right corner of the conversation window, so that I can use a quick ignore-forever on those SPIM messages

Notes/Issues? to handle laters:

Haven’t thought about privacy issues when having a conference/chat/multi-user- chat/etc
Haven’t thought about how privacy and signalling can be handled together.