Privacy Rewrite GSoC Project

[Will Thompson]

Hi!

Sulabh Mahajan wrote:
>     * 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.).

Having been called out as being a specific example of a weird use case,
sorry for not answering sooner. Been incredibly busy with
non-telepathy-haze work. :(

A general complaint I have about libpurple's APIs from telepathy-haze's
point of view is that they give haze no way to report errors properly.
Lots of API for actions which can fail don't have any way to report
failure; instead, purple_notify_error() may or may not be called with a
localized error message, which can't be associated by haze with the
action that caused it. So haze can't return a decent error from the
D-Bus method.

Any privacy-related methods that can fail asynchronously (ie. where
network traffic is involved) should take an (optional) callback to be
called when the action succeeds or fails. So, something like:

    void
    purple_privacy_list_add (
        PurplePrivacyList *l,
        const gchar *contact,
        PurplePrivacyListAddedCb cb,
        gpointer user_data,
        GDestroyNotify destroy);

    typedef void (*PurplePrivacyListAddedCb)(
        PurplePrivacyList *l,
        const gchar *contact,
        PurplePrivacyListModificationError e,
        const gchar *localized_description_from_server,
        gpointer user_data);

    typedef enum {
        PPLM_NO_ERROR = 0,
        PPLM_LIST_FULL,
        // ... whatever...
    } PurplePrivacyListModificationError;

>     * 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.

In Telepathy, we want papering over these things to live at a higher
level than the connection manager. Connection managers don't have any
persistent storage, so even if prpl-irc fakes a block list, it'll be
wiped between reconnections.

I can understand the desire for libpurple to do some of this work so
that it doesn't have to be reinvented in Pidgin, Finch, Adium, and all
the other clients who might want this, but I'd like to be able to turn
it off. (This is a case of wanting libpurple, the protocol library, and
libmauve, the UI helper library. :-))

>     * What about signalling, what signals the privacy subsystem would
>       want to emit?

I took a look at
<http://developer.pidgin.im/wiki/GSoC2009/PrivacyRewrite/initial_proposal>,
but I don't really see the point of having an enum of features and a
whole bunch of functions per feature, when the number of different
feature APIs is going to be of the order of 2. As far as I can tell from
<http://developer.pidgin.im/wiki/GSoC2009/PrivacyRewrite/protocol_specific>
(this is a really handy resource, by the way: I'll certainly use it
again when discussing privacy-related issues in Telepathy), the features
seem to be:

  * A bunch of lists of contacts with a relatively small set of meanings;
  * What to do with people not any of the lists (that is, should we
allow or block everything/presence/messages/...?).

The latter can be a bunch of flags — Block_Everything, Block_Presence,
Block_Messages, ... — with the prpls saying which of those they support,
and a function to set the currently-active flags.  As alluded to above,
my first idea for the former is to have prpl expose PurplePrivacyList
objects with well-known names; maybe

    enum {
        /* Correspond to AIM, MSN, ...'s lists, plus the first and last
         * of ICQ's lists
         */
        PURPLE_PRIVACY_LIST_ALLOW,
        PURPLE_PRIVACY_LIST_DENY,
        /* Correspond to ICQ's lists */
        PURPLE_PRIVACY_LIST_INVISIBLE,
        PURPLE_PRIVACY_LIST_BLOCK,
        /* For Yahoo! */
        PURPLE_PRIVACY_LIST_BYPASS_INVISIBLE,
    };

and the prpl exports only the lists it supports. They could have flags
for things like "this list is only available when you're invisible",
"this list is transient" (both of which only apply to Yahoo's magic
invisible override list), "members of this list can't be on the roster", ...

But thinking about this further... I think a better design would be to
annotate buddies on the buddy list with their privacy state, and the
prpl just exports a mapping from attribute type to the flags just
discussed, indicating which attributes can be set and what they mean.

Telepathy's current approach corresponds more closely to the first
approach I suggested. In fact, we represent the roster as several
disparate lists: "stored" (everyone stored on your roster in any way),
"subscribe" (those whose presence you can see), "publish" (those who can
see your presence), then "allow" and "deny". We've never implemented
"allow", and we've discovered in practice that splitting the roster up
in to subscribe/publish/stored is never what the UI wants. I suspect the
same would be true for libpurple: you want to see in the buddy tooltip
whether they're blocked or whatever, so it makes sense for this
information to be annotations on the blist rather than n separate lists.
 (Maybe we could also unify "Has you: yes" and "Subscription: both", and
make them machine-readable rather than localized strings? That'd be
cool. Haze can't cleanly use these in their current form (because
they're localized strings, and it would need to know what they actually
mean in order to expose them correctly in the Telepathy API).)

This is a bit of a braindump. Concisely, my opinions are:

  * people's membership of various privacy lists should be annotations
on the buddy list;
  * libpurple shouldn't forcibly fake protocol features that don't
exist, but it's okay for it to do so if the UI can tell what it's faking
and hence avoid using the faked functionality;
  * the states and error reporting should be machine-understandable,
rather than just being localized strings (this kind of thing in general
was also an issue for Trutap, and I imagine is an issue for Meebo and
Adium when their UI requirements don't match the UI policy imposed by
libpurple);
  * supporting XMPP privacy lists in their full generality would be
lunacy. :-) I don't believe an accessible UI is possible.

The Telepathy Cabal are vaguely discussing moving Telepathy's roster
representation to list of contacts with attributes (group, subscription
statuses).  Obviously there's some overlap here — our privacy interfaces
are rudimentary and largely unimplemented thus far — so I'll try to feed
discussion between this thread and other Telepathy developers as it happens.

Regards,
-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20090603/71fc6ac9/attachment.sig>