Periodically we see or come up with ideas that would make a good Google Summer of Code project. Many of these get forgotten when we actually get around to listing ideas for the next summer. Here is a space to store them.

Some of these ideas may be insufficient for an entire Summer of Code project; in those cases it will probably be desirable to combine two or more ideas listed here into a single project.

If you need clarification on anything listed below, or want to run a new idea by us to see if we think it would make a good project, or if you have any other questions please feel free to ask on our ​devel mailing list.

Information About Projects By Year

Information about some Summer of Code 2010 projects
Information about some Summer of Code 2009 projects
Information about some Summer of Code 2008 projects
Information about some Summer of Code 2007 projects

Notes about the following ideas

There are a few things people need to keep in mind about the ideas presented below:

• These are NOT the only ideas we will consider.
• Students are encouraged to think of original ideas. A well thought-out original idea may well win out over any of the projects listed below.
• We have not assigned mentors to projects. This will happen once we decide which applications we will accept.

---

Now, on with the ideas:

Better chat log viewer

Our current chat log viewer has only limited functionality. A proposal for this project idea should include plans to implement the following:

• Enhance log viewing in Pidgin by creating a new log viewer that will have:
  • A tree hierarchy of all logs (so you don't have to use the "View Log" dialog for each buddy)
  • A search box for buddies that does real-time pruning of the tree as you type partial buddy names
  • Grouped by contact (person), so if I have "markdoliner" on AIM and "mark.doliner@…" on XMPP combined into a contact/person, the logs show up as being for one person, with some differentiation for me to tell which IM account was used.
• Optionally propose an external log viewer. This has been requested a few times and we have historically ignored these requests.

Automated usage statistics collection

It would be useful if Pidgin included functionality to automatically collect various statistics from users and aggregate these statistics into a viewable form on the Pidgin website. This would be useful in determining which features are popular and which are not, and could allow us to remove unused features and preferences. Google Chrome and possibly Adium could be used as references for how to implement this. Some requirements:

• The information must be anonymous, and not include usernames or passwords.
• Users must be able to opt-out. It's not clear whether reporting would be enable or disabled by default.
• Information must be easily viewable (so this project includes the client-side changes as well as possibly a server... but definitely investigate whether an existing solution could be used before creating a new one). It's not clear whether it would be public or private.
• Could also include automated crash reporting.

Migrate our code from Monotone to Mercurial

(Note: There is some concern that this project does not include enough coding to qualify for Summer of Code.) We'd like to switch using the Mercurial version control system, because it has wider adoption and would be a lower barrier to entry for casual developers. There are a few requirements for this project to be successful:

• Complete history
• All tags and branches
• Configuration/installation of Mercurial on our boxes
• Updated wiki information on how to access our Mercurial server, maybe a link to more Mercurial info. Info on how to migrate from Monotone to Mercurial (even if it's just "mtn diff | patch"

Emoticon cache

(Note: There is some concern that this project is not large enough to justify an entire project.) Currently Pidgin does nothing with received emoticons. It could save a lot of bandwidth if a cache of received emoticons existed. It could also be merged with local custom smileys so we have a unified way to manage these files. The cache can be done per session, per conversation, per account, or as a global permanent cache (just as buddy icons). The preferred method is a permanent cache so emoticons could be fetched only once.

MySpaceIM TLC

Our MySpaceIM implementation is currently substandard. The plugin was developed as part of Summer of Code 2007 by reverse-engineering the protocol spoken by the official client (making it the first publicly-available third party MySpaceIM implementation), and although it is functional, further reverse-engineering of the protocol and bug-fixing of the libpurple implementation is needed to bring our client up to par with the official client.

A list of known bugs is available at MsimToDo?. Areas to consider working on include, but are not limited to:

• Buddies are added to their buddy list using their name/alias. This should be changed so they are added using their numerica ID, with the server_nick field set to their name/alias.
• Group chat support (#4691)
• Improved server-side buddy-list support (#4734, #5240)
• Buddy search (#2661)
• General bug fixing
• Adding new features supported by the official client, but not libpurple

Your mission is to understand what the official MySpaceIM client does at a protocol level, document what you've found ​here (if not already documented), and implement it in libpurple.

Topical Reference Tools

• In the same vein as the display of relevant advertisements along with gmail messages and in other Google tools, create some kind of interface and associated functionality to display contextually relevant information in IMs or other interface elements related to the current conversation.
• A modular or generic implementation to allow different "feeds" of information to be used.
• Implementation of this as a core plugin with dependent UI plugins might prove interesting.
• This should be able to be done asynchronously to avoid interfering with the performance of the event loop.

This sounds suspiciously like the (abandoned) ​Dashboard project – maybe some ideas from there could be adopted? —resiak

Gobjectification Projects

• Adopt a decent segment of the Pidgin source and begin to remodel it around the Gobject, such as the buddy list, the conversation interface, or something else significant and modify libpurple and Pidgin and/or Finch related objects to handle or exist as Gobjects as well.
  • rekkanoryo: Plugins should become gobjects and prpl's should be implementations of a PurpleProtocolIface (or similarly named interface) as a mandatory requirement of gobjectification.

Web site translations

• Produce a translation system for Pidgin's web site (at least the main static content)
• Implement Language auto-selection (via browser "Accept-Language" header)
• Use statically generated pages to avoid unnecessary server load and overhead (in other words, avoid pulling in the strings every time the page loads; only when they need to be regenerated)
• Make use of existing technology such as gettext or similar web projects to allow translators to submit translations easily
• Find a way to generate a translation template, identify or tag strings within pages.
• Consider ways to provide translated versions of images and screen shots
• This particular idea may not be sufficiently complex to span a summer and it may be worthwhile to combine it with other web site or internationalization improvements to Pidgin or some other type of larger project.

libpurple detachable sessions

This is an often-requested feature to which the response is often "run Finch in screen". Ideally, it would be possible for a user to run Pidgin and Finch simultaneously on a computer, with both programs sharing the same data and connections. This would allow users to leave Pidgin open, yet still access their IMs over SSH with Finch.

This requires an implementation of some sort of libpurple daemon, and a method for the clients to connect to that server, and access and display the buddy list, conversations, and chats. Existing ongoing conversations' history should be visible in Pidgin or Finch when they connect to this daemon.

Javascript plugin loader

Similar to the Perl and Mono plugin loaders but for Javascript

Pidgin Plugin Website

A plugin website for browsing plugins in a nicer way than just the list view on ThirdPartyPlugins. Possibly integration with Pidgin via a built-in plugin browser. See ​adiumxtras.com and ​addons.instantbird.org for examples.

Android frontend

There's already been work to port libpurple to Android, but there's no front-end to actually use it yet.

XMPP prpl improvements

• Add support for some XEPs. Here are some interesting ones with at least one other implementation (helpful for testing interoperability):
  • XEP-0184: Message Delivery Receipts - indicate when your contact's client has received a message you've sent
  • XEP-0198: Stream Management - improve reliability of XMPP connections
  • XEP-0308: Last Message Correction - ability to correct one's last message

• Clean up/Finish work
  • Support for Jingle File Transfer: see ​https://developer.pidgin.im/viewmtn/branch/shortchanges/im.pidgin.cpw.malu.xmpp.jingle_ft.