Summer of Code 2010 Project Ideas

Here are some project ideas for the XSF's involvement in GSoC 2010. Visit our Summer of Code 2010 page for information about applying.

High-Level Priorities

The high-level priorities for the XMPP community are listed here with summaries (see also the XSF Roadmap). You may work to implement them in any of the clients, servers or libraries lacking support (see the project-specific lists below).

Choose which project you would like to work with, based on the language their codebase is written in, and how well you fit with their community. Discuss your proposal with them directly to see if it is a good idea.

Jingle File Transfer

We are working to migrate from the old file transfer method XEP-0096 to a more robust method based on Jingle. The new Jingle-based method has been implemented in Pidgin but not yet in other clients. We'd love to see more implementations and get more deployment experience with this method so that we can correct and advance the relevant specs, which are:

• XEP-0234: Jingle File Transfer
• XEP-0047: In-Band Bytestreams
• XEP-0065: SOCKS5 Bytestreams
• XEP-0260: Jingle SOCKS5 Bytestreams Transport Method
• XEP-0261: Jingle In-Band Bytestreams Transport Method

Pidgin already has Jingle File Transfer, but it still needs implementing in other clients and libraries, see below.

Reliability Improvements

The XSF has defined two specifications that make XMPP communication more reliable: Stream Management and Message Receipts. We won't know if these technologies solve the problem until we have more implementation and deployment experience, so we need to get busy coding.

Servers, clients and libraries need this support (see below).

I (MattJ) have some server-side code for XEP-0198 (Stream Management) in Prosody, and am willing (and very interested) to work with someone adding support to a(ny) client so we can get a pair of interoperable implementations going this summer.

Mobile Optimizations

As with reliable communication, the XSF is actively working on optimizations for mobile environments. The two most relevant specifications are Roster Versioning and SIFT. Here again we're looking for more implementation and deployment experience.

Stronger Security

Information security is a never-ending, multi-faceted challenge. Some relevant technologies in the XMPP community are:

• CAPTCHA Forms
• Entity Reputation
• Incident Reporting

In addition, we have several competing proposals for end-to-end encryption but they are fairly experimental.

• XTLS
• AES

General projects

XMPP for the social web

Proposer: Kevin Smith

Difficulty: Variable (scope can be agreed during applications)

Student requirements: Competent development skills, self-drive, ideas.

There are many many websites that involve a social component. This is typically some sort of list of friends, a way to exchange messages, a way to expose information about yourself, and general information feeds. These are all functions that XMPP natively supports very well (the XMPP Roster, Message stanzas, PEP, PubSub etc.). XMPP also has a feature that most of these sites do not - it federates, so you can talk to and friend people on any server. Wouldn't it be great if you could take your friends list with you between sites? So the friends you chat with in your chat client are the same friends you share photos with on a photo stream site, share your thoughts with on microblogging platforms, play games with etc. Wouldn't it be great if when you signed up to a new social-flavoured site, it could pull that in for you? This project is an open-ended attempt to set up a framework that allows social websites to get 'for free' all the flavour of a user's contact list, and the sharing available there, and a simple demo site that uses these features, where XMPP is the back-end and the data-store, and all sites can federate.

XMPP and the social web: federated location

Proposer: Simon Tennant (BuddyCloud)

The goal of this project it so build a reference implementation and, we believe, shape the future of federated location sharing.

Currently there exists no good solution to share your location between social networks or to search for nearby users on other social networks. XMPP has solved the federation problem very nicely. Your challenge would be to solve the location part in a way that makes rolling out world wide across many social networks easy and realistic.

This project's aim is to use the XMPP building blocks and produce a reference implementation of federated location sharing along the lines of the OSLO protocol ( http://code.google.com/p/oslo-protocol/). This work could also dovetail nicely into the "xmpp for the social web" project.

You would be supported by the buddycloud team to produce a working solution that anyone could use to ramp-up federated location sharing between users and federated "who's nearby me" queries. The solution would then be deployed and tested between member networks like Rummble, aka-aki, Skout, mobiluck etc who are very keen to setup working federation and are looking for a reference implementation.

The deliverables for this project would be a working implementation and code snippets and deployment recipes to build the future of location sharing. You would be helped to understand some of the challenges of working with location, building scalable xmpp-based services and turning this into a working deployment.

XMPP-based roaming support

Proposer: Dave Cridland

I have, apparently, almost unique needs in the world.

I have more than one computer, indeed - a desktop *and* a laptop. Not only that, I have a new fangled mobile telephony device - commonly called a mobile, by those in the know.

I can tell I'm one of a kind, because whenever I install an XMPP - or email, or web - client on a computer, I have to reconfigure the damn thing, even thought it's talking to a server which - in principle - could store all my configuration for me, and keep it in sync between my laptop, my desktop, and my mobile client.

Once, many years ago, I wrote such a system based around ACAP - now, I think a winning idea would be based around XEP-0223.

There's a few tricky bits to this project - first, you'd have to figure out the common configuration items between clients, next you'd have to decide how to store them effectively and efficiently. The output would be (at least one) client having fully roaming configuration in at least proof of concept form, and a specification to take through the XSF - with your name on.

