Difference between revisions of "Summer of Code 2015"

From XMPP WIKI
Jump to navigation Jump to search
(Restored from backup.)
 
(31 intermediate revisions by 7 users not shown)
Line 1: Line 1:
= Participation =
= Participation =
The XSF is applying to take part in GSoC 2015. We don't yet know if we'll be accepted.
 
The XSF has been accepted as a mentoring organisation for Google Summer of Code 2015.


== Dates ==
== Dates ==
The various dates for the programme can be found on the [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 GSoC page]  
 
The various dates for the programme can be found on the [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 GSoC page]


== Overview ==
== 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.
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 ([https://jappix.com/?r=gsoc@muc.xmpp.org 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.
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 ([https://jappix.com/?r=gsoc@muc.xmpp.org 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 :)
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 ==
== 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!
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.
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
* '''MUC-Channels Transmatomatic''': https://gist.github.com/imaginator/b244bd157083a97028d0
* '''Reference push notification server''': https://gist.github.com/imaginator/b244bd157083a97028d0
* '''ejabberd''': https://www.ejabberd.im/node/24794
* '''Smack''': https://github.com/igniterealtime/Smack/wiki/GSOC-2015
* '''Conversations''': https://github.com/siacs/Conversations/blob/development/todo.md
* '''SleekXMPP and openHAB''': http://xmpp-iot.github.io/gsoc/
* '''Openfire''': https://github.com/igniterealtime/Openfire/wiki/Getting-Started
* '''ircd-seven MUC support''': [[Summer_of_Code_2015_IRCd]]
* '''Stroke''': https://github.com/swift/stroke/wiki/Contributing


= Project Ideas =
= Project Ideas =


=== Share User Location in Swift===
=== Share User Location in Swift===
* '''Software Project:''' Swift
* '''Software Project:''' Swift
* '''Software URL:''' http://swift.im/swift
* '''Software URL:''' http://swift.im/swift
* '''Software VCS URL:''' http://swift.im/git/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.
* '''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.
* '''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:'''
* '''Expected results:'''
** User Location protocol support in Swiften
** User Location protocol support in Swiften
Line 41: Line 57:
** '''Git experience''': Desirable, can be learned
** '''Git experience''': Desirable, can be learned
** '''Boost experience''': Desirable, can be learned
** '''Boost experience''': Desirable, can be learned
* '''Difficulty:''' Moderate
* '''Implementation Language:''' C++
* '''Mentor:''' Kevin Smith, 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:''' Kevin Smith, Tobias Markmann
* '''Contact Details:''' Chatroom at swift@rooms.swift.im
=== Multi-account support 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:''' Swift has an interface designed for connecting to a single account, for simplicity (a goal of Swift's). Some users wish to connect to several servers at once, and the current solution of "run multiple copies of Swift" is unsatisfying. A student working on this project would project a pleasing user experience allowing users to connect to several accounts in a single Swift, without losing the simplicity that comes from the current single-account approach.
* '''Expected results:'''
** Logging in with multiple accounts
** A single roster window, showing each account's roster (split)
** Merged but identifyable bookmarks and recent chats
** Ability to add a contact to any account
** Ability to join MUCs with any account
** Ability to perform other actions (e.g. user search) with any account
** Setting cross-account things in only one place - e.g. a single status setter for all sessions
** Solving issues anywhere else a user might need to choose their account before an action.
* '''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:''' Easy code, challenging UI
* '''Implementation Language:''' C++
* '''Implementation Language:''' C++
* '''Mentor:''' Kevin Smith, Tobias Markmann
* '''Mentor:''' Kevin Smith, Tobias Markmann
* '''Contact Details:''' Chatroom at swift@rooms.swift.im
* '''Contact Details:''' Chatroom at swift@rooms.swift.im


=== Voice and Video in Swift===


=== Openfire Message Archive Management support ===
* '''Software Project:''' Swift
* '''Software Project:''' Openfire
* '''Software URL:''' http://swift.im/swift
* '''Software URL:''' https://igniterealtime.org/projects/openfire/index.jsp
* '''Software VCS URL:''' https://github.com/swift/swift
* '''Software VCS URL:''' https://github.com/igniterealtime/Openfire
* '''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.
* '''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:''' 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.
* '''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:''' A series of continual improvements, merged through the summer
* '''Expected results:''' XEP-0313 support as pull request on github.
** Updating the branch to the latest libwebrtc
* '''Knowledge Prerequisite:''' Reasonable knowledge of Git, Java and XMPP. Communicating with the team and the XSF Standards SIG will be essential.
** Merging the code with master, behind compilation flags such that it doesn't get enabled for normal users
* '''Implementation Language:''' Java
** Fixing issues with audio streaming in current implementation
* '''Mentor:''' Dave Cridland <dave@cridland.net>
** Adding Jingle for negotiation
* '''Contact Details:''' XEP-0045 chatroom at open_chat@conference.igniterealtime.org
** 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:''' Kevin Smith, Tobias Markmann
* '''Contact Details:''' Chatroom at swift@rooms.swift.im


=== Openfire New Protocol support ===


=== Openfire Simple Communications Blocking support ===
* '''Software Project:''' Openfire
* '''Software Project:''' Openfire
* '''Software URL:''' https://igniterealtime.org/projects/openfire/index.jsp
* '''Software URL:''' https://igniterealtime.org/projects/openfire/index.jsp
* '''Software VCS URL:''' https://github.com/igniterealtime/Openfire
* '''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.
* '''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.
* '''Brief explanation:''' As one of the oldest currently deployed servers, Openfire lacks support for the newer protocols. This project aims to add new protocol support to existing infrastructure; this will modernize Openfire's capabilities in three key ways:
* '''Expected results:''' XEP-0191 support as pull request on github.
** 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 standard for 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.
** In addition, MAM requests may be directed to a XEP-0045 chatroom; again, Openfire already stores MUC archives in the database, so querying these should be possible. MAM support for chatrooms is considered relatively bleeding-edge support, so testing will be a challenge.
** Finally, Simple Communication Blocking, XEP-0191 presents a simpler blocking interface than the older XEP-0019 which is supported by Openfire. Again, the blocking infrastructure already exists, though in this case it may be simpler to avoid the reuse.
* '''Expected results:''' Each item should be presented as a pull request on GitHub, ready for merge, with tests where appropriate.
* '''Knowledge Prerequisite:''' Reasonable knowledge of Git, Java and XMPP. Communicating with the team and the XSF Standards SIG will be essential.
* '''Knowledge Prerequisite:''' Reasonable knowledge of Git, Java and XMPP. Communicating with the team and the XSF Standards SIG will be essential.
* '''Difficulty:''' Easy
* '''Implementation Language:''' Java
* '''Implementation Language:''' Java
* '''Mentor:''' Dave Cridland <dave@cridland.net>
* '''Mentor:''' Dave Cridland &lt;dave@cridland.net&gt;
* '''Contact Details:''' XEP-0045 chatroom at open_chat@conference.igniterealtime.org
* '''Contact Details:''' XEP-0045 chatroom at open_chat@conference.igniterealtime.org


=== XMPP MUC support for ircd-seven ===


=== XMPP MUC support for ircd-seven ===
* '''Software Project:''' ircd-seven
* '''Software Project:''' ircd-seven
* '''Software URL:''' https://freenode.net/seven.shtml
* '''Software URL:''' https://freenode.net/seven.shtml
* '''Software VCS URL:''' https://github.com/freenode/ircd-seven
* '''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.
* '''Software Description:''' freenode's ircd-seven is the server code behind freenode's IRC network, which 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.
* '''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
* '''Expected results:'''
* '''Knowledge Prerequisite:'''
** XMPP federation (Server to Server / S2S) support
** Basic XEP-0045 user join protocol support
** Mapping of further XEP-0045 features to IRC, such as nickname registration.
* '''Knowledge Prerequisite:''' Any knowledge of IRC or XMPP will be beneficial but can be learned during the summer. Otherwise C fluency is required.
* '''Difficulty:''' Moderate
* '''Implementation Language:''' C
* '''Implementation Language:''' C
* '''Mentor:''' Arc Riley
* '''Mentor:''' Arc Riley
* '''Contact details:''' #freenode-seven on freenode
* '''Contact details:''' #copyleftgames 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 ===


=== Add support for XMPP Serverless Messaging (XEP-174) to Smack ===
* '''Software Project:''' Smack
* '''Software Project:''' Smack
* '''Software URL:''' http://www.igniterealtime.org/projects/smack/
* '''Software URL:''' http://www.igniterealtime.org/projects/smack/
Line 113: Line 190:
** Use NsdManager on Android for multicast DNS (smack-servless-android)
** Use NsdManager on Android for multicast DNS (smack-servless-android)
* '''Knowledge Prerequisite:''' Java, Android,
* '''Knowledge Prerequisite:''' Java, Android,
* '''Difficulty:''' Moderate
* '''Implementation Language:''' Java
* '''Implementation Language:''' Java
* '''Mentor:''' Florian Schmaus
* '''Mentor:''' Florian Schmaus
Line 121: Line 199:
* 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
* 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 ===


=== Add support for DNSSEC to Smack via MiniDNS ===
* '''Software Project:''' MiniDNS
* '''Software Project:''' MiniDNS
* '''Software URL:''' https://github.com/rtreffer/minidns
* '''Software URL:''' https://github.com/rtreffer/minidns
Line 137: Line 215:
** Bump MiniDNS version in smack-resolver-minidns to use the MiniDNS-with-DNSSEC version.
** Bump MiniDNS version in smack-resolver-minidns to use the MiniDNS-with-DNSSEC version.
* '''Knowledge Prerequisite:''' Java, DNS, DNSSEC
* '''Knowledge Prerequisite:''' Java, DNS, DNSSEC
* '''Difficulty:''' Hard
* '''Implementation Languages:''' Java
* '''Implementation Languages:''' Java
* '''Mentor:''' Florian Schmaus (Smack), Dominik Schürman (OpenKeychain)
* '''Mentor:''' Florian Schmaus (Smack), Dominik Schürman (OpenKeychain)
Line 143: Line 222:
** MUC: open_chat@conference.igniterealtime.org
** MUC: open_chat@conference.igniterealtime.org


=== Provisioning and registry of Things (IoT) for ejabberd ===


=== Provisioning and registry of Things (IoT) for ejabberd ===
* '''Software Project:''' ejabberd
* '''Software Project:''' ejabberd
* '''Software URL:''' http://www.ejabberd.im
* '''Software URL:''' http://www.ejabberd.im
Line 152: Line 231:
* '''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:
* '''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 registry for ejabberd, as described in XEP-0347.
** Things provisionning for ejabberd, as described in XEP-0324.  
** 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).
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.
* '''Knowledge Prerequisite:''' Erlang, Elixir or any functional programming language. XMPP knowledge as XEP for IoT are assuming already a good understanding of XMPP mechanisms.
* '''Difficulty:''' Hard
* '''Implementation Languages:''' Erlang / Elixir
* '''Implementation Languages:''' Erlang / Elixir
* '''Mentor:''' : Mickaël Rémond (ejabberd / Tsung)
* '''Mentor:''' : Mickaël Rémond (ejabberd / Tsung)
* '''Contact details:'''
* '''Contact details:'''
** MUC: ejabberd@conference.conference.jabber.ru
** MUC: ejabberd@conference.conference.jabber.ru
** MUC: ejabberd@conference.process-one.net
** MUC: ejabberd@conference.process-one.net


=== MUC to Channels translat-o-matic ===


=== MUC to Channels translat-o-matic ===
* '''Software Project:''' Buddycloud
* '''Software Project:''' Buddycloud
* '''Software URL:''' http://buddycloud.com
* '''Software URL:''' http://buddycloud.com
* '''Software VCS URL:''' https://github.com/buddycloud
* '''Software VCS URL:''' https://github.com/buddycloud
* '''Software Description:''' Buddycloud helps developers build social communication apps.
* '''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.  
* '''Brief explanation:''' The MUC&lt;-&gt;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.)
* '''Expected results:''' As many MUC features as possible should be mapped, including:
* '''Knowledge Prerequisite:''' extensive C++ knowledge, TLS implementations
** Joining a room
* '''Implementation Languages:''' Python or Javascript.  
** Faking occupant presence in a room
** Receiving messages from a room
** Posting messages to a room
* '''Knowledge Prerequisite:'''
** Python or Javascript required
** XMPP desirable
* '''Difficulty:''' Moderate
* '''Implementation Languages:''' Python or Javascript.
* '''Mentor:''' Simon Tennant
* '''Mentor:''' Simon Tennant
* '''Contact details:''' https://groups.google.com/forum/#!forum/buddycloud-dev
* '''Contact details:''' https://groups.google.com/forum/#!forum/buddycloud-dev


=== Reference Push Notification Server ===
* '''Software Project:''' Buddycloud
* '''Software URL:''' https://github.com/buddycloud
* '''Software VCS URL:''' Project not specified yet.
* '''Software Description:''' Build a reference implementation of the new Push Notification XEP.
* '''Brief explanation:''' The newly defined [http://xmpp.org/extensions/inbox/push.html Push XEP] offers a great oppertunity for XMPP to support not-always-online mobile devices. This is an area where XMPP has been weak and it's urgent that we get a workable solution that can support app developers. The Buddycloud team has already built a [https://github.com/buddycloud/buddycloud-pusher push notification service] however this contains many features specific to the Buddycloud project and it would be better to have a spec-compliant server and one that can service non-Buddycloud use cases using the Push XEP.
You would be responsible for designing, building and testing the reference implementation and to support plugins for each of the major push platforms. To test, you would need to build a plugin to support at least one of the major mobile platforms push services. You would probably also need to build a small reference application for testing the contents of inbound pushes. Success in this project will require working with and around some of the remaining ambiguity in the current specification, and hopefully providing valuable input back into the current spec to make it stronger.
This should run as an XMPP component and be XMPP server agnostic.
* '''Knowledge Prerequisite''': Strong XMPP, Android or iOS desirable (for building a reference reciver app)
* '''Difficulty:''' moderate to difficult
* '''Implementation Languages:''' Java or Python
* '''Mentor:''' Simon Tennant
* '''Contact details:''' https://groups.google.com/forum/#!forum/buddycloud-dev


=== axolotl support for Conversations ===
=== axolotl support for Conversations ===
* '''Software Project:''' Conversations
* '''Software Project:''' Conversations
* '''Software URL:''' http://conversations.im
* '''Software URL:''' http://conversations.im
* '''Software VCS URL:''' https://github.com/siacs/Conversations
* '''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.
* '''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 [https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/ here]. There is already a java library that implements [https://github.com/WhisperSystems/libaxolotl-android 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)
* '''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 [https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/ here]. There is already a java library that implements [https://github.com/WhisperSystems/libaxolotl-android 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.
* '''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.
* '''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.
* '''Difficulty:''' Moderate
* '''Implementation Languages:''' Java
* '''Implementation Languages:''' Java
* '''Mentor:''' Daniel Gultsch - Maintainer of Conversations
* '''Mentor:''' Daniel Gultsch - Maintainer of Conversations
* '''Contact details''': Chatroom at conversations@conference.siacs.eu
* '''Contact details''': Chatroom at conversations@conference.siacs.eu


=== Extend Stroke Implementation ===


=== Extend Stroke Implementation ===
* '''Software Project:''' Stroke
* '''Software Project:''' Stroke
* '''Software URL:''' http://swift.im/stroke
* '''Software URL:''' http://swift.im/stroke
* '''Software VCS URL:''' http://swift.im/git/stroke/
* '''Software VCS URL:''' https://github.com/swift/stroke
* '''Software Description:''' Stroke is a Java port of the Swiften(C++) XMPP library, using the same asynchronous and signal-based design.
* '''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.
* '''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.
Line 203: Line 311:
** '''Git experience''': Desirable, can be learned
** '''Git experience''': Desirable, can be learned
** '''Boost experience''': Desirable, but only for reading the C++ source of Swiften
** '''Boost experience''': Desirable, but only for reading the C++ source of Swiften
* '''Difficulty:''' Easy
* '''Implementation Language:''' Java
* '''Implementation Language:''' Java
* '''Mentor:''' Kevin Smith
* '''Mentor:''' Kevin Smith
* '''Contact Details:''' Chatroom at swift@rooms.swift.im
* '''Contact Details:''' Chatroom at swift@rooms.swift.im
=== Prototyping tools, for Internet of Things Using SleekXMPP and Javascript Web ===
* '''Software Project:''' SleekXMPP
* '''Software URL:''' https://github.com/fritzy/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) devices like raspberries, cubieboards, beaglebones to control and measure processes and even toys. XMPP has several extensions for helping such devices to create interoperable and secure communication. SleekXMPP is an XMPP package for Python and with the combination of Python, XMPP and IoT It is possible to have a rapid secure prototyping environment without the need to expose data or register accounts on cloud services.
* '''Expected results:'''
** Easy to use examples and web tools for creating 'things' (controlling both sensors and actuators) and letting them connect to logic systems and be controlled through xmpp based web clients
** Being able to securely control things from a webview
** Viewing and visualizing sensor data on a webview
** Having logic scripts or bots taking decisions based on sensor data and sending control messages to other things. Perhaps through http://nodered.org/ visual logic
** All code pullrequested to the main track of https://github.com/fritzy/SleekXMPP
** Examples and demo tools available through http://xmpp-iot.org
** Reading things, as described in XEP-0323.
** Writing to things, as described in XEP-0325.
** Provisioning things, as described in XEP-0324.
** Hiding legacy systems through Concentrators, as described in XEP-0326
The goal is to create a fun easy to understand quick toolset to do prototyping IoT projects in a secure and scalable fashion from the start, instead of exposing ports and webpages through firewalls or other open brokers.
* '''Knowledge Prerequisite:''' Python coding and javascript web environments. XMPP knowledge as XEP for IoT are assuming already a good understanding of XMPP mechanisms. http://xmpp.org/xmpp-protocols/xmpp-extensions/
* '''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 MUC room ([https://jappix.com/?r=gsoc@muc.xmpp.org web client])
** http://mail.jabber.org/mailman/listinfo/iot
** https://groups.google.com/forum/#!forum/sleekxmpp-discussion
=== 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.
** ''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:''' : Joachim Lindborg, joachim.lindborg@sust.se
* '''discussion details:'''
** ** main talk around the assignment in the gsoc@muc.xmpp.org MUC room ([https://jappix.com/?r=gsoc@muc.xmpp.org web client])
** http://mail.jabber.org/mailman/listinfo/iot
** IRC: #smack (freenode)
** MUC: open_chat@conference.igniterealtime.org
** Smack Dev Forum: https://community.igniterealtime.org/community/developers/smack
** http://www.openhab.org/community.html
=== Openfire Stream Resumption support (XEP-198: Stream Management) ===
* '''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 currently lacks the stream management protocol described in XEP-0198. This provides acking of stanzas across the session, and also the ability to resume a stream that has been disconnected by network failure. There is no existing infrastructure for such a capability, and the approach needs to consider that Openfire has clustering support; a session may reconnect to a different node within the cluster. See also https://igniterealtime.org/issues/browse/OF-446
* '''Expected results:''' Each deliverable should be presented as a pull request on GitHub, ready for merge, with tests where appropriate:
** First, simple acking-only should be implemented, with no resumption. This should handle the case where a session is lost, redirecting unacknowledged stanzas to offline storage or other sessions as appropriate.
** Next, resumption should be implemented. There are a number of strategies for this, and it is not entirely clear which strategy will be most successful.
* '''Knowledge Prerequisite:''' Reasonable knowledge of Git, Java and XMPP. Communicating with the team and the XSF Standards SIG will be essential.
* '''Difficulty:''' Hard
* '''Implementation Language:''' Java
* '''Mentor:''' Dave Cridland &lt;dave@cridland.net&gt;
* '''Contact Details:''' XEP-0045 chatroom at open_chat@conference.igniterealtime.org

Latest revision as of 09:37, 23 June 2017

Participation

The XSF has been accepted as a mentoring organisation for Google Summer of Code 2015.

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!

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.

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: Kevin Smith, 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: Kevin Smith, Tobias Markmann
  • Contact Details: Chatroom at swift@rooms.swift.im

Multi-account support 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: Swift has an interface designed for connecting to a single account, for simplicity (a goal of Swift's). Some users wish to connect to several servers at once, and the current solution of "run multiple copies of Swift" is unsatisfying. A student working on this project would project a pleasing user experience allowing users to connect to several accounts in a single Swift, without losing the simplicity that comes from the current single-account approach.
  • Expected results:
    • Logging in with multiple accounts
    • A single roster window, showing each account's roster (split)
    • Merged but identifyable bookmarks and recent chats
    • Ability to add a contact to any account
    • Ability to join MUCs with any account
    • Ability to perform other actions (e.g. user search) with any account
    • Setting cross-account things in only one place - e.g. a single status setter for all sessions
    • Solving issues anywhere else a user might need to choose their account before an action.
  • 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: Easy code, challenging UI
  • Implementation Language: C++
  • Mentor: Kevin Smith, 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: Kevin Smith, Tobias Markmann
  • Contact Details: Chatroom at swift@rooms.swift.im

Openfire New Protocol 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: As one of the oldest currently deployed servers, Openfire lacks support for the newer protocols. This project aims to add new protocol support to existing infrastructure; this will modernize Openfire's capabilities in three key ways:
    • 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 standard for 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.
    • In addition, MAM requests may be directed to a XEP-0045 chatroom; again, Openfire already stores MUC archives in the database, so querying these should be possible. MAM support for chatrooms is considered relatively bleeding-edge support, so testing will be a challenge.
    • Finally, Simple Communication Blocking, XEP-0191 presents a simpler blocking interface than the older XEP-0019 which is supported by Openfire. Again, the blocking infrastructure already exists, though in this case it may be simpler to avoid the reuse.
  • Expected results: Each item should be presented as a pull request on GitHub, ready for merge, with tests where appropriate.
  • Knowledge Prerequisite: Reasonable knowledge of Git, Java and XMPP. Communicating with the team and the XSF Standards SIG will be essential.
  • Difficulty: Easy
  • 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, which 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:
    • XMPP federation (Server to Server / S2S) support
    • Basic XEP-0045 user join protocol support
    • Mapping of further XEP-0045 features to IRC, such as nickname registration.
  • Knowledge Prerequisite: Any knowledge of IRC or XMPP will be beneficial but can be learned during the summer. Otherwise C fluency is required.
  • Difficulty: Moderate
  • Implementation Language: C
  • Mentor: Arc Riley
  • Contact details: #copyleftgames on freenode

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,
  • Difficulty: Moderate
  • 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
  • Difficulty: Hard
  • 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.
  • Difficulty: Hard
  • 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 as possible should be mapped, including:
    • Joining a room
    • Faking occupant presence in a room
    • Receiving messages from a room
    • Posting messages to a room
  • Knowledge Prerequisite:
    • Python or Javascript required
    • XMPP desirable
  • Difficulty: Moderate
  • Implementation Languages: Python or Javascript.
  • Mentor: Simon Tennant
  • Contact details: https://groups.google.com/forum/#!forum/buddycloud-dev

Reference Push Notification Server

  • Software Project: Buddycloud
  • Software URL: https://github.com/buddycloud
  • Software VCS URL: Project not specified yet.
  • Software Description: Build a reference implementation of the new Push Notification XEP.
  • Brief explanation: The newly defined Push XEP offers a great oppertunity for XMPP to support not-always-online mobile devices. This is an area where XMPP has been weak and it's urgent that we get a workable solution that can support app developers. The Buddycloud team has already built a push notification service however this contains many features specific to the Buddycloud project and it would be better to have a spec-compliant server and one that can service non-Buddycloud use cases using the Push XEP.

You would be responsible for designing, building and testing the reference implementation and to support plugins for each of the major push platforms. To test, you would need to build a plugin to support at least one of the major mobile platforms push services. You would probably also need to build a small reference application for testing the contents of inbound pushes. Success in this project will require working with and around some of the remaining ambiguity in the current specification, and hopefully providing valuable input back into the current spec to make it stronger.

This should run as an XMPP component and be XMPP server agnostic.

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.
  • Difficulty: Moderate
  • 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: https://github.com/swift/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
  • Difficulty: Easy
  • Implementation Language: Java
  • Mentor: Kevin Smith
  • Contact Details: Chatroom at swift@rooms.swift.im

Prototyping tools, for Internet of Things Using SleekXMPP and Javascript Web

  • Software Project: SleekXMPP
  • Software URL: https://github.com/fritzy/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) devices like raspberries, cubieboards, beaglebones to control and measure processes and even toys. XMPP has several extensions for helping such devices to create interoperable and secure communication. SleekXMPP is an XMPP package for Python and with the combination of Python, XMPP and IoT It is possible to have a rapid secure prototyping environment without the need to expose data or register accounts on cloud services.
  • Expected results:
    • Easy to use examples and web tools for creating 'things' (controlling both sensors and actuators) and letting them connect to logic systems and be controlled through xmpp based web clients
    • Being able to securely control things from a webview
    • Viewing and visualizing sensor data on a webview
    • Having logic scripts or bots taking decisions based on sensor data and sending control messages to other things. Perhaps through http://nodered.org/ visual logic
    • All code pullrequested to the main track of https://github.com/fritzy/SleekXMPP
    • Examples and demo tools available through http://xmpp-iot.org
    • Reading things, as described in XEP-0323.
    • Writing to things, as described in XEP-0325.
    • Provisioning things, as described in XEP-0324.
    • Hiding legacy systems through Concentrators, as described in XEP-0326

The goal is to create a fun easy to understand quick toolset to do prototyping IoT projects in a secure and scalable fashion from the start, instead of exposing ports and webpages through firewalls or other open brokers.

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.
    • 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: : Joachim Lindborg, joachim.lindborg@sust.se
  • discussion details:

Openfire Stream Resumption support (XEP-198: Stream Management)

  • 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 currently lacks the stream management protocol described in XEP-0198. This provides acking of stanzas across the session, and also the ability to resume a stream that has been disconnected by network failure. There is no existing infrastructure for such a capability, and the approach needs to consider that Openfire has clustering support; a session may reconnect to a different node within the cluster. See also https://igniterealtime.org/issues/browse/OF-446
  • Expected results: Each deliverable should be presented as a pull request on GitHub, ready for merge, with tests where appropriate:
    • First, simple acking-only should be implemented, with no resumption. This should handle the case where a session is lost, redirecting unacknowledged stanzas to offline storage or other sessions as appropriate.
    • Next, resumption should be implemented. There are a number of strategies for this, and it is not entirely clear which strategy will be most successful.
  • Knowledge Prerequisite: Reasonable knowledge of Git, Java and XMPP. Communicating with the team and the XSF Standards SIG will be essential.
  • Difficulty: Hard
  • Implementation Language: Java
  • Mentor: Dave Cridland <dave@cridland.net>
  • Contact Details: XEP-0045 chatroom at open_chat@conference.igniterealtime.org
Retrieved from "https://wiki.xmpp.org/web/index.php?title=Summer_of_Code_2015&oldid=24"