Overhaul the GSoC ideas page.

8 weeks ago, Gary Kramlich
Parents 698cf520ef9f
Children 494965ad0441
Overhaul the GSoC ideas page.

Testing Done:
Ran locally.

Reviewed at
--- a/hugo/content/development/gsoc/ Fri Feb 19 00:04:45 2021 -0600
+++ b/hugo/content/development/gsoc/ Fri Feb 19 01:48:14 2021 -0600
@@ -7,108 +7,133 @@
lastmod: 2019-08-22T04:39:28.000Z
-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
-[wiki: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 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 ``.
## Protocol-specific ideas
-### Encryption for XMPP
+### 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.
-libpurple supports no native end-to-end encryption over XMPP. There are several
-XEP's for this, and there is absolutely room for a new protocol that is
-better/easier/more secure/whatever than the existing proposals. See
-[wiki:EndToEndXMPPCrypto] and talk to [wiki:elb Ethan Blanton]. Note that
-designing a new protocol would **absolutely** require getting some crypto gurus
-on board!
+### XMPP Whiteboard Support
+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:
-## XMPP Modernization
+ * [XEP-0113]( Simple Whiteboarding
+ * [XEP-0284]( Shared XML Editing
- * omemo
- * carbons
+Currently we are unaware of any clients that implement XEP-0113, but
+[Gajim]( does implement XEP-0284.
-### Add Voice and Video to the SIP Plugin
+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
-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.
-## Twitch Plugin
-## Instagram Plugin
+### Twitch Plugin
-## 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
-Michael McConville about some things he identified during his 2015 Maintenance
-Hero project.
+[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.
-### 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.
+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.
-[wiki:grim 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.
+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.
-### Better UI
+### Instagram Plugin
-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.
+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
-### 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
+### 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.
+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.
-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
+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
@@ -122,22 +147,56 @@
Pidgin/libpurple adopt a protocol-agnostic interface for screen sharing as well
as working with us to get XMPP screen sharing capabilities in place.
-## Supporting Tools
+## 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.
-### Canary
-A libpurple UI that watches the status of the IM networks and reports it back to
-a reporting server. The clients would attempt to stay connected to the network
-and report on a set interval. Ideally there would be many of these running all
-over the world all reporting to a redundant server.
+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.
-## Plugin Website
+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
-### Perl Loader
+### Swift Plugin Examples
-### Swift Loader
+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
-### PHP 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.
-### Vala Example
+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.