Summer of Code 2016

Participation

The XSF is applying as a mentoring organisation for Google Summer of Code 2016. We will not know whether we're accepted until later in the year.

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, 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!

A list of teaser tasks is given here, but please join the MUC room mentioned above and discuss them there, where mentors will be able to help you and know what you're up to. There are different teasers for different codebases, and more teasers will be appearing here over the next couple of days.

• Swift: https://github.com/swift/swift/wiki/Contributing
• Smack: https://igniterealtime.org/issues/issues/?filter=11513
• MongooseIM: https://github.com/esl/MongooseIM/labels/GSoC-teaser-tasks
• SleekXMPP: http://www.xmpp-iot.org/gsoc/
• Conversations: https://github.com/siacs/Conversations/issues?q=is%3Aissue+is%3Aopen+label%3Agsoc-teaser
• XMPP-IoT Smack: https://github.com/codavide/Smack/issues

Project Ideas

Share User Location in Swift

• Software Project: Swift
• Software URL: http://swift.im/swift
• Software VCS URL: https://github.com/swift/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), which are mechanisms whereby people can publish data and other people can subscribe to receive notifications about changes in these data, but nothing in Swift itself uses these yet. In this project a user would implement User Location (http://xmpp.org/extensions/xep-0080.html) on top of these 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. If the student has other ideas of interesting ways in which location data can be useful to Swift's users, they can accordingly enhance this project.
• 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
• Difficulty: Moderate
• Implementation Language: C++
• Mentor: Edwin Mons, Tobias Markmann
• Contact Details: Chatroom at swift@rooms.swift.im

Network recovery in Swift

• Software Project: Swift
• Software URL: http://swift.im/swift
• Software VCS URL: https://github.com/swift/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: Sometimes network connections fail, and this is frustrating for users when they're chatting. It's more frustrating if the client doesn't recover. A student working on this project will look at ways of improving the experience around network failures for Swift. This would include support for XEP-0198 session resumption (where a client can tell the server to resume an old session when it reconnects), ways to detect MUC chatroom disconnections while the client is still connected, ways to detect a machine sleeping and waking etc.
• Expected results: A series of self-contained PRs to cover each enhancement, including:
  • XEP-0198 resume support
  • "Gone away" MUC detection (and recovery)
  • Sleep/wake discovery
  • "Network down' discovery
• Knowledge Prerequisite:
  • C++ fluency: 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
• Difficulty: Moderate
• Implementation Language: C++
• Mentor: Edwin Mons, Tobias Markmann
• Contact Details: Chatroom at swift@rooms.swift.im

Voice and Video in Swift

• Software Project: Swift
• Software URL: http://swift.im/swift
• Software VCS URL: https://github.com/swift/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: Jingle is an XMPP protocol that allows streaming of voice and video (amongst other things) for video calling. We'd like to support this in Swift. Some preliminary work has been done to use the libwebrtc library to add video calling, but this is at best prototype standard, and doesn't use Jingle. A student would take this work (or, possibly, start again with a new and more suitable library) and bring it to production quality with Jingle used for negotiation, such that video calls can be made from Swift.
• Expected results: A series of continual improvements, merged through the summer
  • Updating the branch to the latest libwebrtc
  • Merging the code with master, behind compilation flags such that it doesn't get enabled for normal users
  • Fixing issues with audio streaming in current implementation
  • Adding Jingle for negotiation
  • Enabling the feature by default on master
• Knowledge Prerequisite:
  • C++ fluency: Vital
  • Ability to create pleasant UIs: Vital
  • Ability to work with an underdocumented third-party library: 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
  • WebRTC experience: Desirable, can be learned
• Difficulty: Moderate
• Implementation Language: C++
• Mentor: Edwin Mons, Tobias Markmann
• Contact Details: Chatroom at swift@rooms.swift.im

Interoperability testtool for XMPP-IoT using SleekXMPP

