HGKeeper

---

title: GSoC Ideas

date: 2019-01-11T03:13:47.000Z

anchor: gsoc-ideas

replaces:

- developer.pidgin.im/wiki/SoCIdeas

lastmod: 2019-08-22T04:39:28.000Z

---

This is a curated list of the tickets with the `GSoC:Idea` label from our

[issue tracker](https://issues.imfreedom.org/issues?u=1&q=tag:%20GSoC:idea%20).

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`.

## Protocol-specific ideas

### XMPP OMEMO Encryption

This project would implement OMEMO Encryption

[XEP-0384](https://xmpp.org/extensions/xep-0384.html). 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: [PIDGIN-17451](https://issues.imfreedom.org/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](https://xmpp.org/extensions/xep-0113.html) Simple Whiteboarding

* [XEP-0284](https://xmpp.org/extensions/xep-0284.html) Shared XML Editing

Currently we are unaware of any clients that implement XEP-0113, but

[Gajim](https://gajim.org/) 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](https://twitch.tv) 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](https://keep.imfreedom.org/grim/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

### 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

protocol.

### 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 `https://plugins.pidgin.im/` and would work basically like the [Chrome Web

Store](https://chrome.google.com/webstore/) 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.

## 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](https://github.com/rhx/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](https://gitlab.gnome.org/GNOME/gjs). 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](https://keep.imfreedom.org/gplugin/gplugin/file/feature%252Fgjs-cc)

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.

pidgin/nest