Difference between revisions of "Summer of Code 2011 Project Ideas"

From XMPP WIKI
Jump to navigation Jump to search
(No difference)

Revision as of 15:51, 26 February 2011

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 also need to work in parallel with an upcoming XEP that will try to codify an approach to providing standardized social networking services in a federated manner.

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.

ideas?

Swift IM

File Transfer Support

  • Summary: Implement file exchange

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)
    • Implement real-time-protocol (using standard RTP)