• Software Project: SleekXMPP
• Software VCS URL: https://github.com/fritzy/SleekXMPP and https://github.com/joachimlindborg/SleekXMPP/tree/xep_0323_325
• Software Description: SleekXMPP is an XMPP library for Python 2.6/3.1+
• Brief explanation:' Python is a fantastic, easy to use prototyping tool, and is used in many Internet of things (IoT). The IoT extensions for XMPP is a interesting possibility to standardize in an open fashion the internet of things. But to be able to do this in a good way automatic testtools especially for interoperability is of utmost importence. In this project we will extend the xmpp-iot.org site with automatic testtools with inspiration from http://xmpp.net '
• Expected results: A series of continual improvements, merged through the summer
  • Choose python testing environment
  • Testcases xep323, 325 and others
  • Interoptestcases for node's and fields of devices
  • Produce testreports to users
  • Functionality to publish testresults on xmpp-iot.org
  • Automatic testing through github
• Knowledge Prerequisite:
  • Python experience: Good
  • XMPP Experience: Desirable, can be learned
  • Git experience: Desirable, can be learned
• Difficulty: Medium
• Implementation Languages: Python / HTML /javascript
• Mentor: : Joachim Lindborg joachim.lindborg@sust.se
• discussion details:
  • main talk around the assignment in the gsoc@muc.xmpp.org
  • http://mail.jabber.org/mailman/listinfo/iot
  • xmpp: sleek@conference.jabber.org

Adding XMPP-IoT to the openHAB smarthome project using Smack

• Software Project: Smack and OpenHAB
• Software URL: http://www.igniterealtime.org/projects/smack/ and http://www.openhab.org/
• Software VCS URL: https://github.com/igniterealtime/Smack and https://github.com/openhab/openhab
• Google doc design discussion document https://docs.google.com/document/d/1um3pEOwxQhCgV86hOSp9PTmJEIRK97onip7ePB-g9_g/edit?usp=sharing
• Software Description: OpenHAB is a 'smarthome' project, integrating almost any existing legacy protocols and gadgets to manage and control your home. By connecting the openHAB to XMPP and the extensions for Internet of Things (IoT) you can eliminate opening ports in your firewall to your local openHAB server and be able to share sensors and actuators in a secure way between HABs (Home Automation Busses). There is already a chat implementation based on Smack incorporated in the openHAB today. The project will extend that and implement OSGI bindings and actions to be able to handle sensor and actuator data.
• Expected results: The goal is not to implement 100% of each XEP but to get the minimal use case to start getting the openHAB connected over the XMPP-IoT network.
  • Implementation in smack for Reading things, as described in XEP-0323.
  • Implementation in smack for Writing to things, as described in XEP-0325.
  • A binding in OpenHAB for XMPP with smack.
  • optional implementation Provisioning, XEP-0324.
  • optional implementation Concentrator, XEP-0326
• Knowledge Prerequisite: Java and somewhat OSGI to understand the openHAB structure. XMPP knowledge as XEP for IoT are assuming already a good understanding of XMPP mechanisms.
• Difficulty: medium
• Implementation Languages: Java
• Mentor: : Davide Conzon (davide.conzon@ismb.it)

XMPP over WebSocket (RFC 7395) support for Smack

• Software Project: Smack
• Software URL: http://www.igniterealtime.org/projects/smack/
• Software VCS URL: https://github.com/igniterealtime/Smack
• Software Description: Smack is a highly modular and portable open source XMPP client library written in Java for JVMs and Android.
• Brief explanation: XMPP can be bound over TCP, via the BOSH technique or via WebSocket. Smack currently supports the former two but not WebSocket (specified in RFC 7395). The Goal of this GSOC project is to add WebSocket support to Smack
• Expected results: A series of continual improvements, merged through the summer
  • Websocket support for Android and Java
• Knowledge Prerequisite:
  • Java fluency: Vital
  • XMPP Experience: Desirable, can be learned
  • Git experience: Desirable, can be learned
• Difficulty: Moderate
• Implementation Language: Java
• Mentor: Florian Schmaus <flo@geekplace.eu>
• Contact Details: IRC channel #smack at freenode

Reliable File transfer API supporting Jingle for Smack

