diff --git a/hugo/content/development/gsoc/ideas.md b/hugo/content/development/gsoc/ideas.md
--- a/hugo/content/development/gsoc/ideas.md
+++ b/hugo/content/development/gsoc/ideas.md
@@ -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 this 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
 
-### Encryption for XMPP
+### 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
-on board!
+### 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 use 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](https://xmpp.org/extensions/xep-0113.html) Simple Whiteboarding
+ * [XEP-0284](https://xmpp.org/extensions/xep-0284.html) Shared XML Editing
 
- * omemo
- * carbons
+Currently we are unaware of any clients 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.
 
 ## 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
+
+[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 there 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.
 
-## Twitch Plugin
+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 consider it an error if you send the exact same message within
+30 seconds of the previous message.
 
 ## Instagram 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.
-
-### 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.
-
-[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.
-
-### Better UI
-
-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.
+Instragram is a popular social network that has chat capabilities.  It would
+prove benefical 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 support 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 not 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.
 
-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.
+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
 
@@ -124,20 +149,56 @@
 
 ## Supporting Tools
 
-### 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.
+## 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.
 
-## Plugin Website
+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 provided 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 bennefit of allowing plugins to auto
+update.
 
 ## 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](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
 
-### PHP 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.
 
-### Vala Example
+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.
