These ideas are starting points for Google Summer of Code projects that the
Pidgin, Finch, and libpurple community has agreed are generally desirable and
high impact. For smaller projects, community-submitted ideas, or projects that
for some reason we are not sure are in scope for SoC, please see
[wiki:SoCAndBountyIdeas]. (You can submit SoC proposals with those ideas, or
your own ideas, as well, you just have to convince us they're suitable!)
## Protocol-specific ideas
libpurple supports no native end-to-end encryption over XMPP. There are several
XEP's for this, and there is absolutely room for a new protocol that is
better/easier/more secure/whatever than the existing proposals. See
[wiki:EndToEndXMPPCrypto] and talk to [wiki:elb Ethan Blanton]. Note that
designing a new protocol would **absolutely** require getting some crypto gurus
### Add Voice and Video to the SIP Plugin
There are new IM protocols all the time, and some of them even get popular. If
you have a favorite IM protocol, you can propose implementing it. The bar here
is high, though! You need to convince us not only that it is desirable and that
you can do it, but that it will be maintainable; that means that there needs to
be a plausible community to maintain it (maybe you?) after the summer is over.
Convince us that will happen in your proposal.
### Update more things to the Modern Way
We are replacing as many parts of libpurple and Pidgin with modern
library-provided functionality as feasible for 3.0. For example, we have ripped
out our custom DNS infrastructure and replaced it with GIO DNS that did not
exist when our infrastructure was written. There's still a lot left to do here.
For example, we do not use the GTK icon infrastructure everywhere. Talk to
Michael McConville about some things he identified during his 2015 Maintenance
### Tests and proof of functionality
libpurple has always had an anemic test suite. Part of this is that it's hard
to test the protocol plugins, as we cannot hammer the official servers and we do
not have our own implementations of the protocols. Even where we do (such as
XMPP), that doesn't mean the existing servers are appropriate for testing.
Propose a set of tests that you think can be applied to the codebase and
(ideally) run automatically.
[wiki:grim Gary Kramlich] has an idea for a coordinated testing plugin and
server that would effectively run scripts implementing client-server
interaction unit tests for specific functionality. The idea is that server
scripts emulating specific activities (e.g., successful login or an
authentication failure at login) would be started by a plugin in a libpurple
client, which would then attempt that activity and check for the expected
result on the client side.
Pidgin has historically led the way in instant messaging UI design. Several
Pidgin behaviors have gone on to become ubiquitous. That said, our UI has
stagnated over the years, and it seems like IM UI in general has not done much
in recent history. Propose something novel and interesting and convince us
people would want it - or at least that it's worth seeing if they will. We're
not necessarily looking for crazy or off the wall, but we **are** looking for
libpurple has a large amount of network-facing C code, which makes it a big
target. Code hardening, security auditing, and elimination of common errors
have the potential to be a big win affecting a lot of users. libpurple 3.0 also
offers us an interesting opportunity in that it **should** make possible
protocol plugins written in a VHLL, which would reduce entire classes of
vulnerabilities significantly. Propose some specific hardening or auditing
activities to improve the code quality of libpurple or a libpurple client.
### User Highlighting and Name Completion
Pidgin implements a very basic form of name completion which doesn't work with
some of the newer protocols (namely Hipchat which has a distinction between
highlight names and display names). This project is to create an interface for
protocol plugins to expose what is complete-able as well as implement an API in
libpurple that will be used by the user interfaces.
Also, some of the new protocols have added additional highlights (that should be
complete-able) and cause the user to be notified (blue tab in Pidgin). Examples
of the additional highlights are @here and @all in Hipchat, and @channel in
Many modern messenger protocols have the capability of sharing the user's
screen, with or without remote control. While this can be dangerous, viewing a
shared desktop or sharing the local desktop is interesting to many users,
particularly in managed environments. The maintainers of the purple SIPE
protocol have implemented RDP sharing over Lync, and are interested in helping
Pidgin/libpurple adopt a protocol-agnostic interface for screen sharing as well
as working with us to get XMPP screen sharing capabilities in place.
A libpurple UI that watches the status of the IM networks and reports it back to
a reporting server. The clients would attempt to stay connected to the network
and report on a set interval. Ideally there would be many of these running all
over the world all reporting to a redundant server.