Privacy Rewrite GSoC Project

[Zachary West]

On Mon, May 25, 2009 at 08:05, Sulabh Mahajan <sulabh.dev at gmail.com> wrote:
> What are the current requirements of the privacy subsystem apart from being
> able to support the privacy features provided by the protocols, and display
> them in a non confusing manner?

I think a good addition to the privacy system as it stands now is the
integration of group chat ignores into the main privacy system. Right
now they're a separate, very transient privacy control on a per-chat
basis. Rolling it into the main privacy system might be a good idea.

> Ethan suggested we should keep in mind that libpurple is used by several UIs
> other than Pidgin. Our design shouldn't be Pidgin specific. What do
> non-Pidgin-style users of libpurple need that the current situation doesn't
> provide, and what are their requirements for a new API? (specifically,
> telepathy -- but also Meebo, the XMPP transport, etc.).

Adium doesn't quite work around any bugs, but we definitely feel the
bugs that libpurple has. I've seen the privacy toggle itself around
(on MSN), and the numerous other bugs.

> How far do we want to unify the outer interface to protocol privacy, and do
> we want to "paper over" functionality differences? For instance IRC provides
> no privacy support, everything has to be done client side. Similarly for
> some protocols, a few additional features might be supported above the ones
> provided. Should we implement such features?  I am in favour of implementing
> at least those features that we can do without passing anything unusual to
> the server.

IRC does have a weak set of privacy settings ("SILENCE" raw
command—server-dependent though).

I think you should support *all* privacy settings on all protocols,
and fake whatever you can't support natively. Almost everybody would
expect "only from my contact list" to always work; users don't care if
the server can or cannot support something (and I definitely
don't—hide it!).

Zac West