Summer of Code 2011 Project Ideas

Listed below will be some project ideas for the XSF's involvement in GSoC 2011. Visit our Summer of Code 2011 page for information about applying. You are also very welcome to propose your own ideas for the participating projects below, but please be aware that the XSF generally prefers contribution to existing projects that are active in the community, and shies away from proposals to create entirely new software projects.

Open Social Network projects

I believe we are at an important stage in the evolution of social networks where users start to run their own nodes using software from groups like Diaspora, OSW and buddycloud.

We all know why distributed social networks are a good thing. But we are missing components that provide additional services to social networks. Plug-ins if you will. A plug-in to manage location. A plug-in to manage media etc.

The unix philosophy of "write programs that do one thing and do it well, write programs to work together" is very relevant to building an open social network.

XMPP, like Unix's design, gives us a nice interface to build components that handle tasks of work like calculating location, delivering media, serving a directory of channels.

New buddycloud clients will have "plugins" that are really just addresses to xmpp components:

• media server: media.picture-vault.com
• location server: engine.location-service.com
• channel directory: directory.example.com
• search service: channels.collecta.com

All project work will work in parallel with an upcoming XEP that will try to codify an approach to providing standardized federated social networking services.

Mentoring process

GSOC mentors need to devote significant time to the process; we're passionate about creating an open social network and getting buddycloud usable by everyone. We are willing to devote all the time necessary to make you efficient at "building the future".

To make you efficient we plan on doing this by coming up with good user-stories (RFC MUST/SHOULD style plus acceptance criteria), creating specific technical tasks, code review sessions, and testing. Astro will be your main mentor and available for all code and XMPP questions. Simon Tennant will be your backup mentor and help arrange your meeting plans and connect you with the right people at each stage of your project. He will also help you define the system architecture and a timeline. Rene will also be available for client and server specific code questions. Additionally there is an active buddycloud dev chat-room and mailing list for general questions.

Open social location server

build a social location server that helps users share their location in a trusted way with their friends and query for nearby data.

Difficulty: Medium - Hard

A social location server needs to allow uses to bookmark locations that are then stored as either just a name or with incrementally more information such as address, associated wifi and cellID data and perhaps even a lat/long. The location server runs as an XMPP component and should be deployable by anyone that wants to offer location services to anyone else on buddycloud (or other networks too). The server should:

• Receive XEP-0255 formatted beacon data (wifi-MACs, Cell-ID, GPS)
• Pull in with Open StreetMap data and Google Local data sources to reverse geo-locate lat-long
• Cache heavy queries
• Manage user place bookmarks
• Pattern match on beacon data and place users back at bookmarked places
• Scale to millions of queries/minute.

As part of the GSOC provisions, the code should be released as open source so that any XMPP admins can also run a location server.

Skills: GIS functions, database scaling techniques, XMPP component design

iOS XMPP client with pub-sub support

An open-source XMPP client for iPhones and iPads with support for open social networking. AKA, get standards compliant XMPP based social networking into the hands of of the masses.

Difficulty: Medium - Hard

To be successful, this project will deliver and XMPP client that is easy to use, and standards compliant. It should handle roster synchronisation and use XEP-0198 to ensure reliable message delivery on an unreliable mobile network. The iOS client should also provide integrated social networking functions that can challenge the closed Twitter and Facebook hegemony.

It should provide the following social features:

• location updating and sharing with XEP-0080 and XEP-0255
• do channel posting and updating using pub-sub
• handle mood setting
• pay particular attention to ease of use and good UI design principles

The client will need to be well integrated with the iOS core features to ensure long battery life while running in the background.

Skills: Good XMPP knowledge. XMPPFramework skills.

Realtime search service for pub-sub nodes

"Build a library that makes it easy to search for content in pub-sub nodes"

Difficulty: Medium - Hard

Pub-sub servers shipped with XMPP servers are gaining increased use. Additionally pub-sub like "code-on-a-node" projects are gaining traction.

The aim of this project is to develop a library to help search through indexed pub-sub node content.

The library should be easily re-usable in other applications to enable searching and notifications based on content or specific changes to that content.

This would let users perform queries like "Show me all pub-sub updates that contain #FOSDEM" or "Show me all changes to nodes already containing #FOSDEM"

Ideally this content could even be redistributed using pub-sub.

Skills: pub-sub, node.js (or similar async languages)

Channel Directory

"make it super easy for users to find interesting channels"

Difficulty: Medium - Hard

