Privacy Rewrite GSoC Project

[Sulabh Mahajan]

We should probably have signals to indicate when a buddy has been blocked or
unblocked, when a chat user has been ignored or unignored, and possibly one
to
indicate that we dropped a message (and send the message text to the
callback so
plugins and other UI's can do stuff with the message if desired).
 Additional
opinions from the authors of other UI's would be helpful here.

                            ---  John Bailey (rekkanoryo)

I see blocking of IMs a bit like a spam filter for an email inbox, so
I suppose users may want to check sometimes that nothing useful was
accidentally blocked. This means that blocked messages should not be
silently dropped by libpurple, but still need to be handed to the UI
so that they can be presented later to the user.

--- Florian Quèze


Passing the blocked messages to the UI or a plugin through a callback
function or some other way is a great idea, but this will bring
inconsistency among the actions of various protocols. Most protocols support
blocking messages server side, hence prpls never get to see them. The
protocols for which we are implementing this client side (IRC, Yahoo in case
of block everyone not on list, and for many protocols when we fake a
feature) this might be possible.

So we would end up having two sets of protocols, one in which messages are
dropped locally, other in which this is done server side. To complicate the
matter, these sets would differ depending upon the privacy features we are
implementing.

eg- In case of yahoo itself,

   - Allow users on the buddy list           -- implemented client side,
   supported officially
   - Only users on the allow list             -- implemented client side, we
   fake this feature
   - Block all users                               -- implemented client
   side, we fake this feature
   - Block all users on the block list       -- implemented server side,
   supported officially

In short, we will not always know that certain messages were blocked. We can
not "guarantee" this feature, but we might be able to let the UI know which
protocols support it under the current chosen privacy feature(s).

With this in mind, do we still want to implement it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090608/f08f4b78/attachment.html>