Summer of Code 2015

From XMPP WIKI
Jump to navigation Jump to search

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

XMPP is an Internet protocol used in many fields, such as the Internet of Things, chat applications, voice and video calls, etc. It's what Google Talk uses, Whatsapp uses an XMPP-derivative protocol, Google Hangouts uses some aspects of XMPP internally, and as well as end-users it's used extensively by enterprises and governments.

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 (web client), 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

Swift Geolocation and Contact Finding

  • Software Project: Swift
  • Software URL: http://swift.im/swift
  • Software VCS URL: http://swift.im/git/swift/
  • Software Description: Swift is a desktop XMPP chat client. It aims to prioritise usability and usefulness to users in preference to an extensive niche feature list.
  • Brief explanation: Swiften, the XMPP library driving Swift, supports pubsub (http://xmpp.org/extensions/xep-0060.html) and PEP (http://xmpp.org/extensions/xep-0163.html), but nothing in Swift itself uses these yet. In this project a user would implement User Location (http://xmpp.org/extensions/xep-0080.html) in Swiften, and use this in Swift to expose the user's location to their contacts, allow them to see the location of their contacts, and to somehow monitor which contacts are near to the user.
  • Expected results:
    • User Location support in Swiften
    • API for providing location providers to Swift
    • Location provider implementations
    • Publishing location in Swift
    • Consuming others' published location in Swift
    • Map rendering of locations in Swift
    • Rendering of 'nearby' contacts in Swift
  • Knowledge Prerequisite:
    • C++ fluency: Vital
    • Ability to create pleasant UIs: Vital
    • Qt Experience: Desirable, can be learned
    • XMPP Experience: Desirable, can be learned
    • Git experience: Desirable, can be learned
    • Boost experience: Desirable, can be learned
  • Implementation Language: C++
  • Mentor: Kevin Smith, Tobias Markmann
  • Contact Details: Chatroom at swift@rooms.swift.im

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 Language: 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 Language: 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 Language: 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 Language: Java
  • Mentor: Florian Schmaus
  • Contact details:
  • 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


Add support for DNSSEC to Smack via MiniDNS

  • Software Project: MiniDNS
  • Software URL: https://github.com/rtreffer/minidns
  • Software VCS URL: https://github.com/rtreffer/minidns
  • Software Description: A minimal DNS client library for Android and JVMs
  • Brief explanation: MiniDNS is a DNS client library, which allows Android Apps and Java programs to resolve DNS resource records (RR). On Android, some resource records could not be resolved using only the Android API, for example DNS SRV RRs. Which was one of the main reasons MiniDNS was invented. Adding support for DNSSEC would be the logical next step to improve the security of the software using MiniDNS. Since MiniDNS runs also on JavaSE runtimes, i.e. it is not an Anroid exclusive library, all applications using it would also become DNSSEC enabled. Once MiniDNS is able to perform DNSSEC, it should be used in smack-resolver-minidns for DNS resolution. See also: https://github.com/rtreffer/minidns/issues/7. The list of Android Apps und Java programs that would benefit from a DNSSEC enabled MiniDNS include:
  • Expected results:
    • Add the ability to perform recursive DNS lookups (required for DNSSEC)
    • Add DNSSEC support to MiniDNS
    • Use Java/Android crypto primitives where possible
    • Bump MiniDNS version in smack-resolver-minidns to use the MiniDNS-with-DNSSEC version.
  • Knowledge Prerequisite: Java, DNS, DNSSEC
  • Implementation Languages: Java
  • Mentor: Florian Schmaus (Smack), Dominik Schürman (OpenKeychain)
  • Contact details:
    • IRC: #smack (freenode)
    • MUC: open_chat@conference.igniterealtime.org


Provisioning and registry of Things (IoT) for ejabberd

  • Software Project: ejabberd
  • Software URL: http://www.ejabberd.im
  • Software VCS URL: https://github.com/processone/ejabberd
  • Software Description: ejabberd is an XMPP server written in Erlang
  • Brief explanation: ejabberd is an open source Jabber/XMPP server designed from the ground up to be the building bricks of highly critical messaging systems. Written in Erlang programming language, ejabberd is cross-platform, fault-tolerant, clusterable, very modular and highly versatile. It can be extending in other programming languages, such as Elixir. Designed to be massively scalable, it is widely used to power web scale deployments across many software industry: Mobile messaging, Social Networks, Gaming, Internet of Things, …
  • Expected results:

Internet of Things support is becoming a growing source of interest for XMPP and many extensions have been designed to facilitate this use case. However, to get real life feedback and improve our XMPP specifications, we need to experiment with working code. A consistent package of XEP support for IoT extension for ejabberd would be to implement as part of this project:

    • Things registry for ejabberd, as described in XEP-0347.
    • Things provisionning for ejabberd, as described in XEP-0324.

The goal is not to implement 100% of each XEP but to get the minimal use case to start getting more things connected to XMPP (through ejabberd support).

  • Knowledge Prerequisite: Erlang, Elixir or any functional programming language. XMPP knowledge as XEP for IoT are assuming already a good understanding of XMPP mechanisms.
  • Implementation Languages: Erlang / Elixir
  • Mentor: : Mickaël Rémond (ejabberd / Tsung)
  • Contact details:
    • MUC: ejabberd@conference.conference.jabber.ru
    • MUC: ejabberd@conference.process-one.net
Retrieved from "https://wiki.xmpp.org/web/index.php?title=Summer_of_Code_2015&oldid=7078"