Privacy Rewrite GSoC Project
sulabh.dev at gmail.com
Mon May 25 08:05:43 EDT 2009
I am Sulabh Mahajan, the GSoC student implementing "Privacy Rewrite" this
year. I am the same guy who did the yahoo! project last year. My
college exams just finished, I have some practicals for next 7 days, but I
can extract good amount of time for the project. The project can start, or
rather can't wait to start :-)
So, lets discuss the design issues related to the privacy subsystem. The
current implementation of the privacy system needs to be redesigned from the
scratch. Because of the nature of the work I have done so far for Pidgin, I
am thoroughly aware of yahoo! prpl and bits and pieces of libpurple. I have
never done the designing part, so to be able to come up with a great design,
I would need the help of the experienced developers.
Let us use this thread to discuss the design issues.
Please go through these links:
Protocol specific privacy features:
The initial design idea:
There are several issues that need to be discussed, like:
- 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?
- 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?
telepathy -- but also Meebo, the XMPP transport, etc.).
- 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.
- A related issue is, what if a function can be handled both client and
server side, like rejecting a file transfer to a blocked user, should we let
the server decide it for us, or should we always let the privacy subsystem
handle the case? I am in favour of letting privacy system drop all the
requests, and not pass it to the server, helps simplify the system.
- What about the privacy issues with conference/chat/multi-user-chat/etc?
How should we handle the multiple user environment, when each
protocol differs in the way it handles this issue?
- What about signalling, what signals the privacy subsystem would want to
- What about privacy issues related to xmpp? Do we support XEP-0191 ?
What about sending presence notifications (invisibility?). How is the
privacy handled differently in gtalk compared to xmpp?
- Also, while coding the subsystem, I would like to use one (or two)
protocols initially to test. What that protocol(s) should be? I am most
familiar with the yahoo!, and would naturally want to use it, but yahoo! is
very simple in privacy concerns and won't provide me with enough testing
scenarios. XMPP is naturally the second choice for being well documented,
but the privacy extensions are too complex, and I am not sure which one
Pidgin implements, and if that implementation is complete or not.
What are the other design issues? There must have been discussions on
privacy hundreds of times, I am sure everyone has lots of ideas. I would be
grateful, if you can share those ideas with me. I request developers to come
up with more questions and issues related to privacy, so we can
have discussions and finalize a design.
Project: Privacy Rewrite
Mentor: Ethan Blanton
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel