--- a/hugo/content/development/gsoc/ideas.md Fri Feb 19 00:04:45 2021 -0600
+++ b/hugo/content/development/gsoc/ideas.md 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](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. -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+### 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. -### 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. -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.-### 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+[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. -### 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](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. -[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.
-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+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.
-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 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 +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 +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 @@ -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.
+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.
-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 `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
+### 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
+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 +We are confident at this time that this project would not contain enough work +for a full Google Summer of Code project. 