• Software Project: Smack
• Software URL: http://www.igniterealtime.org/projects/smack/
• Software VCS URL: https://github.com/igniterealtime/Smack
• Software Description: Smack is a highly modular and portable open source XMPP client library written in Java for JVMs and Android.
• Brief explanation: Smack's file transfer API has come to age. It currently only supports legacy XMPP file transfers and not the newer Jingle based ones. The Goal of this GSOC project is to add an easy to use file transfer API that provides a reliable ("always works") experience. Smack should determine the best mechanism for establishing a bytestream to a remote XMPP entity and eventually fallback to other mechanisms if the preferred ones fail.
• Expected results: A series of continual improvements, merged through the summer
  • A solid Jingle class model and implementation
  • A well designed file transfer API
• Knowledge Prerequisite:
  • Java fluency: Vital
  • XMPP Experience: Desirable, can be learned
  • Git experience: Desirable, can be learned
• Difficulty: Moderate
• Implementation Language: Java
• Mentor: Florian Schmaus <flo@geekplace.eu>
• Contact Details: IRC channel #smack at freenode

Dashboard for MongooseIM

• Software Project: MongooseIM
• Software URL: https://www.erlang-solutions.com/products/mongooseim.html
• Software VCS URL: https://github.com/esl/MongooseIM
• Software Description: A massively scalable XMPP/Jabber server written in erlang
• Brief explanation: MongooseIM comes with command line interface for administration and simple file for configuration. It would be nice to have a nice, modern-looking, easy to use, web-based administration, configuration, and reporting user interface
• Expected results:
  • A basic visual configuration interface: core, modules, etc.
  • A basic visual administration interface: kick/ban MUC participants, etc.
  • A basic visual reporting interface: number of users in DB, number of connected users, number of nodes, etc.
  • A basic config testing and compliancy interface
• Knowledge Prerequisite:
  • XMPP servers in general
  • erlang
  • HTML5, CSS3, JS
• Difficulty: Moderate
• Implementation Language:
• Mentor: Michal Piotrowski, Nicolas Vérité
• Contact Details: firstname dot lastname at erlang-solutions dot com

In-chat media for MongooseIM

• Software Project: MongooseIM
• Software URL: https://www.erlang-solutions.com/products/mongooseim.html
• Software VCS URL: https://github.com/esl/MongooseIM
• Software Description: A massively scalable XMPP/Jabber server written in erlang
• Brief explanation:
  • User Experience, UX:
    • File transfer: the use "file transfer" User Experience (UX) is about the sender inviting the receiver, and the receiver accepting the file, thus a synchronous UX, it is neede that both users are online, which happens seemingly not often. This UX have long-lived, feels really old-fashioned and just plainly obsolete: this a massive user feedback that is consistent since ages. It is however very clear that this synchronous invite/accept UX is very good only for a very specific use cases, such large files with no archive, and synchronous user experience. This is an unfair advantage over proprietary IM which have (almost) completely removed this UX. Please note that the first generation of IM (ICQ-like) had all this "file transfer" UX/feature with limitations (bandwitdh, censorship, etc.), this UX has disappeared starting from the 2nd gen (WhatsApp-like). There are some XMPP-specific issues with implementations having non-parity of protocols: the UX is then very painful since the sender invite and waits and waits and the transfers fails, sometimes with an error message, sometimes with a timeout, sometimes with no clear feedback.
    • In-chat media: (name may change) since the 2nd (WhatsApp-like), and 3rd (Slack-like) generation of IM (it stared around 10 years ago, an eternity in IM), the UX has totally, radically changed: from synchronous, it became asynchronous. The users expect to just send the files AND NOT WAIT or fail. And on the other hand, the users just want to receive files, whether they are connected or not at the time of the (background, silent) transfer (upload and download, not P2P). This is the UX we must target, "asynchronous send/receive on multi-device accounts", no more "synchronous invite/accept" mechanism. Obviously we need archiving and distribution on all devices in real time, when possible (Carbons and MAM?). The previews and/or thumbnails (whatever the name fits best) are a must-have feature, as the client don't have download the heavy files, but only lightweight versions.
  • Experimentations: we will start these experimentations with a very limited set of requirements, in order make it a GSoC success given the time and other constraints. The ultimate goal is to feed back some experience into the some implementors thinking and software, and obviously XEPs for larger audience when it's made ready.
  • Technology, specifications: for the underlying technology, the XEP "HTTP file upload"(XEP-0363) seems like pretty good first step in the right direction. Only it offers a very limited UX, since it is only about exchanging an long URL by text, sometimes dangerous (malevolent URLs). And it does not offer previews/thumbnails.
