Ideas for Pidgin, Finch, and libpurple GSoC projects
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 SoCAndBountyIdeas. (You can submit SoC proposals with those ideas, or your own ideas, as well, you just have to convince us they're suitable!)
This page is not world-editable, while the SoCAndBountyIdeas page is. If you have an idea to add, please add it there. If it gets traction, it will be migrated here. You can also comment on the ideas here on that page if you like.
Protocol-specific ideas
Encryption for XMPP
libpurple supports no native end-to-end encryption over XMPP. There are several XEPs for this, and there is absolutely room for a new protocol that is better/easier/more secure/whatever than the existing proposals. See EndToEndXMPPCrypto and talk to Ethan Blanton. Note that designing a new protocol would absolutely require getting some crypto gurus on board!
New protocol plugins
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.
Forward Progress
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 mmcc about some things he identified during his 2015 Maintenance Hero project (mmcco).
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.
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.
Better UI
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 plausibly better.
Internals
Code hardening
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 Slack.
Advanced Features
Screen sharing
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.
Supporting Tools
Canary
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.
