pidgin/nest
Pull in the existing GSoC ideas from the wiki
+++ b/content/gsoc/ideas.md Thu Jan 17 00:08:08 2019 -0600
@@ -5,28 +5,77 @@
+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!)
+libpurple supports no native end-to-end encryption over XMPP. There are several XEPs 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!
+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.
+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 mmcc about some things he identified during his 2015 Maintenance Hero project ([wiki:mmcco]).
+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.
+[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.
+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.
+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.
+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.
+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 Slack.
+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.