• Expected results:
  • For the sender:
    • Feature/value/goal:
      • IN ORDER TO send file immediately
      • AS A contemporary user of 2nd and 3rd generation IM (WhatsApp-like, Slack-like)
      • I WANT to select a file in the conversation screen and not care about the rest
    • Behaviour:
      • GIVEN I am in a conversation screen/tab/window (one-to-one, group chat)
      • WHEN I click/tap on a clipper (or whatever) icon/button
      • THEN my client sends it immediately (and takes care about bandwidth and energy consumption)
  • For the receiver:
    • Feature/value/goal:
      • IN ORDER TO receive files without hassles
      • AS A contemporary user of 2nd and 3rd generation IM (WhatsApp-like, Slack-like)
      • I WANT to just be notified, and have a thumbnail (with optional auto-download)
    • Behaviour:
      • GIVEN I have a configured XMPP client
      • WHEN I receive a file notification
      • THEN my XMPP client must show a thumbnail in the conversation (one-to-one, group chat)
  • The XMPP server will handle the persistent-media server (not relay type) part:
    • Upload protection: max file size, forbid/authorise some file types (blacklist/whitelist), max number of uploads per unit of time per bare JID in one-to-one conversations, max number of uploads per unit of time per bare JID per MUC
    • Storage: that can be any place, on bare-metal or cloud, preferably secure, in MAM (and/or PEP)
    • Thumbnails/previews: XEP-0231: Bits of Binary? XEP-0329: File Information Sharing?
    • Notification: "file available" notification with all the relevant info, with backwards compatibility
    • Download protection: the client should have an option to automatically download large files only on non-paid bandwidth (wifi, not mobile), the server must provide file size info
  • Feed the open standardisation process: propose a new protoXEP? Extend XEP-0363: HTTP File Upload? Or other option?
• Knowledge Prerequisite:
  • erlang
  • XMPP
  • File types, preview/thumbnails generation
  • Server-side, basic anti-abuse protection
  • Open standardisation process
• Difficulty: Moderate
• Implementation Language: erlang, and potentially anything that would fit better
• Mentor: Michal Piotrowski, Nicolas Vérité
• Contact Details: firstname dot lastname at erlang-solutions dot com

Service Administration for MongooseIM

• Software Project: MongooseIM
• Software URL: https://www.erlang-solutions.com/products/mongooseim.html
• Software VCS URL: https://github.com/esl/MongooseIM
• Software Description: A massively scalable XMPP/Jabber server written in erlang
• Brief explanation: implementation of XEP-0133: Service Administration to configure and manage MongooseIM via Ad-Hoc Commands
• Expected results:
  • A useful and handy set of Ad-Hoc Commands for Mongooseim configuration and management
• Knowledge Prerequisite:
  • XMPP servers in general
  • erlang
• Difficulty: Moderate
• Implementation Language: erlang
• Mentor: Michal Piotrowski, Nicolas Vérité
• Contact Details: firstname dot lastname at erlang-solutions dot com

Extended Stanza Addressing for MongooseIM

• Software Project: MongooseIM
• Software URL: https://www.erlang-solutions.com/products/mongooseim.html
• Software VCS URL: https://github.com/esl/MongooseIM
• Software Description: A massively scalable XMPP/Jabber server written in erlang
• Brief explanation: implementation of XEP-0033: Extended Stanza Addressing in MongooseIM
• Expected results:
  • Enable the users to send messages to multiple receivers
  • The receiver can reply to all, or remove/add some
  • All must work with Carbons and MAM
• Knowledge Prerequisite:
  • XMPP servers in general
  • erlang
