Summer of Code 2015

Participation

The XSF is applying to take part in GSoC 2015. We don't yet know if we'll be accepted.

Dates

The various dates for the programme can be found on the GSoC page

Overview

The XSF is (for GSoC) an umbrella organisation for various XMPP-related projects. As such, there's two tiers involved - the XSF itself, which is responsible for catherding mentors to submit ideas, choosing students etc., and the software projects themselves that then mentor students. Anyone interested in participating in GSoC as an XSF student can join the gsoc@muc.xmpp.org MUC room (FIXME: details to join...), where various mentors will be available to answer questions and generally help. Although each idea below lists a possible mentor, this MUC is the best place to start.

As there are several disparate projects here, there's variety across several codebases in different languages and with significantly different aims, so take a look through all the ideas - there should be something for everyone here :)

Teaser Tasks

To assess students applying to GSoC for XSF projects we'll strongly suggest that they submit some small patches to one of the XMPP projects in advance, as this gives us an idea of their general ability to interact with the projects and submit patches. These should only be an afternoon or two's work, and shouldn't be onerous!

For teaser task suggestions, please join the MUC room mentioned above.

Project Ideas

Openfire Message Archive Management support

• Software Project: Openfire
• Software URL: https://igniterealtime.org/projects/openfire/index.jsp
• Software VCS URL: https://github.com/igniterealtime/Openfire
• Software Description: Openfire is an XMPP server. It is configured through a web-based admin interface and used in enterprise, military, and government environments.
• Brief explanation: Openfire has supported the older, and more complex, XEP-0136 Archiving for many years, but more modern clients have tended to use XEP-0313, also known as MAM. MAM is a small subset of functionality from XEP-0136, and as such the storage etc should be largely handled already.
• Expected results: XEP-0313 support as PR.
• Knowledge Prerequisite: Reasonable knowledge of Git, Java and XMPP. Communicating with the team and the XSF Standards SIG will be essential.
• Implementation Languages: Java
• Mentor: Dave Cridland <dave@cridland.net>
• Contact Details: XEP-0045 chatroom at open_chat@conference.igniterealtime.org

Openfire Simple Communications Blocking support

• Software Project: Openfire
• Software URL: https://igniterealtime.org/projects/openfire/index.jsp
• Software VCS URL: https://github.com/igniterealtime/Openfire
• Software Description: Openfire is an XMPP server. It is configured through a web-based admin interface and used in enterprise, military, and government environments.
• Brief explanation: Openfire has supported the older, and more complex, XEP-0019 Block Lists for many years, but more modern clients have tended to use XEP-0191. This is a small subset of functionality from XEP-0019, and as such the existing code may be reusable.
• Expected results: XEP-0191 support as PR.
• Knowledge Prerequisite: Reasonable knowledge of Git, Java and XMPP. Communicating with the team and the XSF Standards SIG will be essential.
• Implementation Languages: Java
• Mentor: Dave Cridland <dave@cridland.net>
• Contact Details: XEP-0045 chatroom at open_chat@conference.igniterealtime.org

XMPP MUC support for ircd-seven

• Software Project: ircd-seven
• Software URL: https://freenode.net/seven.shtml
• Software VCS URL: https://github.com/freenode/ircd-seven
• Software Description: freenode's ircd-seven is the server code behind freenode's IRC network, that provides discussion facilities for a variety of Free and Open Source Software communities, not-for-profit organizations, and related communities.
• Brief explanation: The goal of this project is to add the possibility to interact with all of freenode's channels using the XMPP Multi-User Chat protocol as described in XEP-0045. This should be done as a service gateway that's an extension into the particular ircd implementation used by the freenode network: ircd-seven. It would accept XMPP server-to-server connections and present each channel as a MUC room transparently and bidirectional.
• Expected results: An XMPP extension to ircd-seven
• Knowledge Prerequisite:
• Implementation Languages: C
• Mentor: Arc Riley
• Contact details: #freenode-seven on freenode

XMPP servers performance comparator

• Software Project: XMPP server performance comparison tool
• Software URL: Not specified yet
• Software VCS URL: Not specified yet
• Software Description: This is completely new project aiming to compare performance of most popular XMPP servers MongooseIM, ejabberd, Prosody, OpenFire, Tigase and what not
• Brief explanation: The main goal of this project is to specify some common load test scenarios and automate the process of load testing various XMPP servers. This tool should automate server deployments based on publicly available scripts and generate specified load.
• Expected results: A tool running load tests against specified XMPP servers and producing comparison.
• Knowledge Prerequisite: Erlang, Python, load testing, docker
• Implementation Languages: Erlang, Python
• Mentor: Micha? Piotrowski
• Contact details: michal.piotrowski@erlang-solutions.com, mongoose-im@erlang-solutions.com

Add support for XMPP Serverless Messaging (XEP-174) to Smack

• Software Project: Smack
• Software URL: http://www.igniterealtime.org/projects/smack/
• Software VCS URL: https://github.com/igniterealtime/Smack
• Software Description: An XMPP Client Library written in Java for JVMs and Android.
• Brief explanation: Since 2009 there exists a patchset which adds serverless messaging (link-local) support to Smack. Unfortunately the patch design is no longer compatible with recent Smack versions and thorough examination has shown that it needs major rewriting (basically from scratch) in order to fulfill the requirements for inclusion in the 'master' branch. The 2009er patch should not be used as a starting point for the new code. But analyzing its weaknesses and problems will sure help providing a better end-result. Furthermore Guardian Project's ChatSecure uses an old version of aSmack with the serverless messaging patch. They need support for XEP-174 in order to switch from the old aSmack version they currently use to an newer Smack version. This also means that the code has to be Android compatible.
• Expected results: Implement support for XEP-174 (http://www.xmpp.org/extensions/xep-0174.html) in Smack, fulfilling the following requirements:
  • Design and implement an easy to use Smack API for serverless

messaging, try re-use existing Smack code wherever possible

• • Add smack-serverlesss subproject with XMPPLLConnection
  • XMPPLLConnection should manage a set of XMPPLLStreams (not the case

with the 2009 patch)

• • Multiple XMPPLLConnections should be supported on the same host (not

the case with the 2009 patch)

• • Use java.nio to manage connections
  • Use JmDNS for multicast DNS (smack-serverless-jmdns)
  • Use NsdManager on Android for multicast DNS (smack-servless-android)
• Knowledge Prerequisite: Java, Android,
• Implementation Languages: Java
• Mentor: Florian Schmaus
• Contact details:
  • IRC: #smack (freenode)
  • MUC: open_chat@conference.igniterealtime.org
  • Smack Dev Forum: https://community.igniterealtime.org/community/developers/smack
• More Info about this project idea can be found at https://github.com/igniterealtime/Smack/wiki/Smack-Jobs#create-xmppllconnection-for-serverless-link-local-messaging-xep-174