Summer of Code 2015

From XMPP WIKI
Revision as of 14:45, 20 February 2015 by Kevin (talk | contribs)
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

Share User Location in Swift

  • 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 protocol support in Swiften
    • API for providing location providers to Swift
    • Location provider implementations
    • Publishing location in Swift
    • Consuming others' published location in Swift
    • Roster tooltips giving contacts' locations
    • 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: Server-side message archiving allows a user's client to query the server for their previous messages. 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 pull request on github.
  • 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-0016 Block Lists for many years, but more modern clients have tended to use XEP-0191. This is a small subset of functionality from XEP-0016, and as such the existing code may be reusable.
  • Expected results: XEP-0191 support as pull request on github.
  • 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 to be the building bricks of critical messaging systems. Written in the Erlang programming language, ejabberd is cross-platform, fault-tolerant, clusterable and modular. It can be extended in other programming languages, such as Elixir. It is designed to be massively scalable, and is used to power deployments across sectors: 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


MUC to Channels translat-o-matic

  • Software Project: Buddycloud
  • Software URL: http://buddycloud.com
  • Software VCS URL: https://github.com/buddycloud
  • Software Description: Buddycloud helps developers build social communication apps.
  • Brief explanation: The MUC<->buddycloud translat-o-matic brings a MUC-based frontend to Buddycloud channels. Users can use their favourite MUC client to post, comment and follow a buddycloud channel. Media should be displayed as a HTML links.
  • Expected results: As many MUC features should be possible (posting to a MUC room, fetching posts and more.)
  • Knowledge Prerequisite: extensive C++ knowledge, TLS implementations
  • Implementation Languages: Python or Javascript.
  • Mentor: Simon Tennant
  • Contact details: https://groups.google.com/forum/#!forum/buddycloud-dev


axolotl support for Conversations

  • Software Project: Conversations
  • Software URL: http://conversations.im
  • Software VCS URL: https://github.com/siacs/Conversations
  • Software Description: Conversations is an XMPP client for Android that features optimizations for the use in a mobile environment like message synchronization across devices and battery optimization techniques. Conversations tries to be accessible to an audience that has no prior experience with XMPP by eliminating a lot of configuration options and replacing them with sane defaults or automation.
  • Brief explanation: Conversations already comes with a choice of end-to-end encryptions. Currently the user can decide between OTR and openPGP which unfortunately both have some downsides. With OTR enabled, for example, messages can no longer be synced across devices. The axolotl encryption protocol, which is currently used by the TextSecure client, can solve these problems as described here. There is already a java library that implements axolotl for Android. Conversations itself comes with a lot of features that make an implementation easier like general crypto support (UI elements), message synchronization (carbon copies, message archive management) and PEP support (can be used to publish the keys)
  • Expected results: Implement libaxolotl support in Conversations. Come up with a way to send axolotl encrypted messages in XMPP messages. Implement a mechanism to publish what axolotl calls PreKeys over PEP or another suitable mechanism and have others users fetch those keys. Make this work with carbon messages (=multiple receiving clients). Not part of GSOC but this proof of concept implementation will later be used to propose a XEP and allow other clients to use the same standard. Potential participants won't be expected to be part of this standardization process but they will definitely have the chance to.
  • Knowledge Prerequisite: XMPP, Java, a bit of Android (you probably won't have too much contact with Android specifics because the UI work is already done for the most part), some awareness for crypto and security. You don't have to be a cryptologist since you will be using a library for that but some basic crypto knowledge might make some things easier.
  • Implementation Languages: Java
  • Mentor: Daniel Gultsch - Maintainer of Conversations
  • Contact details: Chatroom at conversations@conference.siacs.eu


Extend Stroke Implementation

  • Software Project: Stroke
  • Software URL: http://swift.im/stroke
  • Software VCS URL: http://swift.im/git/stroke/
  • Software Description: Stroke is a Java port of the Swiften(C++) XMPP library, using the same asynchronous and signal-based design.
  • Brief explanation: Stroke is a port of Swiften, but it is incomplete and not all Swiften updates have been applied to it. This straightforward project would involve a student working through the Stroke and Swiften source and ensuring that Stroke has feature parity with Swiften, and that the implementations and API in Stroke are current with respect to their Swiften counterparts.
  • Expected results:
    • New implementations for missing functionality
    • Updated implementations to match functionality that has changed in Swiften since the initial port
  • Knowledge Prerequisite:
    • Java: Vital
    • C++: Read-only (only needs to read Swiften, not write it)
    • XMPP Experience: Desirable, can be learned
    • Git experience: Desirable, can be learned
    • Boost experience: Desirable, but only for reading the C++ source of Swiften
  • Implementation Language: Java
  • Mentor: Kevin Smith
  • Contact Details: Chatroom at swift@rooms.swift.im
Retrieved from "https://wiki.xmpp.org/web/index.php?title=Summer_of_Code_2015&oldid=7091"