• Difficulty: Moderate
• Implementation Language: erlang
• Mentor: Michal Piotrowski, Nicolas Vérité
• Contact Details: firstname dot lastname at erlang-solutions dot com

Implement encrypted calling in Conversations

• Software Project: Conversations
• Software URL: https://conversations.im
• Software VCS URL: https://github.com/siacs/Conversations
• Software Description: Conversations is a state of the art mobile instant messaging client for Android. It provides a modern user experience and is on top of the current developments in XMPP standards
• Brief explanation: P2P calling is a very popular addition to instant messaging. This project implements encrypted 1-on-1 calling based on Jingle in Conversations
• Expected results: A series of commits across the summer that add support for jingle calling in Conversations
  • Reimplement a proper Jingle stack in Conversation (the current one is only made for file transfer)
  • Implement voice calling over ICE and TURN
  • Implement a UI to make and accept calls
• Knowledge Prerequisite:
  • Java
  • Android UI (can be learned)
  • Git
• Difficulty: Moderate
• Implementation Language: Java / Android
• Mentor: Daniel Gultsch
• Contact Details: MUC at conversations@conference.siacs.eu

Implement client-side MIX in Conversations

• Software Project: Conversations
• Software URL: https://conversations.im
• Software VCS URL: https://github.com/siacs/Conversations
• Software Description: Conversations is a state of the art mobile instant messaging client for Android. It provides a modern user experience and is on top of the current developments in XMPP standards
• Brief explanation: MIX is the upcoming standard in group chats. This project would be one of the first implementations of this standard
• Expected results:
  • Allow users to subscribe to MIX channels
  • Display users in a channel
  • Implement UI to create new channels
• Difficulty: Moderate
• Implementation Language: Java / Android
• Mentor: Daniel Gultsch
• Contact Details: MUC at conversations@conference.siacs.eu

Port Conversations to Desktop using JavaFX and Babbler

• Software Project: Conversations
• Software URL: https://conversations.im
• Software VCS URL: https://github.com/siacs/Conversations
• Software Description: Conversations is a state of the art mobile instant messaging client for Android. It provides a modern user experience and is on top of the current developments in XMPP standards
• Brief explanation: Currently Conversations is only available on Android 4.0+ operating systems. However users want a similiar experience on their Desktop. This project is about creating a desktop variant of Conversations which aims to provide the same user experience.
• Expected results: It is impossible within the time frame of GSOC to copy the entire functionality of Conversations however the main features of Conversations can be boilt down to a few managable tasks
  • Create a simple UI with Java FX
  • Carbons support
  • HTTP upload and preview of Images
  • Infite history srcolling with local archive and MAM
  • OMEMO encryption
• Knowledge Prerequisite:
  • Java 8
  • JavaFX (can be learned)
  • Familiarity with Conversations on Android
  • Git
  • basic knowledge of XMPP
• Difficulty: Moderate
• Implementation Language: Java 8
• Mentor: Daniel Gultsch
• Contact Details: MUC at conversations@conference.siacs.eu

Pubsub enhancements in Prosody

• Software Project: Prosody
• Software URL: https://prosody.im/
• Software VCS URL: https://hg.prosody.im/
• Software Description: Prosody is an XMPP server, aiming to be lightweight, easy to use and easy to extend.
• Brief explanation: Prosody already supports basic pubsub (XEP-0060), but is lacking support for some advanced features. This project would be to add several key pubsub features to Prosody.
• Expected results:
  • From XEP-0060, the following features implemented in Prosody:
    • Node and item persistence
    • Node affiliation management
    • Multiple access models
    • Multiple publish models
• Knowledge Prerequisite:
  • Lua fluency: Desirable, can be learned easily with prior programming experience
  • XMPP Experience: Moderate understanding of XMPP and XML required, specifics can be learned
• Difficulty: Moderate
• Implementation Language: Lua
• Mentor: Matthew Wild (MattJ), Kim Alvefur (Zash)
• Contact Details: Chatroom at prosody@conference.prosody.im

EXI support in Prosody

