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 gsoc@conference.pidgin.im. If you don’t have
an XMPP account check out our PidginChat Service.
This project would implement OMEMO Encryption XEP-384. 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.
Ticket: 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:
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.
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 is a popular social network that has chat capabilities. It would prove beneficial to many if we had some sort of support for it.
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 PIDGIN-17496.
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 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.
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
protocol.
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.
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.
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 https://plugins.pidgin.im/ 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 update.
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.
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 completeable.
We are confident at this time that this project would not contain enough work for a full Google Summer of Code project.