Specific Client Projects

Gajim

Gajim is a full-featured and easy to use XMPP client. It is written in Python, uses GTK and integrates well with the GNOME desktop environment (but does not depend on it). You can visit Gajim's wiki.

Jingle File Transfer XEP-0234

Gajim already has socks5 bytestream working, and a work in progress IBB patch. Gajim also has jingle negotiation implemantation for audio / video sessions. So making jingle file transfer work shouldn't be too hard. A harder part is to write the ICE-UDP transport layer, or use XMLL-TLS to encrypt transfers.

Stream Management XEP-0198

This extensions has to be implemented at the lowest layer of Gajim: xmpp parser. It requires a carefull implementation to not break things, but should not be a hard project.

CAPTCHA Forms XEP-0158

There are 2 places where captchas can be presented to users: when registering an account, or when joining a groupchat. Here we need to be able to download a picture / sound / video and present it to user so he can reply to the captcha. Gajim has the required code to doewnload files asynchronously. Showing a picture or playing a sound is also possible. What needs to be done is to present them to users when they arrive (using an external tool when it's a video) and show a field to answer. This sounds quite simple to implement.

Psi

Psi is a powerful cross-platform XMPP client. It is written in C++ with Qt. You can visit Psi's homepage.

Stream Management XEP-0198

Support acknowledging messages and restoring sessions from broken connections, so that Psi can be relied on in even the worst of networking conditions. This development would happen in Psi's underlying XMPP library, Iris.

Jingle RTP Encryption XEP-0167: Negotiation of SRTP

Currently, voice calls in Psi are not encrypted. Ideally, SRTP would be implemented in Psi's avcall module, though that may depend on how tight of a relationship SRTP needs with the RTP session. If a tight relationship is required, then SRTP may need to be implemented in a lower level module like PsiMedia or GStreamer instead.

MUC Overhaul XEP-0045

Psi has decent MUC support but the user interface is lacking in some ways. Better browsing of MUCs, seamless converting of one-to-one chats to MUCs, ability to hide open MUCs or minimize them to the roster, and reconciliation of the join window, MUC bookmarks, and recently joined history, are all things that would be great to see.

Whiteboarding (Shared XML Editing inbox spec)

Psi already has a fairly complete implementation of whiteboarding using the experimental SXE spec. In fact it was worked on as a previous GSoC project. However, it is not fully finished and contains some bugs. Given the age of the existing code and specs, a student choosing this project should approach it with a fresh perspective, evaluate the existing proposed XEPs and consider pushing them through XSF standardization, and then correct/refactor/rewrite Psi's existing whiteboarding code as appropriate.

Message Archiving XEP-0136

Storing message history centrally on the user's server is a longtime requested feature of Psi and XMPP in general. Also, Psi's user interface for message history is quite dated and should be given a facelift. This was also attempted in a previous GSoC project, although none of the code was merged into Psi.

MCabber

MCabber is a small console-based XMPP client, which includes features such as SASL support, history logging, commands completion, dynamic modules and external actions triggers. See our Wiki and Homepage.

Jingle File Transfer XEP-0234

MCabber has no file transfer support. There is an experimental file transfer module (which may not be up-to-date), but we would really be interested in adding Jingle File Transfer.

Specific Server Projects

Prosody

Prosody is a lightweight XMPP server written in Lua. It is designed to be modular and easily extensible via Lua plugins. Members of the Prosody development team would consider mentoring students on any of the following projects:

Server Side Message Archiving

Difficulty: Medium Support for server-side message archiving, as described in XEP-0136. This would allow the server to be a central repository for all the user's conversation logs.

The Gajim client project has an implementation of this XEP, and you should work with them to ensure interoperability between Gajim and Prosody.

IPv6 support

Difficulty: Easy for someone with knowledge of C and networking IPv6 is support in protocols and networks is becoming increasingly important as the IPv4 address space diminishes. We need to encourage the use of IPv6 on the XMPP network, but Prosody and the Lua socket library it uses (LuaSocket) don't support IPv6. The project would involve both C (LuaSocket) and Lua coding (Prosody's DNS and connection-handling code) to allow for easy use of IPv6 connections for both c2s and s2s.

Web interface

Difficulty: Easy A dynamic web interface for managing the server. This would ideally use BOSH, Strophe.js and XEP-0133 to make it a server-independent project. The primary language would be Javascript, with a possibility of some Lua.

Pubsub support

Difficulty: Medium A mod_pubsub for Prosody, implementing XEP-0060. In the spirit of Prosody it should be simple, modular and extensible.

Spam/abuse prevention

Difficulty: Easy-Medium Although spam and abuse isn't prevalent on XMPP as it is on most other networks, it's on the rise. Implement a range of features to help stop this trend, and help service administrators keep on top of abuse on the network.

Links:

• CAPTCHA Forms
• Entity Reputation
• Incident reporting

The ultimate server migration tool