• Software Project: Prosody
• Software URL: https://prosody.im/
• Software VCS URL: https://hg.prosody.im/
• Software Description: Prosody is an XMPP server, aiming to be lightweight, easy to use and easy to extend.
• Brief explanation: A fun project for lovers of protocols - add support for EXI streams so clients with resource constraints may connect to Prosody.
• Expected results:
  • A client may connect to Prosody using EXI, as defined in XEP-0322, instead of the conventional XML stream binding.
• Knowledge Prerequisite:
  • Lua fluency: Desirable, can be learned easily with prior programming experience
  • XMPP Experience: Moderate understanding of XMPP and XML required
• Difficulty: Advanced
• Implementation Language: Lua
• Mentor: Matthew Wild (MattJ), Kim Alvefur (Zash)
• Contact Details: Chatroom at prosody@conference.prosody.im

Priviledged Entity Support to Write Powerful External Components for ejabberd

• Software Project: ejabberd
• Software URL: https://www.ejabberd.im
• Software VCS URL: https://github.com/processone/ejabberd
• Software Description: A widely used and massively scalable XMPP/Jabber server written in Erlang
• Brief explanation:Many open source project want to extend XMPP server like ejabberd with external component. The de facto approach used today is XEP-0114: Jabber Component that ejabberd implements. It is however too limited in scope to implement powerful component that need to interact more deeply with the server. The goal of this project is to implement newer server extensions to XMPP that allowing more powerful component to run on ejabberd. This is good for open source in general as those components will also work with all other servers that conform to these protocols. The project will implement XEP-0356 Priviledged entity and XEP-0355 Namespace delegation.
• Expected results: The goal is to be able to use external components that leverage the new features of XEP-0356 and XEP-0355. The XMPP microblogging components SàT (Salut à Toi) will be used as a reference to valid the project result. The goal is to make those components fully run onto ejabberd with the newly implemented XEP. To fully support this component, a separate XEP will be implemented by community mentor to add missing Pubsub feature (XEP-0351 Recipient server-side filtering). That component, while not mandatory in the context of the project, will allow full validation of the behaviour on an existing full featured component.
• Knowledge Prerequisite:
  • XMPP servers in general
  • Erlang
• Difficulty: Moderate
• Implementation Language: Erlang
• Mentor: Mickaël Rémond (@mickael)
• Contact Details: mremond AT process-one.net

Server-to-Server Stream Management Support for ejabberd

• Software Project: ejabberd
• Software URL: https://www.ejabberd.im
• Software VCS URL: https://github.com/processone/ejabberd
• Software Description: A widely used and massively scalable XMPP/Jabber server written in Erlang
• Brief explanation:Stream Management is a feature that adds a reliability layer to communication between entity on an XMPP network. Stream Management is described in XEP-0198. Stream management is already implemented for client to server communication in ejabberd. However, adding the same level of reliability and robustness to server-to-server communication would make the whole XMPP network more robust.
• Expected results:
  • Implementation of XEP-0198 for server-to-server communication
  • ejabberd code may be refactored to allow reuse of client to server feature when possible.
  • Ability to cache outgoing messages for a given for a configurable amount of time to allow other end server to reboot or short unvailability will also be added (with correct overflow protection).
• Knowledge Prerequisite:
  • XMPP servers in general
  • Erlang
• Difficulty: Moderate
• Implementation Language: Erlang
• Mentor: Holger Weiss
• Contact Details: mremond AT process-one.net

Support for Things Discovery service in ejabberd

• Software Project: ejabberd
• Software URL: https://www.ejabberd.im
• Software VCS URL: https://github.com/processone/ejabberd
• Software Description: A widely used and massively scalable XMPP/Jabber server written in Erlang
• Brief explanation: The first step in getting Internet of Things over XMPP to take off is to be able to register things. Implementing XMPP-IOT protocol would allow Things to be installed, configured and claimed by their owner.
• Expected results:
  • Implement ejabberd server component conforming to XEP-0347 Internet of Things - Discovery
• Knowledge Prerequisite:
  • XMPP servers in general
  • Erlang
• Difficulty: Moderate
• Implementation Language: Erlang
• Mentor: Jérôme Sautret
• Contact Details: mremond AT process-one.net