41
edits
Difference between revisions of "Summer of Code 2010 Project Ideas"
Jump to navigation
Jump to search
Summer of Code 2010 Project Ideas (view source)
Revision as of 18:15, 30 March 2010
, 18:15, 30 March 2010no edit summary
(Inline ideas from Prosody GSoC page, and various other improvements to the page) |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 54: | Line 54: | ||
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. | 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. | |||
== Specific Client Projects == | == Specific Client Projects == | ||
=== Gajim === | === Gajim === | ||
Gajim is a full-featured and easy to use Jabber client. It is written in Python, uses GTK and integrates well with the GNOME desktop environment (but does not depend on it). | Gajim is a full-featured and easy to use Jabber 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 [http://trac.gajim.org/wiki/GajimGSOC Gajim's wiki]. | ||
==== Jingle File Transfer [http://xmpp.org/extensions/xep-0234.html 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 [http://xmpp.org/extensions/xep-0198.html 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 [http://xmpp.org/extensions/xep-0158.html 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 Jabber client. It is written in C++ with Qt. You can visit [http://psi-im.org/ Psi's homepage]. | |||
==== Stream Management [http://xmpp.org/extensions/xep-0198.html 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 [http://xmpp.org/extensions/xep-0167.html#srtp 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 [http://xmpp.org/extensions/xep-0045.html 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 [http://xmpp.org/extensions/inbox/sxe.html (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 [http://xmpp.org/extensions/xep-0136.html 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. | |||
== Specific Server Projects == | == Specific Server Projects == | ||
| Line 115: | Line 150: | ||
* [http://www.igniterealtime.org/community/docs/DOC-1925]: Constructive performance enhancements, which would include finding a structural solution to Openfires Achilles' heel | * [http://www.igniterealtime.org/community/docs/DOC-1925]: Constructive performance enhancements, which would include finding a structural solution to Openfires Achilles' heel | ||
* [http://www.igniterealtime.org/community/message/202083#202083]: Constructive spec compliance enhancements | * [http://www.igniterealtime.org/community/message/202083#202083]: Constructive spec compliance enhancements | ||
* [http://www.igniterealtime.org/community/message/ | * [http://www.igniterealtime.org/community/message/202105#202105]: Network application framework porting effort from Apache MINA to Netty | ||
* [http://www.igniterealtime.org/community/docs/DOC-1992]: Clustering solution development | * [http://www.igniterealtime.org/community/docs/DOC-1992]: Clustering solution development | ||
* [http://www.igniterealtime.org/community/message/202083]: Automated functional testing | * [http://www.igniterealtime.org/community/message/202083]: Automated functional testing | ||