Difficulty: Medium The Prosody team have developed many tools for converting the different server storage formats around. Unify them and produce a tool capable of reading the data from one server and exporting another supported format (e.g. XEP-0227), making server migration painless, no matter where you are moving from or to.

jabberd2

jabberd2.x project is the next generation of the jabberd project. It has been rewritten from the ground up to be scalable, architecturally sound and to support the latest protocol extensions coming out of the XSF. jabberd2 is written in C.

Ideas

• XEP-0060: Publish-Subscribe
• XEP-0163: Personal Eventing Protocol
• XEP-0136: Message Archiving

Openfire

Openfire is the award-winning, open alternative to proprietary instant messaging based on the Java programming language. It is modular and extensible via its plugin architecture.

Network application framework porting from Apache MINA to Netty

Proposer: Safa Sofuoglu

Difficulty: Medium

Openfire is using Apache MINA library for its network infrastructure, but MINA 1.x has some known flaws (it can easily get OutOfMemory, also problems with processing of multibyte characters have been reported) and MINA 2.0 is not released yet. On the other hand, Netty looks promising with its feature set, active community, cleaner documentation and shorter release cycle. According to testimonals, migration from MINA to Netty has led to noticable performance boost and we believe that Openfire will benefit from this migration.

Multi-domain support

Proposer: Openfire Community, member contact slicer321 [1], Wroot [2]

Difficulty: Medium

Currently the server supports a single XMPP domain. Each user of the service must specify the domain in their IM client connection configuration. To host an additional domain, one may consider installing a second instance of Openfire, but this creates networking communication conflicts because each instance is set to reuse the same ports by virtue of established client/server conventions. Instead a proposal began circulating to modify so that it can internally host multiple XMPP domains. This was described as, "virtual hosts", where the server acts as multiple domains, with a separate set of users on each domain. [3]

Portable Import/Export for XMPP servers

Proposer: Openfire Community, member contacts slicer321, Guus der Kinderen [4]

Difficulty: Medium - Easy

Different implementations of XMPP-IM servers store user data in various ways, and many implementations have more than one storage format. This leads to problems when a server administrator wants to switch to another implementation or storage format -- the implementation is as likely as not to have an import mechanism that can read the user data in its current form. Modify to support a common file format for import and export of user data in XMPP-IM servers via Openfire plugin. [5]

Reducing the database footprint of Rosters

Proposer: Openfire Community, member contacts slicer321, Guus

Difficulty: Medium

User Rosters (e.g. buddy contact lists) are stored in the database and requires a large per-user footprint and does not scale well. Modify to reduce the database footprint of rosters by possibly replacing the relation persistence model with a new model based on No-SQL-techniques (e.g. examples of nosql are "Document stores and CouchDB", "Graph databases and Neo4J", "Key/Value stores and Redis", "Column-oriented databases and Cassandra" See Article [6] ). [7]

Constructive performance enhancements

Proposer: Openfire Community, member contacts slicer321, Guus

Difficulty: Medium - Hard

At high-traffic installations, you're measuring the amount of concurrently connected users in groups of thousands. Openfire uses a fixed number of Java threads (from the core thread pool) to do most of its work. By default, Openfire uses 17 threads for each pool. The more data your XMPP domain processes, the more likely it is that you'll run into it. At some point during servicing requests, Openfire stops processing data. If this happens in the core thread pool that handles your client connections, service is very visibly interrupted. Quite often, Openfire doesn't recover from this situation. The server effectively dies. Modify to add constructive performance enhancements, which would include finding a structural solution to Openfires Achilles' heel. [8]

Constructive spec compliance enhancements

Proposer: Openfire Community, member contacts slicer321, Guus

Difficulty: Medium

Openfire provides full support for the XMPP protocol defined by RFC 3920 and RFC 3921. In addition to full XMPP support, Openfire also provides support for numerous extensions to XMPP that are defined through the XEP process at xmpp.org. Modify to add constructive specification compliance enhancements. [9]

Open Source Clustering Solution

Proposer: Openfire Community, member contacts slicer321, tomstrummer [10]

Difficulty: Medium - Hard

The clustering plugin allows more than one server to support client connections transparently providing scalability and high availability. Several community members have begun a project to transition to a newly designed plugin based on JGroups / JBossCache. Students interested in assisting this effort can by collaborating with developers in coding, testing existing code functionality, and or providing documentation. [11]

Automated Testing Implementation

Proposer: Community member contact slicer321

Difficulty: Medium - Hard

Similar server project Tigase has built an automated testing system designed to limit the number of bugs slipping thru into each release [12]. We would like a similar system to provide functional verification, and performance testing. This is an open-ended project with many possibilities.

Fastpath enhancements

Proposer: Openfire Community, member contact slicer321, wroot

Difficulty: Medium - Easy

The Fastpath plugin adds support for managed queued chat requests, such as a support team might use. For example, a web based "Live Support" interface can point a potential customer at a workgroup representing the Sales team. This has been popular among organizations, and there has been many requests for functional enhancement. Modify by adding some of the requested features. [13]