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.
Please do edit this page to outline or list any ideas that you want to work on, or if your an XMPP Project, what ideas you have for Students...
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
Realtime search service
"Collecta for channels"
Difficulty: Medium - Hard
While buddycloud users follow individual channels like beerlove@budvar.cz or james@peach.com, there is a need to be able to follow keywords (#hashtags in twitter-speak).
Each buddycloud channel server provides a firehose feed to remote firehose servers.
This is picked up by aggregators like superfeedr. This project would provide a filtered feed similar to http://superfeedr.com/documentation#track back to users of open social networks, and expose the filtered firehose to them as a channel. This would make it simple to follow hashtags.
For example: I am interested in FOSDEM-related posts. I would follow the channel: FOSDEM@firehose-service.com. Your code will be deployed by anyone running an XMPP server who wants to offer firehose-like searching to buddycloud-compatible clients.
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.
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, ... 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, ...), 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 abd 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/administrutanio, 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 good 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 simultaniously (which is currently hard to manage in most XMPP clients, including Swift).
Gajim
Gajim is a jabber client written in pyton 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 carefull implementation to not break things, but should not be a so 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/TRUN 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.