When a user joins a new social network it's really important to get them hooked up with interesting content. Fast. The user needs to have an almost immediate "this is cool" or "I didn't know that there were other channels or users nearby" moment in the first minute of using a client.

This project aims to build a distributed directory service that would run as an XMPP component.

Channel server operators would select a node running your software as the recommended directory service to find channels. Channel clients query your software for "show me channels nearby to lat/long", "show me channels similar to beer@budvar.cz". Your service would then return lists of channels based on nearby-ness, popularity, or if you feel like getting clever, a mahout based taste engine.

Skills: pub-sub, perhaps mahout, component design.

Media Vault

...because all social networks need cat pictures.

Difficulty: Medium

I'm throwing this up here as an idea and if someone is interested in chatting more and coming up with a firmer project spec then please ping me.

The old non-federated buddycloud had a way to inject media links into your channel. Originally it was a side project of Tuomas Koski, but it really took off with users. Hugely so.

If this were to turn into a project, the goals would be to find an elegant way to share content in the XMPP world (in your channel) and also in the HTTP world. The solution would also need to be really simple to implement in clients and also fit nicely with ATOM formatted entries.

ideas?

Swift

Swift's goal is to provide an IM client that does things 'right': good user interface, solid quality, and standards-compliant. Since Swift is still a young project, there are still several opportunities for new functionality. This page lists some of the high priority tasks the Swift development team has. If you're interested in any of these (or other) Swift ideas, please jump into the swift@rooms.swift.im room and chat it over with Remko and Kev. Swift is a C++ project, so C++ proficiency is required, with either knowledge of or willingness to learn about unit testing (and ideally test-driven development).

Conversation History

• Summary: Implement all aspects of keeping conversation history, both local and remote.
• Difficulty: Easy-Medium
• Details: Swift doesn't currently store any transcripts. A student would likely start by producing a prototype user interface for accessing chat history, then write the library code to access a remote archive, and plug these together and finally work on a local archive. This is likely to be a very satisfying project, with enough challenge to be interesting, but not so much that it's frustrating - plus it's a very popular feature request.

File Transfer Support

• Summary: Implement file exchange using the Jingle XMPP protocol
• Difficulty: Medium-Hard
• Details
  • Implement Jingle signaling protocol for file exchange
  • Implement existing transports for File Transfer in XMPP: SOCKS5 Bytestreams, In-Band-Bytestreams
  • Implement & experiment with new transports, using ICE(-TCP), TURN, ... protocols for firewall traversal

VoIP Support

• Summary: Implement support for voice (and optionally video) communication.
• Difficulty: Hard. This project requires a strong background in VoIP and Networking
• Details
  • Implement signaling using the Jingle XMPP protocol
  • Implement firewall traversal (using standard traversal protocols: ICE, TURN, ...)
  • Implement real-time-protocol (using standard RTP)
  • Investigate frameworks for hardware interaction & media encoding/decoding.

Constrained Swift

• Summary: Implement support for XMPP protocols that are targeted towards (resource-)constrained environments
• Difficulty: Medium
• Details: XMPP provides protocols for dealing with 'constrained' environments: session resumption and incremental roster retrieval for bandwidth-constrained situations, BOSH for places where keeping a long-lived connection is hard, SIFT for limiting the amount of incoming traffic, Link-local for serverless locations, ... Support for these protocols is not only interesting when XMPP software is used in these particular situations, it also makes the client faster and more reliable in general. In this project, you will study the protocols that can improve Swift in these situations (Session Management, BOSH, SIFT, Link-local, ...), and extend Swift (and the underlying Swiften XMPP library) to support these use cases.

Multi-account Support

• Summary: Implement support for multiple accounts
• Difficulty: Medium
• Details: Swift currently only supports one account at a time. Supporting multiple accounts is one of the most requested features for Swift. Although this is technically not hard to implement, it involves quite some design decisions on providing a clear and easy-to-understand user interface. This project is about designing a good user interface for multiple account support.

Multi-resource support

• Summary: Implement and standardize techniques & protocols for supporting being connected with multiple clients simultaneously.
• Difficulty: Medium
• Details: Although XMPP has supported multiple simultaneously connected clients from the start, the user experience is in practice seldom what a user would expect. This has not been a big problem up until recently, since most people tend to connect with only one client at the same time. These days, however, people are constantly going back and forth between their always-on mobile IM client and their desktop. Enabling a good user experience for this requires new protocols and techniques for transferring conversations between devices, ... This project is about implementing these protocols to streamline the use case of multiple resources

Multi-User Chat Support

