Add an alias for /development/wiki/GetABacktrace to the debugging page

Testing Done:
Ran `npm hugo:server` and verified that `/development/wiki/GetABacktrace` redirected to `/development/debugging'

Reviewed at
title: GSoC Ideas
date: 2019-01-11T03:13:47.000Z
anchor: gsoc-ideas
lastmod: 2019-08-22T04:39:28.000Z
This is a curated list of the tickets with the `GSoC:Idea` label from our
[issue tracker](
These ideas have been deemed generally desirable and/or have high impact by the
community. As such this list may not be completely up to date. If you're
curious of what might not have made this list yet, please see the link above.
If you have any questions about these ideas, please ask on the tickets that are
referenced or by joining us in ``. If you don't have
an XMPP account check out our [PidginChat Service]({{< ref "/about/pidginchat" >}}).
## Protocol-specific ideas
### XMPP OMEMO Encryption
This project would implement OMEMO Encryption {{% xep 0384 %}}. This project is
a bit complicated as it would need to add some features to both libpurple as
well as Pidgin and Finch to really make it a first class feature.
For starters libpurple needs a way to represent an encryption method for a
conversation. Once that is in place, we also need a way to mark messages as
encrypted and which method (possibly none), settings, keys, etc were used.
Pidgin and Finch will need a way to allow users to change what encryption to
use and should be readily available in the message window.
Finally the XMPP protocol would need to be updated to actually implement
XEP-0384 and use the new API in libpurple to make it all work.
### XMPP Whiteboard Support
Ticket: {{% issue PIDGIN-17451 %}}
Pidgin has supported whiteboard for very many years now, however the only
in-tree plug-in that uses it is SILC which is difficult to build. This means
that breakages are inevitable and that's bad for everyone but mostly users.
As such, there are multiple XEPs to implement whiteboard in XMPP:
* {{% xep 0113 %}} Simple Whiteboarding
* {{% xep 0284 %}} Shared XML Editing
Currently we are unaware of any clients that implement XEP-0113, but
[Gajim]( does implement XEP-0284.
The extent of this project would be to implement XEP-0284 and make sure there
is interoperability with Gajim as well as any additional cleanup that might be
necessary in the Whiteboard API.
## New Protocol Plugins
### Twitch Plugin
[Twitch]( is a popular site for live streaming things like
gaming, arts, crafts, and even programming. Twitch brings with it some
interesting problems. The chat rooms in Twitch are nearly IRC, but they are
HUGE. It's not uncommon for there to be to many thousands of users in a single
chatroom and all of them talking very quickly and using very many emojis.
Grim has some basic support already done which is available at
[purple-spasm]( He tried to
implement emojis, but Purple2 and Pidgin2 are not designed to be able to handle
the kinds of use cases Twitch presents.
Also due to the volume of Twitch chats there are different modes that the chat
can be in. "Follower Only" mode only allows followers to talk. "Emote Only"
mode only allows users to send Emotes/Emoji. "Slow mode" rate limits messages.
Finally, Twitch considers it an error if you send the exact same message within
30 seconds of the previous message.
### Instagram Plugin
Instagram is a popular social network that has chat capabilities. It would
prove beneficial to many if we had some sort of support for it.
## Internals
### Audit Log
It would be handy from both troubleshooting and security points of view if we
kept a log of every setting change that happens in libpurple. The idea here is
to make everything auditable so when something is different users are quickly
able to figure out why.
This idea is being discussed in {{% issue PIDGIN-17496 %}}.
### Account Assistant
Currently adding an account to Pidgin requires a lot of technical knowledge.
It's certainly possible for someone to figure it out, but we can and should
make it a much easier process.
There's a rough draft of how this would work in {{% issue PIDGIN-17461 %}}.
This project would include writing quite a few composite GTK Widgets as well
as getting pretty familiar with our abstractions for protocol plugins.
### Name Completion
Pidgin implements a very basic form of name completion which doesn't work with
some of the newer protocols (namely anything that has a distinction between
highlight names and display names). Also, newer protocols tend to allow you to
complete chat room names as well which we currently do not support at all.
This project is to create an interface for protocol plugins to expose user and
chat compleitions. Some protocols require a `@` prefix for users and an `#`
prefix for chats, but others do not so we'll need to having something robust
that can allow the protocol to work easily with whatever method the user chose
for this instance. We don't want to lock the user into using `@` on one
protocol and not another, as that's a support nightmare waiting to happen. We
would be better off supporting as many methods as possible regardless of
### Mentions
Historically Pidgin has just looked for your username in a message to determine
if you were mentioned. This worked well enough for awhile, but things have
changed considerably over the past few years. Namely, protocols will now tell
the client when the user has been mentioned.
This happens for a number of reasons, but the biggest one is that there are
ways to mention groups of people as well as everyone in a chat room. For
example `@all`, `@channel`, `@everyone`, `@here`, as well as the ability to
mention a role on Discord.
Our limited research so far, has shown that there is no distinction when
multiple mentions are provided in the same message. So if you're mentioned at
the same time as someone else, your mention looks exactly the same as the
mention for the other person.
This project would consist of separate libpurple and UI portions. The core
portions would create the infrastructure to make mentions more robust than they
currently are, and the UI updates would update Pidgin and Finch to handle the
new infrastructure.
The libpurple updates would consist of adding a "mentioned" property to
`PurpleMessage`. This follows the current behavior of other clients that just
say whether a message contains a mention or not. Libpurple would also need to
add a signal that would be emitted during `purple_conversation_write_message`
if the `mentioned` property is true. This signal would be emitted from the
conversation instance and pass along the message itself. This would allow a
plugin to play a sound or the UI can track it in other ways.
The UI updates for now, would just include drawing attention to the messages
that have mentions in them. Ideally there would be some sort of navigation for
the user to jump to the mentions, but we need more infrastructure for that to
happen. In the mean time, just styling the messages differently would be more
than adequate.
## 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.
## Plugin Website
Over the years it has been very difficult to find plugins for libpurple,
Pidgin, and Finch. We've tried to address this in a number of ways by listing
ones that people told us about, but this is hard to maintain and isn't
discoverable by end users.
This project is meant to fix those issues by creating a website that would live
at `` and would work basically like the [Chrome Web
Store]( where users can upload their
plugins and provide support and such.
This site would provide a REST API so that we can implement a user interface
inside of Pidgin and Finch that would make finding new plugins much easier for
users. It would also have the added benefit of allowing plugins to auto
## GPlugin
### Swift Plugin Examples
Swift is a popular compiled programming language released by Apple that is
meant to replace their usage of Objective-C. Since Swift compiles to native
code, it should be easily loadable into GPlugin. Using something like
[SwiftGtk]( it should be possible to put
together some plugin examples in the same vein as the Vala examples that are
already in the GPlugin codebase.
This project would mostly likely not be large enough to cover an entire 175
hours of a Google Summer of Code project, but could be combined with another
smaller one to make up the time.
### Gnome Javascript Loader
A long time ago, GPlugin supported
[GnomeJS]( However, that version of
GnomeJS was using the C bindings for Spider Monkey, which is the JavaScript
engine in Firefox. Awhile back Mozilla unstandably decided they no longer
wanted to maintain language bindings in multiple languages and moved to only
providing C++ bindings. GnomeJS transitioned but the GPlugin load was never
fully updated.
Grim tried a few attempts to get this working, as can be seen in the
[gjs-cc branch](
but it does not currently work.
Embedding GnomeJS is mostly undocumented and much of the work Grim has done has
been "borrowed" from Gnome Shell itself that embeds GnomeJS. Grim is not sure
of where he left off, but with a little bit of work this should be
We are confident at this time that this project would not contain enough work
for a full Google Summer of Code project.