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.