• Summary: Implement full MUC protocol support, and improve MUC-related UI aspects
• Difficulty: Easy
• Details: Although Swift already supports multi-user chats, the support for it is still basic. For example, things that are still missing are room management/administrutaion, converting a one-to-one chat to a MUC, and other more advanced use cases. This project will improve the MUC support currently present in Swift to also support the more advanced use cases, while still providing a clear and usable UI. Another goal of this project is to work out how to provide a UI that allows you to be in a large number of rooms simultaneously (which is currently hard to manage in most XMPP clients, including Swift).

User activity/profile

• Summary: Implement social aspects in user profiles
• Difficulty: Easy
• Details: XMPP (Through the PEP offerings) supports many social-ish data structures, including a user's location, their mood and their current activity. A student working on this project would add support for these protocols to Swiften, and build a 'user profile' UI around these data to give a view on a contact's state that goes beyond the usual 'Name, address, telephone number' profile. A nice touch would be adding map overlays to the location data, so you could see where all your friends were on a map together, and the suchlike.

Gajim

Gajim is a jabber client written in python and GTK. If you're interested in this (or other) project, please jump into the gajim@conference.gajim.org room and talk to Asterix.

Stream Management

• Summary: Implement all XEP-0198
• Difficulty: Medium
• Details: This extensions has to be implemented at the lowest layer of Gajim: XMPP parser. It requires a careful implementation to not break things, but should not be such a hard project.

Prosody

Prosody is an easily extensible jabber server written in Lua. If you're interested in any of the following project or have a different nice project idea you want to chat about you can reach the Prosody community in their chatroom.

Server-side Jingle Support Features

• Summary: Implement basic STUN/TURN server and Jingle Relay Nodes as prosody module.
• Difficulty: Medium
• Details: STUN and TURN greatly increases the success rate of a connection for protocols using ICE, like XEP-0176.

Realtime Monitoring and Statistics

• Summary: Implement realtime monitoring and statistics viewable via various interfaces, i.e. web interface, for Prosody.
• Difficulty: Medium
• Details: Collect, prepare and present realtime statistics of a running prosody instance in numbers and fancy graphs. The system should be easy to extend and could include metrics like, memory usage, stanza throughput per connection, connected clients and so on.

PySoy

PySoy is 3d cloud game engine for Python 3. The game engine uses XMPP as an open game network in much the same way as the closed Steam, PSN or XBox Live networks. Interested students should join #PySoy on irc.freenode.net and/or pysoy-dev@pysoy.org.

Chat Widgets

• Summary: Add new widgets (soy.widgets.*) specifically designed for XMPP IM between players both in and out of game.
• Difficulty: Easy
• Details: Support for buddy lists, chat windows, and ad-hoc command execution would make implementing a network game much easier. These widgets should be implemented in a generic manner so they can be used for other purposes and modify/extend soy.net classes to be used with them.

XMPP Client Plugin

• Summary: Write a Soy plugin for a popular XMPP client, such as Empathy or Pidgin
• Difficulty: Easy to Medium (client dependent)
• Details: PySoy is designed such that the Python game code runs on a server and Soy clients, using the same libsoy backend, connect to the server such that games can be played without downloading them. One goal is to allow users to launch a game one of their friends is playing directly inside their XMPP client. As libsoy uses glib/gobject, writing a plugin for a GTK-based XMPP client may be easiest. There's already an early example plugin for web browsers as a starting point, but some additional integration will be needed.

Jingle Voice

• Summary: Implement support for player-to-player voice chat using XMPP/Jingle.
• Difficulty: Medium
• Details: Using libraries we already depend on (loudmouth, libnice, libspeex, openal), add voice support support such that players can chat voice with other players and friends who aren't playing the same game but are also using an XMPP/Jingle client with speex support.

OneSocialWeb

The OneSocialWeb project aims at leveraging the similarities that XMPP has with social networking, by taking advantage of its capabilities in terms of security, real-time messaging and identity, in order to create a free, open, decentralized, privacy-aware social web. We think of a future in which all social networks work together in a decentralized and open manner similar to e-mail.

Our project has an active open-source community, federation is alive and we are increasing the number of protocol implementations. Our code can be found at our github site. We have developed a server-side plugin, and one mobile and one web client. You can also join our mailing list to start getting in touch.

Please visit our ideas page to see some of what we propose for the GSoc. Students are also free to come up with their own ideas and suggestions and we will certainly consider them. We will have one mentor to help a student get familiar with the OSW architecture, code and provide guidance on XMPP and related technologies.

Any ideas, questions, etc., please contact: [1]