Difference between revisions of "Summer of Code 2008"

From XMPP WIKI
Jump to navigation Jump to search
m
(Restored from backup.)
 
(One intermediate revision by one other user not shown)
Line 2: Line 2:
  
 
= Introduction =
 
= Introduction =
 +
 
XMPP is the Extensible Messaging and Presence Protocol, an XML wire protocol for real-time communication that emerged from the [http://www.jabber.org/ Jabber] open-source community. Our community is not a traditional open-source project because it is not focused on a single codebase. Instead, our community is centered around open standards and open protocols. However, even though there are closed-source implementations of XMPP, we still have a strong commitment to open code and there are many free and open-source projects in our community.
 
XMPP is the Extensible Messaging and Presence Protocol, an XML wire protocol for real-time communication that emerged from the [http://www.jabber.org/ Jabber] open-source community. Our community is not a traditional open-source project because it is not focused on a single codebase. Instead, our community is centered around open standards and open protocols. However, even though there are closed-source implementations of XMPP, we still have a strong commitment to open code and there are many free and open-source projects in our community.
  
 
We have participated in the Summer of Code since its inception and have learned many lessons, among them:
 
We have participated in the Summer of Code since its inception and have learned many lessons, among them:
 +
 
* We try to choose half a dozen excellent projects and really focus on them.
 
* We try to choose half a dozen excellent projects and really focus on them.
 
* It is difficult to choose excellent projects, so the more helpful information you can provide, the better.
 
* It is difficult to choose excellent projects, so the more helpful information you can provide, the better.
Line 11: Line 13:
 
* We take the Summer of Code very seriously and we expect our students to treat it like a full-time job.
 
* We take the Summer of Code very seriously and we expect our students to treat it like a full-time job.
  
This page lists some potential project ideas that students can work on. This is similar to a "Request for Proposal" process for your summer job. The mentors and other project members have defined these RFPs as a way to help structure the summer work. Many of these projects are are relevant to our overall community [http://xmpp.org/xsf/roadmap.shtml roadmap]. A select team of longtime XMPP developers and former mentors will review all the student proposals and "interview" many of the students so that we can make the best possible choices.
+
This page lists some potential project ideas that students can work on. This is similar to a "Request for Proposal" process for your summer job. The mentors and other project members have defined these RFPs as a way to help structure the summer work. Many of these projects are are relevant to our overall community [http://xmpp.org/xsf/roadmap.shtml roadmap]. A select team of longtime XMPP developers and former mentors will review all the student proposals and "interview" many of the students so that we can make the best possible choices.
  
 
If you have any questions about the XSF's involvement with the Google Summer of Code, please contact [https://stpeter.im/?page_id=1968 Peter Saint-Andre] via email or (preferably) IM.
 
If you have any questions about the XSF's involvement with the Google Summer of Code, please contact [https://stpeter.im/?page_id=1968 Peter Saint-Andre] via email or (preferably) IM.
Line 17: Line 19:
 
Thanks for your interest, and good luck!
 
Thanks for your interest, and good luck!
  
=How to Apply=
+
= How to Apply =
 +
 
 
Application instructions are available at the main GSoC site -- see [http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants here].
 
Application instructions are available at the main GSoC site -- see [http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants here].
  
 
Here is what you should include:
 
Here is what you should include:
 +
 
* Some details about you (what code languages you like, what programming courses you've taken, etc.)
 
* Some details about you (what code languages you like, what programming courses you've taken, etc.)
 
* Results of your preliminary research into the protocols and codebases you might work on
 
* Results of your preliminary research into the protocols and codebases you might work on
Line 26: Line 30:
 
* Possible problems you think you may face
 
* Possible problems you think you may face
  
In general, we consider your GSoC project to be a summer job, so try to provide detailed information that will enable us to decide if you deserve to earn $4500. Our project ideas are like "RFPs" -- your application is your proposal to get the job. Please treat it seriously. Thanks!
+
In general, we consider your GSoC project to be a summer job, so try to provide detailed information that will enable us to decide if you deserve to earn $4500. Our project ideas are like "RFPs" -- your application is your proposal to get the job. Please treat it seriously. Thanks!
  
 
= Clients =
 
= Clients =
 +
 
== Coccinella ==
 
== Coccinella ==
 +
 
=== Jingle video using iaxclient ===
 
=== Jingle video using iaxclient ===
 +
 
* Proposed Mentor: [http://coccinella.im/matben Mats Bengtsson]
 
* Proposed Mentor: [http://coccinella.im/matben Mats Bengtsson]
 
* Programming language: C (knowledge of Tcl/Tk is a plus but '''not''' required!)
 
* Programming language: C (knowledge of Tcl/Tk is a plus but '''not''' required!)
  
 
==== Project description ====
 
==== Project description ====
 +
 
The goal is to integrate and implement the video part from the [http://iaxclient.sf.net/ iaxclient] project with [http://coccinella.im/ Coccinella].
 
The goal is to integrate and implement the video part from the [http://iaxclient.sf.net/ iaxclient] project with [http://coccinella.im/ Coccinella].
  
 
This project involves two distinct tasks:
 
This project involves two distinct tasks:
 +
 
# Write a Tcl/Tk widget integrating video from the iaxclient package. There already is a Tcl package available in Coccinella for iaxclient audio that can be reused.
 
# Write a Tcl/Tk widget integrating video from the iaxclient package. There already is a Tcl package available in Coccinella for iaxclient audio that can be reused.
 
# Include this video widget into Coccinella. A Tcl package supporting the Jingle protocol exists and is being used by the audio package.
 
# Include this video widget into Coccinella. A Tcl package supporting the Jingle protocol exists and is being used by the audio package.
Line 44: Line 53:
  
 
=== Jingle file transfer ===
 
=== Jingle file transfer ===
 +
 
* Proposed Mentor: [http://coccinella.im/matben Mats Bengtsson]
 
* Proposed Mentor: [http://coccinella.im/matben Mats Bengtsson]
 
* Programming language: C/C++ and/or Tcl
 
* Programming language: C/C++ and/or Tcl
  
 
==== Project motivation ====
 
==== Project motivation ====
Transporting files from one user to another is plagued by NATs and firewalls. In ancient times a standard Tcp connection was all that was needed. Instead various application level protocols have been implemented on top of Udp which handles NATs much better. This "reinventing the wheel" by having to reimplement a kind of pseudo Tcp stack on top of Udp is a very unfortunate situation which lacks standardization.
+
 
 +
Transporting files from one user to another is plagued by NATs and firewalls. In ancient times a standard Tcp connection was all that was needed. Instead various application level protocols have been implemented on top of Udp which handles NATs much better. This "reinventing the wheel" by having to reimplement a kind of pseudo Tcp stack on top of Udp is a very unfortunate situation which lacks standardization.
  
 
==== Implementation ====
 
==== Implementation ====
 +
 
This projects aims to use Google gTalks Jingle implementation as a starting point. Ufortunately it is written in C++ and deeply tied into the application notifier system and therefore not reusable as is. Instead the task will be to use the Tcl Udp C code implementation, and essentially use gTalks PseudoTcp class as a wrapper. There are two possible options here: either do a pure Tcl script implementation of the tricks used in PseudoTcp, which I'm not sure is possible, or just translate the C++ class into C code and wrap up the tcludp package to a pseudo tcp (ptcp) command. This should work just like the standard Tcl socket command and should be able to use it transparently.
 
This projects aims to use Google gTalks Jingle implementation as a starting point. Ufortunately it is written in C++ and deeply tied into the application notifier system and therefore not reusable as is. Instead the task will be to use the Tcl Udp C code implementation, and essentially use gTalks PseudoTcp class as a wrapper. There are two possible options here: either do a pure Tcl script implementation of the tricks used in PseudoTcp, which I'm not sure is possible, or just translate the C++ class into C code and wrap up the tcludp package to a pseudo tcp (ptcp) command. This should work just like the standard Tcl socket command and should be able to use it transparently.
  
Line 56: Line 68:
  
 
==== Relevant XEP ====
 
==== Relevant XEP ====
 +
 
* [http://xmpp.org/extensions/xep-0234.html Jingle File Transfer]
 
* [http://xmpp.org/extensions/xep-0234.html Jingle File Transfer]
  
 
=== Aquarium for kids ===
 
=== Aquarium for kids ===
 +
 
* Proposed Mentor: [http://coccinella.im/matben Mats Bengtsson]
 
* Proposed Mentor: [http://coccinella.im/matben Mats Bengtsson]
 
* Programming language: Tcl/Tk
 
* Programming language: Tcl/Tk
  
 
==== Project description ====
 
==== Project description ====
 +
 
This project involves the creation of an interface for kids to Coccinella. You need to create a new roster style, the fishy roster style, with an aquarium containing fishes that represents the contacts (like [http://ralphm.net/ ralphm's Jabber Aquarium]). The fishes need to be be animated with [http://xmpp.org/extensions/xep-0107.html User Mood]. For example, when a contact is happy, the fish will swim quickly in the aquarium with a smile on his face. The graphics will be done in 2D, but when time allows, they can be made in 3D.
 
This project involves the creation of an interface for kids to Coccinella. You need to create a new roster style, the fishy roster style, with an aquarium containing fishes that represents the contacts (like [http://ralphm.net/ ralphm's Jabber Aquarium]). The fishes need to be be animated with [http://xmpp.org/extensions/xep-0107.html User Mood]. For example, when a contact is happy, the fish will swim quickly in the aquarium with a smile on his face. The graphics will be done in 2D, but when time allows, they can be made in 3D.
  
The programming tools will be Tcl/Tk and the tkpath graphics extension package [http://tclbitprint.sf.net/] which provides high quality graphics on all platforms. There exists an albeit primitive SVG importer so the actual graphics elements can be obtained from a SVG drawing tool.
+
The programming tools will be Tcl/Tk and the tkpath graphics extension package [http://tclbitprint.sf.net/ [1]] which provides high quality graphics on all platforms. There exists an albeit primitive SVG importer so the actual graphics elements can be obtained from a SVG drawing tool.
  
 
This project will involve mostly new code, and few boring code rewriting.
 
This project will involve mostly new code, and few boring code rewriting.
  
 
== Psi ==
 
== Psi ==
 +
 
=== Message history ===
 
=== Message history ===
 +
 
* Proposed Mentor: [http://kismith.co.uk Kevin Smith]
 
* Proposed Mentor: [http://kismith.co.uk Kevin Smith]
 
* Programming language: C++ / Qt toolkit
 
* Programming language: C++ / Qt toolkit
 +
 
Psi's current history system is not very usable - this project would involve a student replacing it with a more usable UI, implementing history for groupchat, and using server-side history. Since Psi is a widely-used client, this project would be of particular benefit to a large number of the Jabber/XMPP community.
 
Psi's current history system is not very usable - this project would involve a student replacing it with a more usable UI, implementing history for groupchat, and using server-side history. Since Psi is a widely-used client, this project would be of particular benefit to a large number of the Jabber/XMPP community.
  
 
=== Themable WebKit-based Chat Dialogs ===
 
=== Themable WebKit-based Chat Dialogs ===
 +
 
* Proposed Mentor: [http://el-tramo.be Remko]
 
* Proposed Mentor: [http://el-tramo.be Remko]
 
* Programming language: C++ / Qt toolkit
 
* Programming language: C++ / Qt toolkit
 +
 
It's a widely accepted fact that [http://www.adiumx.com/ Adium] is one of the best looking IM clients out there. Besides the fact that nearly all native Mac OS X apps look good, Adium draws a lot of it looks from its themable [http://www.adiumx.com/screenshots/images/overvieworange.jpg chat dialogs]. These dialogs use [http://webkit.org/ WebKit] to draw their contents. WebKit is an open source web engine, used by Apple in Safari, and even throughout the whole Mac OS X operating system. The good news is that, in the next Qt release, there will be a built-in integration with WebKit, which is good news for Psi.
 
It's a widely accepted fact that [http://www.adiumx.com/ Adium] is one of the best looking IM clients out there. Besides the fact that nearly all native Mac OS X apps look good, Adium draws a lot of it looks from its themable [http://www.adiumx.com/screenshots/images/overvieworange.jpg chat dialogs]. These dialogs use [http://webkit.org/ WebKit] to draw their contents. WebKit is an open source web engine, used by Apple in Safari, and even throughout the whole Mac OS X operating system. The good news is that, in the next Qt release, there will be a built-in integration with WebKit, which is good news for Psi.
  
Line 83: Line 103:
  
 
== Gajim ==
 
== Gajim ==
 +
 
=== Plugin system ===
 
=== Plugin system ===
 +
 
* Proposed Mentor: Yann Leboulanger
 
* Proposed Mentor: Yann Leboulanger
 
* Programming language: Python / GTK+
 
* Programming language: Python / GTK+
 +
 
The goal would be to refactor the way events are handled in Gajim, in order to implement a plugin system. There need to be some GUI hooks, and data flow hooks. The objective is to setup the system and to add some hooks as a proof of concept. Some more hooks will be added later. Second objective is to write one or two plugins as examples.
 
The goal would be to refactor the way events are handled in Gajim, in order to implement a plugin system. There need to be some GUI hooks, and data flow hooks. The objective is to setup the system and to add some hooks as a proof of concept. Some more hooks will be added later. Second objective is to write one or two plugins as examples.
  
 
=== BOSH authentification ===
 
=== BOSH authentification ===
 +
 
* Proposed Mentor: Yann Leboulanger
 
* Proposed Mentor: Yann Leboulanger
 
* Programming language: Python
 
* Programming language: Python
 +
 
Title tells all. Bosh is an authentification methode based on HTTP. It's described in [http://xmpp.org/extensions/xep-0124.html XEP-0124]. It has to be implemented in our fork of xmpppy library.
 
Title tells all. Bosh is an authentification methode based on HTTP. It's described in [http://xmpp.org/extensions/xep-0124.html XEP-0124]. It has to be implemented in our fork of xmpppy library.
  
 
== New Clients ==
 
== New Clients ==
 +
 
=== Modern Web-based Jabber/XMPP Client ===
 
=== Modern Web-based Jabber/XMPP Client ===
 +
 
* Proposed Mentor: [http://el-tramo.be Remko]
 
* Proposed Mentor: [http://el-tramo.be Remko]
 +
 
Despite all the AJAX/Web 2.0/... hypes, and despite the plethora of closed web-based IM clients (Meebo, Google Talk Gadget, GMail/Talk, ...), there still exists no open, free, and attractive web-based Jabber IM client. In this project, the student will try to fill this void, or at least build a solid foundation towards the ultimate web-based IM client.
 
Despite all the AJAX/Web 2.0/... hypes, and despite the plethora of closed web-based IM clients (Meebo, Google Talk Gadget, GMail/Talk, ...), there still exists no open, free, and attractive web-based Jabber IM client. In this project, the student will try to fill this void, or at least build a solid foundation towards the ultimate web-based IM client.
  
In order to achieve the goal, the student should try to re-use as much of the existing libraries and frameworks, in order to be able to focus on the goal of the project. For the server-side backend, there is a good choice of frameworks in many different languages, including Ruby and Python. For the frontend, existing frameworks exist to build good looking javascript based user interfaces without much trouble (e.g. [http://extjs.com/ ExtJS]).  
+
In order to achieve the goal, the student should try to re-use as much of the existing libraries and frameworks, in order to be able to focus on the goal of the project. For the server-side backend, there is a good choice of frameworks in many different languages, including Ruby and Python. For the frontend, existing frameworks exist to build good looking javascript based user interfaces without much trouble (e.g. [http://extjs.com/ ExtJS]). The student will have to investigate which frameworks suit the project (and the student) best, implement the missing parts on the server-side if necessary (e.g, [http://xmpp.org/extensions/xep-0206.html BOSH]), and build a user interface using the building blocks provided by the web UI libraries.
The student will have to investigate which frameworks suit the project (and the student) best, implement the missing parts on the server-side if necessary (e.g, [http://xmpp.org/extensions/xep-0206.html BOSH]), and build a user interface using the building blocks provided by the web UI libraries.
 
  
stpeter saith: You mean like [http://soashable.com/ Soashable]? :-)
+
stpeter saith: You mean like [http://soashable.com/ Soashable]? :-)
  
 
== xmpp4moz/SamePlace ==
 
== xmpp4moz/SamePlace ==
 +
 
=== PubSub ATOM aggregator ===
 
=== PubSub ATOM aggregator ===
This is an idea to develop a XUL [http://dev.hyperstruct.net/xmpp4moz xmpp4moz]-based PubSub ATOM aggregator.
 
The aggregator would support [http://xmpp.org/extensions/xep-0060.html XEP-0060 PubSub], [http://tools.ietf.org/html/draft-saintandre-atompub-notify ATOM-over-PubSub] and [http://xmpp.org/extensions/xep-0136.html XEP-0136 Message archiving] so that feeds could be synched across multiple computers and their state saved. It could be possible to download all feeds for offline/disconnected mode. The aggregator could be developed as a stand-alone application and as an extension for Firefox and Thunderbird, or/and integrated in [http://sameplace.cc/ SamePlace]. -- [[User:Kael|Kael]]
 
  
I would be willing to (help) mentor this project -- -- [[User:Itay|Itay]]
+
This is an idea to develop a XUL [http://dev.hyperstruct.net/xmpp4moz xmpp4moz]-based PubSub ATOM aggregator. The aggregator would support [http://xmpp.org/extensions/xep-0060.html XEP-0060 PubSub], [http://tools.ietf.org/html/draft-saintandre-atompub-notify ATOM-over-PubSub] and [http://xmpp.org/extensions/xep-0136.html XEP-0136 Message archiving] so that feeds could be synched across multiple computers and their state saved. It could be possible to download all feeds for offline/disconnected mode. The aggregator could be developed as a stand-alone application and as an extension for Firefox and Thunderbird, or/and integrated in [http://sameplace.cc/ SamePlace]. -- [[User:Kael]]
 +
 
 +
I would be willing to (help) mentor this project -- -- [[User:Itay]]
  
 
=== Mozilla PubSub application configuration extension ===
 
=== Mozilla PubSub application configuration extension ===
This is an idea to develop an extension for [http://dev.hyperstruct.net/xmpp4moz xmpp4moz]/[http://sameplace.cc/ SamePlace] to save [http://preferential.mozdev.org/preferences.html Firefox and Thunderbird settings] remotely, following the ''PubSub persistent storage model'' defined by  [http://xmpp.org/extensions/xep-0223.html XEP-0223], similarly to [http://en.wikipedia.org/wiki/Application_Configuration_Access_Protocol ACAP] (cf. [http://tools.ietf.org/html/rfc2244 RFC2244] and [https://datatracker.ietf.org/drafts/wg/acap/ ACAP Internet-Drafts]).
 
  
This extension would allow to save Firefox browser settings, bookmarks, history, cookies, Sherlock and OpenSearch search engine plugins ; and Thunderbird email, newsgroups and feeds accounts, and configuration settings on an XMPP server. -- [[User:Kael|Kael]]
+
This is an idea to develop an extension for [http://dev.hyperstruct.net/xmpp4moz xmpp4moz]/[http://sameplace.cc/ SamePlace] to save [http://preferential.mozdev.org/preferences.html Firefox and Thunderbird settings] remotely, following the ''PubSub persistent storage model'' defined by [http://xmpp.org/extensions/xep-0223.html XEP-0223], similarly to [http://en.wikipedia.org/wiki/Application_Configuration_Access_Protocol ACAP] (cf. [http://tools.ietf.org/html/rfc2244 RFC2244] and [https://datatracker.ietf.org/drafts/wg/acap/ ACAP Internet-Drafts]).
 +
 
 +
This extension would allow to save Firefox browser settings, bookmarks, history, cookies, Sherlock and OpenSearch search engine plugins ; and Thunderbird email, newsgroups and feeds accounts, and configuration settings on an XMPP server. -- [[User:Kael]]
  
 
= Servers =
 
= Servers =
 +
 
== ejabberd ==
 
== ejabberd ==
 +
 
Mentor: Mickaël Rémond (email: [mailto:mremond@process-one.net mremond@process-one.net] / jid: [xmpp:mremond@process-one.net mremond@process-one.net]).
 
Mentor: Mickaël Rémond (email: [mailto:mremond@process-one.net mremond@process-one.net] / jid: [xmpp:mremond@process-one.net mremond@process-one.net]).
  
 
Those proposals for GSOC projects could be implemented in any Jabber server and programming language. However, they are specially easy to implement in ejabberd for several reasons:
 
Those proposals for GSOC projects could be implemented in any Jabber server and programming language. However, they are specially easy to implement in ejabberd for several reasons:
 +
 
* ejabberd modularity allows to implement those features without requiring changes in ejabberd core
 
* ejabberd modularity allows to implement those features without requiring changes in ejabberd core
 
* there are several contributed modules that can serve as example for some parts of the features
 
* there are several contributed modules that can serve as example for some parts of the features
Line 125: Line 157:
 
* The erlang declarative programming language allows easy prototyping: no need to declare functions, variables, etc just to implement a function/module and try it.
 
* The erlang declarative programming language allows easy prototyping: no need to declare functions, variables, etc just to implement a function/module and try it.
  
 +
=== Page for Account Registration & Password Recovery ===
  
=== Page for Account Registration & Password Recovery ===
 
 
Develop a module for ejabberd that provides a page to create account, change password and recover lost password.
 
Develop a module for ejabberd that provides a page to create account, change password and recover lost password.
  
'''Motivation'''
+
'''Motivation''' There are two different problems that are of great importance for public servers and the XMPP federation as Jabber gets increasing popularity:
There are two different problems that are of great importance for public servers and the XMPP federation as Jabber gets increasing popularity:
+
 
 
* In-band account registration of Jabber accounts (XEP-0077) can be abused easily by spammers. For example, a spammer could create a million of accounts in jabber.org easily, and then put 100 zombie machines to login to those accounts and send spam to everywhere in the XMPP Federation.
 
* In-band account registration of Jabber accounts (XEP-0077) can be abused easily by spammers. For example, a spammer could create a million of accounts in jabber.org easily, and then put 100 zombie machines to login to those accounts and send spam to everywhere in the XMPP Federation.
 
* There isn't a generalized way to recover a forgotten password of a Jabber account. Since In-band account registration (XEP-0077) is the standard way to create Jabber accounts since 1999 until now, Jabber accounts do not have email accounts associated. Hence, it isn't possible to recover a forgotten password automatically. The solution right now is to contact an admin in the Jabber server, which will change the password manually and send an email with the new password.
 
* There isn't a generalized way to recover a forgotten password of a Jabber account. Since In-band account registration (XEP-0077) is the standard way to create Jabber accounts since 1999 until now, Jabber accounts do not have email accounts associated. Hence, it isn't possible to recover a forgotten password automatically. The solution right now is to contact an admin in the Jabber server, which will change the password manually and send an email with the new password.
  
'''Details'''
+
'''Details''' This proposal attempts to fix both problems. It consits in three related tasks:
This proposal attempts to fix both problems. It consits in three related tasks:
+
 
 
* Provide a registration page. The page requests: username, password, repeat-password, email address. When filled the form, it registers the account in the local ejabbed server. The email address is NOT stored in the user's vcard; it is stored in a secure a private way, just like the password. Optional elements:
 
* Provide a registration page. The page requests: username, password, repeat-password, email address. When filled the form, it registers the account in the local ejabbed server. The email address is NOT stored in the user's vcard; it is stored in a secure a private way, just like the password. Optional elements:
 +
 
# The page could also include a captcha to require registration
 
# The page could also include a captcha to require registration
 
# The page could send an email instead of registering the account. If the email is responded correctly, then the account is created
 
# The page could send an email instead of registering the account. If the email is responded correctly, then the account is created
 +
 
* Provide a page to change the password and email addresProvide also. Of course, this page will require the valid username and password in order to change the information.
 
* Provide a page to change the password and email addresProvide also. Of course, this page will require the valid username and password in order to change the information.
 
* Provide a page to recover the forgotten password. The page only requires a valid username. Then it sends an email to the address stored for that account. If the email is answered correctly, the password is changed and the new one is sent by email.
 
* Provide a page to recover the forgotten password. The page only requires a valid username. Then it sends an email to the address stored for that account. If the email is answered correctly, the password is changed and the new one is sent by email.
  
 
'''Existing work'''
 
'''Existing work'''
 +
 
* ejabberd 2.0.0 allows to provide web pages easily using the feature request_handlers in the service ejabberd_http. Example: mod_http_bind, mod_http_fileserver, mod_webpresence.
 
* ejabberd 2.0.0 allows to provide web pages easily using the feature request_handlers in the service ejabberd_http. Example: mod_http_bind, mod_http_fileserver, mod_webpresence.
 
* There is an old and experimental contributed module, mod_passrecover, that implements part of task 3. It could be used as an example
 
* There is an old and experimental contributed module, mod_passrecover, that implements part of task 3. It could be used as an example
 
* Example of registration page, this one is written in PHP: http://www.jabberes.org/jrt/
 
* Example of registration page, this one is written in PHP: http://www.jabberes.org/jrt/
  
 +
=== Time Tracker ===
  
=== Time Tracker ===
 
 
Implement an ejabberd module that tracks how much time a Jabber account is online in each presence type. Reports can be check by the user and/or admin.
 
Implement an ejabberd module that tracks how much time a Jabber account is online in each presence type. Reports can be check by the user and/or admin.
  
Line 154: Line 189:
  
 
'''Example Track'''
 
'''Example Track'''
* When I start my work in the morning, I start my Jabber client and login to my working account. Then set presence 'busy' with status message 'Doing GSOC: write cases for test suite'. The Time Tracker captures that and stores the meaningful information.
 
* At midday I change to 'xa' with text 'Launch time'.
 
* During the afternoon I set to 'busy' again, but status message 'Doing study: homework'.
 
* When I am interrupted for more than 5 minutes, my Jabber client sets to 'autoaway', and the Time Tracker will also notice that.
 
  
'''Example Report'''
+
* When I start my work in the morning, I start my Jabber client and login to my working account. Then set presence 'busy' with status message 'Doing GSOC: write cases for test suite'. The Time Tracker captures that and stores the meaningful information.
At the end of the day, I can access the Time Tracker interface (web, adhoc or whatever) and ask the report. For example, it can report:
+
* At midday I change to 'xa' with text 'Launch time'.
 +
* During the afternoon I set to 'busy' again, but status message 'Doing study: homework'.
 +
* When I am interrupted for more than 5 minutes, my Jabber client sets to 'autoaway', and the Time Tracker will also notice that.
 +
 
 +
'''Example Report''' At the end of the day, I can access the Time Tracker interface (web, adhoc or whatever) and ask the report. For example, it can report:
  
 
Today:
 
Today:
 +
 
* busy - Doing GSOC: write cases for test suite - 5 hours and 30 minutes
 
* busy - Doing GSOC: write cases for test suite - 5 hours and 30 minutes
 
* busy - Doing study: homework - 2 hours and 10 minutes
 
* busy - Doing study: homework - 2 hours and 10 minutes
Line 168: Line 204:
  
 
Last Week (last 7 days):
 
Last Week (last 7 days):
 +
 
* busy - Doing GSOC: write cases for test suite - 30 hours and 30 minutes
 
* busy - Doing GSOC: write cases for test suite - 30 hours and 30 minutes
 
* busy - Doing study: homework - 7 hours and 10 minutes
 
* busy - Doing study: homework - 7 hours and 10 minutes
Line 175: Line 212:
  
 
'''Existing work'''
 
'''Existing work'''
 +
 
* ejabberd 2.0.0 provides the feature request_handlers in the service ejabberd_http, so it's easy to provide web pages. Example: mod_http_bind, mod_http_fileserver, mod_webpresence.
 
* ejabberd 2.0.0 provides the feature request_handlers in the service ejabberd_http, so it's easy to provide web pages. Example: mod_http_bind, mod_http_fileserver, mod_webpresence.
 
* There are contributed modules that track presence changes and can be used as examples: mod_logxml, mod_statsdx, ...
 
* There are contributed modules that track presence changes and can be used as examples: mod_logxml, mod_statsdx, ...
  
 
=== XMPP to XMPP gateway ===
 
=== XMPP to XMPP gateway ===
 +
 
With the release of exmpp, writing an XMPP client is now easy. Writing a gateway that allow user of a given ejabberd server to reuse their other or old XMPP/Jabber account it a useful project.
 
With the release of exmpp, writing an XMPP client is now easy. Writing a gateway that allow user of a given ejabberd server to reuse their other or old XMPP/Jabber account it a useful project.
  
Line 184: Line 223:
  
 
== Openfire ==
 
== Openfire ==
 +
 
Here are some nice features that would be nice to have in Openfire. We are still working on the list which should be ready for early next week (March 25th). If you have other ideas not listed here feel free to send us an email to discuss it or post it [http://www.igniterealtime.org/community/community/developers/gsoc08?view=discussions here].
 
Here are some nice features that would be nice to have in Openfire. We are still working on the list which should be ready for early next week (March 25th). If you have other ideas not listed here feel free to send us an email to discuss it or post it [http://www.igniterealtime.org/community/community/developers/gsoc08?view=discussions here].
  * File Repository and Sharing (including WebDAV)
 
  * File transfers for gateways
 
  * Group Chat for Gateways
 
  * Update and improve BOSH support
 
  * Complete XMPP RFC implementation in XIFF and work on web client
 
  
For more details, visit the [http://www.igniterealtime.org/community/docs/DOC-1490 Summer of Code 2008 Projects].
+
* File Repository and Sharing (including WebDAV)
 +
* File transfers for gateways
 +
* Group Chat for Gateways
 +
* Update and improve BOSH support
 +
* Complete XMPP RFC implementation in XIFF and work on web client
 +
 
 +
For more details, visit the [http://www.igniterealtime.org/community/docs/DOC-1490 Summer of Code 2008 Projects].
 +
 
 +
=== Contacts ===
  
===Contacts===
 
 
Mentor: Gaston Dombiak (email: [mailto:gaston@jivesoftware.com gaston@jivesoftware.com] / jid: [xmpp:gato@jivesoftware.com gato@jivesoftware.com]).
 
Mentor: Gaston Dombiak (email: [mailto:gaston@jivesoftware.com gaston@jivesoftware.com] / jid: [xmpp:gato@jivesoftware.com gato@jivesoftware.com]).
  
 
== PJS ==
 
== PJS ==
 +
 
The PJS project aims to create a reliable, correct and highly scalable XMPP server framework in Python, not unlike what ejabberd is to Erlang. It was started as an undergrad project at the University of Toronto in February 2008. By the start of GSOC, the server should have the following components:
 
The PJS project aims to create a reliable, correct and highly scalable XMPP server framework in Python, not unlike what ejabberd is to Erlang. It was started as an undergrad project at the University of Toronto in February 2008. By the start of GSOC, the server should have the following components:
 +
 
* basic connection handling
 
* basic connection handling
 
* internal message routing (with chained handlers)
 
* internal message routing (with chained handlers)
Line 205: Line 249:
  
 
The server will not be production quality by the end of the semester, though it will have substantial progress toward this goal. Some of the things that may need to be written:
 
The server will not be production quality by the end of the semester, though it will have substantial progress toward this goal. Some of the things that may need to be written:
 +
 
* S2S handling (already has parts of it)
 
* S2S handling (already has parts of it)
 
* Privacy lists (may have parts of it by May)
 
* Privacy lists (may have parts of it by May)
Line 213: Line 258:
  
 
The architecture is as follows:
 
The architecture is as follows:
 +
 
* asynchronous event handling using asyncore (low per-connection memory overhead)
 
* asynchronous event handling using asyncore (low per-connection memory overhead)
 
* chained handlers in pairs (handler + error handler), where each can be run either in-process or in a threadpool.
 
* chained handlers in pairs (handler + error handler), where each can be run either in-process or in a threadpool.
Line 219: Line 265:
  
 
===Contacts===
 
===Contacts===
 +
 
Mentor: David Janes (email: [mailto:davidjanes@blogmatrix.com davidjanes@blogmatrix.com] / jid: [xmpp:davidjanes@gmail.com davidjanes@gmail.com]). Current developer: Dmitri Vassilenko (email: [mailto:tro@glyphy.com tro@glyphy.com] / jid: [xmpp:troworld@gmail.com troworld@gmail.com]).
 
Mentor: David Janes (email: [mailto:davidjanes@blogmatrix.com davidjanes@blogmatrix.com] / jid: [xmpp:davidjanes@gmail.com davidjanes@gmail.com]). Current developer: Dmitri Vassilenko (email: [mailto:tro@glyphy.com tro@glyphy.com] / jid: [xmpp:troworld@gmail.com troworld@gmail.com]).
  
Line 224: Line 271:
  
 
= Components =
 
= Components =
== New ==  
+
 
 +
== New ==
 +
 
 
=== IRC-to-MUC bridge ===
 
=== IRC-to-MUC bridge ===
 +
 
==== Project Description ====
 
==== Project Description ====
This idea is about writing a XMPP Component which acts as a bridge between a IRC network and open and federated XMPP servers. For an IRC network it looks like another server in the network which is connected via one of the custom IRC server-to-server protocols. The component should be written extensible so it's easy to make it work with the different servers like Hyperion or UnrealIRCD. For the XMPP world the component is connected to a XMPP server und some domain like myirc.example.com. When a user from XMPP world joins the Multi User Chat hello@myirc.example.com, the component will map this as a login to #hello on some IRC network.
 
Since most IRC servers are written in C or C++ it seems to be best that this component is written in C or C++ as well.
 
  
Libraries you can use are found under http://jabber.org/
+
This idea is about writing a XMPP Component which acts as a bridge between a IRC network and open and federated XMPP servers. For an IRC network it looks like another server in the network which is connected via one of the custom IRC server-to-server protocols. The component should be written extensible so it's easy to make it work with the different servers like Hyperion or UnrealIRCD. For the XMPP world the component is connected to a XMPP server und some domain like myirc.example.com. When a user from XMPP world joins the Multi User Chat hello@myirc.example.com, the component will map this as a login to #hello on some IRC network. Since most IRC servers are written in C or C++ it seems to be best that this component is written in C or C++ as well.
 +
 
 +
Libraries you can use are found under http://xmpp.org/software/libraries.shtml
  
 
=== XMPP Transport/Gateway ===
 
=== XMPP Transport/Gateway ===
 +
 
==== Project Description ====
 
==== Project Description ====
 +
 
Write a XMPP transport/gateway which enables to use other jabber accounts through only one. It should cover things like transporting presence, messages, roster groups, PEP events and if there is time left even more. Transports like that will make migration XMPP accounts easier.
 
Write a XMPP transport/gateway which enables to use other jabber accounts through only one. It should cover things like transporting presence, messages, roster groups, PEP events and if there is time left even more. Transports like that will make migration XMPP accounts easier.
  
 
=== Sync mode for clients ===
 
=== Sync mode for clients ===
 +
 
==== Project Description ====
 
==== Project Description ====
Write a protocol extension to create a "sync mode" for clients. The idea is to broadcast all a user's incoming and outgoing messages to all of the user's connected resources, so that the user can move between clients on different devices with no interruption. It should also have the option of preserving a client's window state, so that opening or closing a window on one client causes the window to be open or closed on all connected clients.
 
  
Idea submitted by [[User:andrewy|andrewy]], who has done a more in-depth writeup [http://www.andrewyates.net/misc/xmppsync.html here].
+
Write a protocol extension to create a "sync mode" for clients. The idea is to broadcast all a user's incoming and outgoing messages to all of the user's connected resources, so that the user can move between clients on different devices with no interruption. It should also have the option of preserving a client's window state, so that opening or closing a window on one client causes the window to be open or closed on all connected clients.
 +
 
 +
Idea submitted by [[User:Andrewy]], who has done a more in-depth writeup [http://www.andrewyates.net/misc/xmppsync.html here].
  
 
=== JMS-to-XMPP bridge ===
 
=== JMS-to-XMPP bridge ===
 +
 
==== Project Description ====
 
==== Project Description ====
Java Message Service (JMS) provides enterprise messaging features that are similar to both [http://xmpp.org/extensions/xep-0060.html XMPP pubsub] and standard XMPP messaging with http://xmpp.org/extensions/xep-0184.html receipts]. This project would involve writing a bridge between JMS and XMPP so that messages could be shared across systems. This bridge might take the form of a server-side component or a common API. For more details, see [http://mail.jabber.org/pipermail/jdev/2008-March/026380.html here] and [http://mail.jabber.org/pipermail/jdev/2008-March/026386.html]. Possible mentor: Fabio Forno.
+
 
 +
Java Message Service (JMS) provides enterprise messaging features that are similar to both [http://xmpp.org/extensions/xep-0060.html XMPP pubsub] and standard XMPP messaging with http://xmpp.org/extensions/xep-0184.html receipts]. This project would involve writing a bridge between JMS and XMPP so that messages could be shared across systems. This bridge might take the form of a server-side component or a common API. For more details, see [http://mail.jabber.org/pipermail/jdev/2008-March/026380.html here] and [http://mail.jabber.org/pipermail/jdev/2008-March/026386.html [2]]. Possible mentor: Fabio Forno.
  
 
=== Universal Transport via libpurple ===
 
=== Universal Transport via libpurple ===
 +
 
==== Project Description ====
 
==== Project Description ====
 +
 
The [http://swik.net/libpurple libpurple] library is used in Pidgin and Adium for their multi-protocol support. This component would interface from XMPP to libpurple via an existing C or C++ XMPP library such as gloox, iksemel, loudmouth, or libstrophe. As a result, the component would automatically translate to any of the protocols that libpurple supports, including AIM, Bonjour, Gadu-Gadu, Groupwise, ICQ, IRC, MSN, MySpaceIM, QQ, SILC, SIMPLE, Sametime, XMPP, Yahoo!, and Zephyr. Possible mentor: Andreas Monitzer
 
The [http://swik.net/libpurple libpurple] library is used in Pidgin and Adium for their multi-protocol support. This component would interface from XMPP to libpurple via an existing C or C++ XMPP library such as gloox, iksemel, loudmouth, or libstrophe. As a result, the component would automatically translate to any of the protocols that libpurple supports, including AIM, Bonjour, Gadu-Gadu, Groupwise, ICQ, IRC, MSN, MySpaceIM, QQ, SILC, SIMPLE, Sametime, XMPP, Yahoo!, and Zephyr. Possible mentor: Andreas Monitzer
  
 
=== pyICQ-t Fixing and File Transfers ===
 
=== pyICQ-t Fixing and File Transfers ===
 +
 
==== Project Description ====
 
==== Project Description ====
 +
 
With the introduction of ICQ 6, a lot of the ICQ protocol was changed. For example, the old charset problem was solved, UTF-16 is used almost everywhere, it seems that text/x-aolrtf finally died now and status messages are now allowed for every status, even the online status, but most is done via new SNACs. While most of these changes fix severe problems, they also introduced incompatibilities (status messages not shown in older clients / newer clients, charset problems with older / newer clients). Your task would be to analyze the new protocol, update pyICQ-t and/or Twisted to the new protocol, think of a way that works with old and new clients and fix every bug you find during that which was introduced by the ICQ 6 protocol. If there's enough time, your task would also be to figure out how ICQ file transfers (especially in ICQ 6) work and implement them.
 
With the introduction of ICQ 6, a lot of the ICQ protocol was changed. For example, the old charset problem was solved, UTF-16 is used almost everywhere, it seems that text/x-aolrtf finally died now and status messages are now allowed for every status, even the online status, but most is done via new SNACs. While most of these changes fix severe problems, they also introduced incompatibilities (status messages not shown in older clients / newer clients, charset problems with older / newer clients). Your task would be to analyze the new protocol, update pyICQ-t and/or Twisted to the new protocol, think of a way that works with old and new clients and fix every bug you find during that which was introduced by the ICQ 6 protocol. If there's enough time, your task would also be to figure out how ICQ file transfers (especially in ICQ 6) work and implement them.
  
Line 257: Line 317:
  
 
= Libraries =
 
= Libraries =
 +
 
== gloox ==
 
== gloox ==
 +
 
=== Serverless Messaging aka Local-Link ===
 
=== Serverless Messaging aka Local-Link ===
 +
 
==== Project description ====
 
==== Project description ====
 +
 
Write up a platform independent implementation of XEP-0174 for gloox. Platforms supported should be *NIX (including Mac OS X), linux and windows.
 
Write up a platform independent implementation of XEP-0174 for gloox. Platforms supported should be *NIX (including Mac OS X), linux and windows.
  
Line 265: Line 329:
  
 
= Other =
 
= Other =
 +
 
== ISS (Instant Syndicating Standards) ==
 
== ISS (Instant Syndicating Standards) ==
 +
 
=== Project description ===
 
=== Project description ===
Further develop [http://iss.im/ ISS (Instant Syndicating Standards)], built on top of [http://xmpp.org/extensions/xep-0163.html PEP (Personal Eventing via PubSub)].
+
 
Please see website or contact [http://wiki.jabber.org/index.php/User:NickVidal Nick Vidal] for more details.
+
Further develop [http://iss.im/ ISS (Instant Syndicating Standards)], built on top of [http://xmpp.org/extensions/xep-0163.html PEP (Personal Eventing via PubSub)]. Please see website or contact [[User:NickVidal]] for more details.
  
 
== PubSub Wordpress and Drupal plugins ==
 
== PubSub Wordpress and Drupal plugins ==
 +
 
=== Project description ===
 
=== Project description ===
This is an idea to develop a PubSub plugin for WordPress and Drupal with [http://tools.ietf.org/html/draft-saintandre-atompub-notify Atom notifications]
 
The goal is to ease the publication with PubSub and to create an XMPP PubSub ecosystem.
 
  
Blogs could support an autodiscovery element like :
+
This is an idea to develop a PubSub plugin for WordPress and Drupal with [http://tools.ietf.org/html/draft-saintandre-atompub-notify Atom notifications] The goal is to ease the publication with PubSub and to create an XMPP PubSub ecosystem.
<pre>
 
<link rel='alternate' type='xxxx' href='xmpp:romeo@jabber.org?;node=blog'/>
 
</pre>
 
  
(The "type" is yet to be determined...)
+
Blogs could support an autodiscovery element like :
 +
 
 +
<pre>&lt;link rel='alternate' type='xxxx' href='xmpp:romeo@jabber.org?;node=blog'/&gt;</pre>
 +
(The &quot;type&quot; is yet to be determined...)
  
 
Each new post could generate a new leaf node which would contain the post per se and the comments. In this manner, users could subscribe to the thread of their choice directly from the blog by clicking on an RSS-like button.
 
Each new post could generate a new leaf node which would contain the post per se and the comments. In this manner, users could subscribe to the thread of their choice directly from the blog by clicking on an RSS-like button.
Line 289: Line 354:
  
 
== XEP-0070 for the Drupal Jabber authentication module ==
 
== XEP-0070 for the Drupal Jabber authentication module ==
 +
 
=== Project description ===
 
=== Project description ===
 +
 
Drupal implements a [http://drupal.org/node/312 Distributed Authentication System] which allows to use Jabber credentials to log onto every Drupal sites (e.g. [http://www.ejabberd.im/user/help#jabber the Ejabberd site]). But it requires to pass the password to third-party sites often without encryption.
 
Drupal implements a [http://drupal.org/node/312 Distributed Authentication System] which allows to use Jabber credentials to log onto every Drupal sites (e.g. [http://www.ejabberd.im/user/help#jabber the Ejabberd site]). But it requires to pass the password to third-party sites often without encryption.
  
Line 295: Line 362:
  
 
== SSH authentication validation with XEP-0070 ==
 
== SSH authentication validation with XEP-0070 ==
 +
 
=== Project description ===
 
=== Project description ===
 +
 
The idea is to implement an additional security layer for SSH authentication with [http://xmpp.org/extensions/xep-0070.html XEP-0070: Verifying HTTP Requests via XMPP].
 
The idea is to implement an additional security layer for SSH authentication with [http://xmpp.org/extensions/xep-0070.html XEP-0070: Verifying HTTP Requests via XMPP].
  
Line 303: Line 372:
  
 
== XMPP Webmin interface ==
 
== XMPP Webmin interface ==
 +
 
=== Project description ===
 
=== Project description ===
This is an idea to implement an XMPP interface for
+
 
[http://www.webmin.com/ Webmin], a web-based interface for system administration for Unix. Inspired by the example of [http://xmpp.org/extensions/xep-0050.html XEP-0050: Ad-Hoc Commands], this software would allow system administrators to remotely manage and configure their server through data-forms.
+
This is an idea to implement an XMPP interface for [http://www.webmin.com/ Webmin], a web-based interface for system administration for Unix. Inspired by the example of [http://xmpp.org/extensions/xep-0050.html XEP-0050: Ad-Hoc Commands], this software would allow system administrators to remotely manage and configure their server through data-forms.
  
 
It would also allow to select events to be notified of (via messages or PubSub), and processes to monitor (via presence or PubSub), perhaps in conjunction with SNMP.
 
It would also allow to select events to be notified of (via messages or PubSub), and processes to monitor (via presence or PubSub), perhaps in conjunction with SNMP.
Line 314: Line 384:
  
 
== Flyspray Bot ==
 
== Flyspray Bot ==
 +
 
=== Project description ===
 
=== Project description ===
 +
 
It would be really nice to have a bot for the Flyspray bug tracking system which allows to add, delete and edit bugs via ad-hoc commands and chat messages. Additionally it could send out the XMPP notifications which is currently done by a php script.
 
It would be really nice to have a bot for the Flyspray bug tracking system which allows to add, delete and edit bugs via ad-hoc commands and chat messages. Additionally it could send out the XMPP notifications which is currently done by a php script.
  
 
=== Links ===
 
=== Links ===
[http://flyspray.org Flyspray]
 
[http://xmpp.org/extensions/xep-0050.html Ad-Hoc Commands]
 
  
 +
* [http://flyspray.org/ Flyspray]
 +
* [http://xmpp.org/extensions/xep-0050.html Ad-Hoc Commands]
  
 
== Client-Independent Serverless IM component ==
 
== Client-Independent Serverless IM component ==
* Proposed Mentor: [http://el-tramo.be Remko]
+
 
 +
* Proposed Mentor: [http://el-tramo.be/ Remko]
  
 
Currently, only some clients (iChat, Gajim) support server-less chatting, a feature which is very interesting to be able to discover and communicate with people on a local network, without the need to be connected to the internet. The reason behind the slow adoption of this protocol is probably that it breaks with the very fundamental way Jabber is designed (client-server architecture), and as such is a significant amount of work for an existing client to adapt its codebase. The aim of this project is to bring server-less messaging to every XMPP client, by implementing it outside of the client.
 
Currently, only some clients (iChat, Gajim) support server-less chatting, a feature which is very interesting to be able to discover and communicate with people on a local network, without the need to be connected to the internet. The reason behind the slow adoption of this protocol is probably that it breaks with the very fundamental way Jabber is designed (client-server architecture), and as such is a significant amount of work for an existing client to adapt its codebase. The aim of this project is to bring server-less messaging to every XMPP client, by implementing it outside of the client.
  
The goal of this project is to implement a lightweight Jabber daemon that acts as a regular jabber server on the client side, but uses [http://www.jabber.org/xeps/xep-0174.html Link Local Messaging] on the server side. By connecting your favorite client to this daemon running on your own machine, you enable server-less messaging for this client. The project should be written in a cross-platform way to reach a large population of clients. Language can be chosen, as long as there is a decent library available to do zeroconf networking, and preferably a (core) xmpp library as well (examples include Python and C++).
+
The goal of this project is to implement a lightweight Jabber daemon that acts as a regular jabber server on the client side, but uses [http://www.jabber.org/xeps/xep-0174.html Link Local Messaging] on the server side. By connecting your favorite client to this daemon running on your own machine, you enable server-less messaging for this client. The project should be written in a cross-platform way to reach a large population of clients. Language can be chosen, as long as there is a decent library available to do zeroconf networking, and preferably a (core) xmpp library as well (examples include Python and C++).
  
 
Some information about link-local chatting (biased towards Psi) can be found [http://psi-im.org/wiki/Bonjour here].
 
Some information about link-local chatting (biased towards Psi) can be found [http://psi-im.org/wiki/Bonjour here].
  
 
== Client-Independent D-Bus Service for Jingle Audio ==
 
== Client-Independent D-Bus Service for Jingle Audio ==
Many Jabber clients will want to implement the Jingle Audio protocol (and eventually other Jingle protocols as well), but may lack the technical possibility to keep an internal implementation. (or just the will to reinvent the wheel ☺) [http://emacs-jabber.cvs.sourceforge.net/emacs-jabber/tox/ Tox] (Talk Over XMPP) is a D-Bus service meant to provide Jingle functionality to a Jabber client able to communicate over D-Bus. It uses the Farsight library.
+
 
 +
Many Jabber clients will want to implement the Jingle Audio protocol (and eventually other Jingle protocols as well), but may lack the technical possibility to keep an internal implementation. (or just the will to reinvent the wheel ☺) [http://emacs-jabber.cvs.sourceforge.net/emacs-jabber/tox/ Tox] (Talk Over XMPP) is a D-Bus service meant to provide Jingle functionality to a Jabber client able to communicate over D-Bus. It uses the Farsight library.
  
 
The goals of this project are:
 
The goals of this project are:
 +
 
* Beat Tox into good enough shape to perform audio conversations
 
* Beat Tox into good enough shape to perform audio conversations
 
* Make at least one Jabber client implement the Jingle protocol through Tox (possibly jabber.el, which is the current development platform)
 
* Make at least one Jabber client implement the Jingle protocol through Tox (possibly jabber.el, which is the current development platform)

Latest revision as of 09:19, 23 June 2017

The XMPP Standards Foundation has once again been accepted to participate in the Google Summer of Code for 2008. We're using this page, the jdev discussion list, and the jdev chatroom to talk about potential Summer of Code ideas. Also free free to chat with developers working on particular codebases.

Introduction

XMPP is the Extensible Messaging and Presence Protocol, an XML wire protocol for real-time communication that emerged from the Jabber open-source community. Our community is not a traditional open-source project because it is not focused on a single codebase. Instead, our community is centered around open standards and open protocols. However, even though there are closed-source implementations of XMPP, we still have a strong commitment to open code and there are many free and open-source projects in our community.

We have participated in the Summer of Code since its inception and have learned many lessons, among them:

  • We try to choose half a dozen excellent projects and really focus on them.
  • It is difficult to choose excellent projects, so the more helpful information you can provide, the better.
  • We also try to choose excellent mentors and match students with mentors.
  • We expect regular reporting (via blog) and weekly or bi-weekly meetings.
  • We take the Summer of Code very seriously and we expect our students to treat it like a full-time job.

This page lists some potential project ideas that students can work on. This is similar to a "Request for Proposal" process for your summer job. The mentors and other project members have defined these RFPs as a way to help structure the summer work. Many of these projects are are relevant to our overall community roadmap. A select team of longtime XMPP developers and former mentors will review all the student proposals and "interview" many of the students so that we can make the best possible choices.

If you have any questions about the XSF's involvement with the Google Summer of Code, please contact Peter Saint-Andre via email or (preferably) IM.

Thanks for your interest, and good luck!

How to Apply

Application instructions are available at the main GSoC site -- see here.

Here is what you should include:

  • Some details about you (what code languages you like, what programming courses you've taken, etc.)
  • Results of your preliminary research into the protocols and codebases you might work on
  • Your ideas about how to approach the project, including an outline of what work you think is required, a rough timeline of the work, etc.
  • Possible problems you think you may face

In general, we consider your GSoC project to be a summer job, so try to provide detailed information that will enable us to decide if you deserve to earn $4500. Our project ideas are like "RFPs" -- your application is your proposal to get the job. Please treat it seriously. Thanks!

Clients

Coccinella

Jingle video using iaxclient

  • Proposed Mentor: Mats Bengtsson
  • Programming language: C (knowledge of Tcl/Tk is a plus but not required!)

Project description

The goal is to integrate and implement the video part from the iaxclient project with Coccinella.

This project involves two distinct tasks:

  1. Write a Tcl/Tk widget integrating video from the iaxclient package. There already is a Tcl package available in Coccinella for iaxclient audio that can be reused.
  2. Include this video widget into Coccinella. A Tcl package supporting the Jingle protocol exists and is being used by the audio package.

Iaxclient as a cross-platform C library for unix-like systems, Windows, and Mac OS X. It is fairly high level and takes care of codecs, some negotiating, network, and grabbing. The work involves mainly C coding and some Tcl coding. Only C coding knowledge is required to participate. There already exist video widgets for Tk which can be used as templates (QuickTime and DirectShow). The student may pick any of the supported platforms for the work since all components are cross-platform.

Jingle file transfer

  • Proposed Mentor: Mats Bengtsson
  • Programming language: C/C++ and/or Tcl

Project motivation

Transporting files from one user to another is plagued by NATs and firewalls. In ancient times a standard Tcp connection was all that was needed. Instead various application level protocols have been implemented on top of Udp which handles NATs much better. This "reinventing the wheel" by having to reimplement a kind of pseudo Tcp stack on top of Udp is a very unfortunate situation which lacks standardization.

Implementation

This projects aims to use Google gTalks Jingle implementation as a starting point. Ufortunately it is written in C++ and deeply tied into the application notifier system and therefore not reusable as is. Instead the task will be to use the Tcl Udp C code implementation, and essentially use gTalks PseudoTcp class as a wrapper. There are two possible options here: either do a pure Tcl script implementation of the tricks used in PseudoTcp, which I'm not sure is possible, or just translate the C++ class into C code and wrap up the tcludp package to a pseudo tcp (ptcp) command. This should work just like the standard Tcl socket command and should be able to use it transparently.

Jingle contains several parts but the actual jingle xmpp protocol stack is already running and used for voip. A limited STUN client has also been implemented in pure Tcl, but some support for the ICE protocol will likely be necessary.

Relevant XEP

Aquarium for kids

Project description

This project involves the creation of an interface for kids to Coccinella. You need to create a new roster style, the fishy roster style, with an aquarium containing fishes that represents the contacts (like ralphm's Jabber Aquarium). The fishes need to be be animated with User Mood. For example, when a contact is happy, the fish will swim quickly in the aquarium with a smile on his face. The graphics will be done in 2D, but when time allows, they can be made in 3D.

The programming tools will be Tcl/Tk and the tkpath graphics extension package [1] which provides high quality graphics on all platforms. There exists an albeit primitive SVG importer so the actual graphics elements can be obtained from a SVG drawing tool.

This project will involve mostly new code, and few boring code rewriting.

Psi

Message history

  • Proposed Mentor: Kevin Smith
  • Programming language: C++ / Qt toolkit

Psi's current history system is not very usable - this project would involve a student replacing it with a more usable UI, implementing history for groupchat, and using server-side history. Since Psi is a widely-used client, this project would be of particular benefit to a large number of the Jabber/XMPP community.

Themable WebKit-based Chat Dialogs

  • Proposed Mentor: Remko
  • Programming language: C++ / Qt toolkit

It's a widely accepted fact that Adium is one of the best looking IM clients out there. Besides the fact that nearly all native Mac OS X apps look good, Adium draws a lot of it looks from its themable chat dialogs. These dialogs use WebKit to draw their contents. WebKit is an open source web engine, used by Apple in Safari, and even throughout the whole Mac OS X operating system. The good news is that, in the next Qt release, there will be a built-in integration with WebKit, which is good news for Psi.

In this project, the student will create a themable, WebKit-based chat dialog. Additionally, the chat dialog should be themable with the distributed Adium themes, in order to be able to enjoy a wide set of themes out of the box. Another property of this chat dialog is that it would be decoupled from Psi itself, which would ease initial development, testing, and allow easy porting to other Qt-based IM clients.

Gajim

Plugin system

  • Proposed Mentor: Yann Leboulanger
  • Programming language: Python / GTK+

The goal would be to refactor the way events are handled in Gajim, in order to implement a plugin system. There need to be some GUI hooks, and data flow hooks. The objective is to setup the system and to add some hooks as a proof of concept. Some more hooks will be added later. Second objective is to write one or two plugins as examples.

BOSH authentification

  • Proposed Mentor: Yann Leboulanger
  • Programming language: Python

Title tells all. Bosh is an authentification methode based on HTTP. It's described in XEP-0124. It has to be implemented in our fork of xmpppy library.

New Clients

Modern Web-based Jabber/XMPP Client

Despite all the AJAX/Web 2.0/... hypes, and despite the plethora of closed web-based IM clients (Meebo, Google Talk Gadget, GMail/Talk, ...), there still exists no open, free, and attractive web-based Jabber IM client. In this project, the student will try to fill this void, or at least build a solid foundation towards the ultimate web-based IM client.

In order to achieve the goal, the student should try to re-use as much of the existing libraries and frameworks, in order to be able to focus on the goal of the project. For the server-side backend, there is a good choice of frameworks in many different languages, including Ruby and Python. For the frontend, existing frameworks exist to build good looking javascript based user interfaces without much trouble (e.g. ExtJS). The student will have to investigate which frameworks suit the project (and the student) best, implement the missing parts on the server-side if necessary (e.g, BOSH), and build a user interface using the building blocks provided by the web UI libraries.

stpeter saith: You mean like Soashable? :-)

xmpp4moz/SamePlace

PubSub ATOM aggregator

This is an idea to develop a XUL xmpp4moz-based PubSub ATOM aggregator. The aggregator would support XEP-0060 PubSub, ATOM-over-PubSub and XEP-0136 Message archiving so that feeds could be synched across multiple computers and their state saved. It could be possible to download all feeds for offline/disconnected mode. The aggregator could be developed as a stand-alone application and as an extension for Firefox and Thunderbird, or/and integrated in SamePlace. -- User:Kael

I would be willing to (help) mentor this project -- -- User:Itay

Mozilla PubSub application configuration extension

This is an idea to develop an extension for xmpp4moz/SamePlace to save Firefox and Thunderbird settings remotely, following the PubSub persistent storage model defined by XEP-0223, similarly to ACAP (cf. RFC2244 and ACAP Internet-Drafts).

This extension would allow to save Firefox browser settings, bookmarks, history, cookies, Sherlock and OpenSearch search engine plugins ; and Thunderbird email, newsgroups and feeds accounts, and configuration settings on an XMPP server. -- User:Kael

Servers

ejabberd

Mentor: Mickaël Rémond (email: mremond@process-one.net / jid: mremond@process-one.net).

Those proposals for GSOC projects could be implemented in any Jabber server and programming language. However, they are specially easy to implement in ejabberd for several reasons:

  • ejabberd modularity allows to implement those features without requiring changes in ejabberd core
  • there are several contributed modules that can serve as example for some parts of the features
  • The Open Source Erlang/OTP distribution includes many libraries that implement common small tasks, and can be used freely because they are available in any ejabberd deployment
  • The erlang declarative programming language allows easy prototyping: no need to declare functions, variables, etc just to implement a function/module and try it.

Page for Account Registration & Password Recovery

Develop a module for ejabberd that provides a page to create account, change password and recover lost password.

Motivation There are two different problems that are of great importance for public servers and the XMPP federation as Jabber gets increasing popularity:

  • In-band account registration of Jabber accounts (XEP-0077) can be abused easily by spammers. For example, a spammer could create a million of accounts in jabber.org easily, and then put 100 zombie machines to login to those accounts and send spam to everywhere in the XMPP Federation.
  • There isn't a generalized way to recover a forgotten password of a Jabber account. Since In-band account registration (XEP-0077) is the standard way to create Jabber accounts since 1999 until now, Jabber accounts do not have email accounts associated. Hence, it isn't possible to recover a forgotten password automatically. The solution right now is to contact an admin in the Jabber server, which will change the password manually and send an email with the new password.

Details This proposal attempts to fix both problems. It consits in three related tasks:

  • Provide a registration page. The page requests: username, password, repeat-password, email address. When filled the form, it registers the account in the local ejabbed server. The email address is NOT stored in the user's vcard; it is stored in a secure a private way, just like the password. Optional elements:
  1. The page could also include a captcha to require registration
  2. The page could send an email instead of registering the account. If the email is responded correctly, then the account is created
  • Provide a page to change the password and email addresProvide also. Of course, this page will require the valid username and password in order to change the information.
  • Provide a page to recover the forgotten password. The page only requires a valid username. Then it sends an email to the address stored for that account. If the email is answered correctly, the password is changed and the new one is sent by email.

Existing work

  • ejabberd 2.0.0 allows to provide web pages easily using the feature request_handlers in the service ejabberd_http. Example: mod_http_bind, mod_http_fileserver, mod_webpresence.
  • There is an old and experimental contributed module, mod_passrecover, that implements part of task 3. It could be used as an example
  • Example of registration page, this one is written in PHP: http://www.jabberes.org/jrt/

Time Tracker

Implement an ejabberd module that tracks how much time a Jabber account is online in each presence type. Reports can be check by the user and/or admin.

Its usage is voluntary for the user, as programs like KArm, GnoTime, TaskCoach. Instead of requiring a specific desktop program, this project uses the presence set in the Jabber client to track the time invested in each task.

Example Track

  • When I start my work in the morning, I start my Jabber client and login to my working account. Then set presence 'busy' with status message 'Doing GSOC: write cases for test suite'. The Time Tracker captures that and stores the meaningful information.
  • At midday I change to 'xa' with text 'Launch time'.
  • During the afternoon I set to 'busy' again, but status message 'Doing study: homework'.
  • When I am interrupted for more than 5 minutes, my Jabber client sets to 'autoaway', and the Time Tracker will also notice that.

Example Report At the end of the day, I can access the Time Tracker interface (web, adhoc or whatever) and ask the report. For example, it can report:

Today:

  • busy - Doing GSOC: write cases for test suite - 5 hours and 30 minutes
  • busy - Doing study: homework - 2 hours and 10 minutes
  • xa - Launch time - 40 minutes

Last Week (last 7 days):

  • busy - Doing GSOC: write cases for test suite - 30 hours and 30 minutes
  • busy - Doing study: homework - 7 hours and 10 minutes
  • xa - Launch time - 2 hours and 53 minutes
  • xa - Dinner time - 2 hours and 12 minutes
  • online - Browsing the web - 3 hours

Existing work

  • ejabberd 2.0.0 provides the feature request_handlers in the service ejabberd_http, so it's easy to provide web pages. Example: mod_http_bind, mod_http_fileserver, mod_webpresence.
  • There are contributed modules that track presence changes and can be used as examples: mod_logxml, mod_statsdx, ...

XMPP to XMPP gateway

With the release of exmpp, writing an XMPP client is now easy. Writing a gateway that allow user of a given ejabberd server to reuse their other or old XMPP/Jabber account it a useful project.

The development can be developed in Erlang and leverage the existing work on exmpp. It might also involve to improve the Erlang XMPP library itself.

Openfire

Here are some nice features that would be nice to have in Openfire. We are still working on the list which should be ready for early next week (March 25th). If you have other ideas not listed here feel free to send us an email to discuss it or post it here.

  • File Repository and Sharing (including WebDAV)
  • File transfers for gateways
  • Group Chat for Gateways
  • Update and improve BOSH support
  • Complete XMPP RFC implementation in XIFF and work on web client

For more details, visit the Summer of Code 2008 Projects.

Contacts

Mentor: Gaston Dombiak (email: gaston@jivesoftware.com / jid: gato@jivesoftware.com).

PJS

The PJS project aims to create a reliable, correct and highly scalable XMPP server framework in Python, not unlike what ejabberd is to Erlang. It was started as an undergrad project at the University of Toronto in February 2008. By the start of GSOC, the server should have the following components:

  • basic connection handling
  • internal message routing (with chained handlers)
  • a way to run blocking handlers in threads
  • presence, subscriptions, roster get/set, message
  • sqlite backend for user, roster and offline messages storage

The server will not be production quality by the end of the semester, though it will have substantial progress toward this goal. Some of the things that may need to be written:

  • S2S handling (already has parts of it)
  • Privacy lists (may have parts of it by May)
  • Clustering. This could use something like pylinda or PyRO to distribute jobs among machines.
  • Pick any XEP you'd like to implement. Dialback (XEP-0220) may be already implemented by May.

Because the project is a part of a course, its code cannot be released until the course is over (around May 1, 2008). The project will be licensed under the PFL (same license as that for Python).

The architecture is as follows:

  • asynchronous event handling using asyncore (low per-connection memory overhead)
  • chained handlers in pairs (handler + error handler), where each can be run either in-process or in a threadpool.
  • everything is a plugin (which is just a handler class)
  • everything can be redefined at run-time (little protection, but lots of power)

Contacts

Mentor: David Janes (email: davidjanes@blogmatrix.com / jid: davidjanes@gmail.com). Current developer: Dmitri Vassilenko (email: tro@glyphy.com / jid: troworld@gmail.com).

Also see Python's SOC page (under Dr.Project)

Components

New

IRC-to-MUC bridge

Project Description

This idea is about writing a XMPP Component which acts as a bridge between a IRC network and open and federated XMPP servers. For an IRC network it looks like another server in the network which is connected via one of the custom IRC server-to-server protocols. The component should be written extensible so it's easy to make it work with the different servers like Hyperion or UnrealIRCD. For the XMPP world the component is connected to a XMPP server und some domain like myirc.example.com. When a user from XMPP world joins the Multi User Chat hello@myirc.example.com, the component will map this as a login to #hello on some IRC network. Since most IRC servers are written in C or C++ it seems to be best that this component is written in C or C++ as well.

Libraries you can use are found under http://xmpp.org/software/libraries.shtml

XMPP Transport/Gateway

Project Description

Write a XMPP transport/gateway which enables to use other jabber accounts through only one. It should cover things like transporting presence, messages, roster groups, PEP events and if there is time left even more. Transports like that will make migration XMPP accounts easier.

Sync mode for clients

Project Description

Write a protocol extension to create a "sync mode" for clients. The idea is to broadcast all a user's incoming and outgoing messages to all of the user's connected resources, so that the user can move between clients on different devices with no interruption. It should also have the option of preserving a client's window state, so that opening or closing a window on one client causes the window to be open or closed on all connected clients.

Idea submitted by User:Andrewy, who has done a more in-depth writeup here.

JMS-to-XMPP bridge

Project Description

Java Message Service (JMS) provides enterprise messaging features that are similar to both XMPP pubsub and standard XMPP messaging with http://xmpp.org/extensions/xep-0184.html receipts]. This project would involve writing a bridge between JMS and XMPP so that messages could be shared across systems. This bridge might take the form of a server-side component or a common API. For more details, see here and [2]. Possible mentor: Fabio Forno.

Universal Transport via libpurple

Project Description

The libpurple library is used in Pidgin and Adium for their multi-protocol support. This component would interface from XMPP to libpurple via an existing C or C++ XMPP library such as gloox, iksemel, loudmouth, or libstrophe. As a result, the component would automatically translate to any of the protocols that libpurple supports, including AIM, Bonjour, Gadu-Gadu, Groupwise, ICQ, IRC, MSN, MySpaceIM, QQ, SILC, SIMPLE, Sametime, XMPP, Yahoo!, and Zephyr. Possible mentor: Andreas Monitzer

pyICQ-t Fixing and File Transfers

Project Description

With the introduction of ICQ 6, a lot of the ICQ protocol was changed. For example, the old charset problem was solved, UTF-16 is used almost everywhere, it seems that text/x-aolrtf finally died now and status messages are now allowed for every status, even the online status, but most is done via new SNACs. While most of these changes fix severe problems, they also introduced incompatibilities (status messages not shown in older clients / newer clients, charset problems with older / newer clients). Your task would be to analyze the new protocol, update pyICQ-t and/or Twisted to the new protocol, think of a way that works with old and new clients and fix every bug you find during that which was introduced by the ICQ 6 protocol. If there's enough time, your task would also be to figure out how ICQ file transfers (especially in ICQ 6) work and implement them.

Possible mentor: User:Js

Libraries

gloox

Serverless Messaging aka Local-Link

Project description

Write up a platform independent implementation of XEP-0174 for gloox. Platforms supported should be *NIX (including Mac OS X), linux and windows.

http://xmpp.org/extensions/xep-0174.html

Other

ISS (Instant Syndicating Standards)

Project description

Further develop ISS (Instant Syndicating Standards), built on top of PEP (Personal Eventing via PubSub). Please see website or contact User:NickVidal for more details.

PubSub Wordpress and Drupal plugins

Project description

This is an idea to develop a PubSub plugin for WordPress and Drupal with Atom notifications The goal is to ease the publication with PubSub and to create an XMPP PubSub ecosystem.

Blogs could support an autodiscovery element like :

<link rel='alternate' type='xxxx' href='xmpp:romeo@jabber.org?;node=blog'/>

(The "type" is yet to be determined...)

Each new post could generate a new leaf node which would contain the post per se and the comments. In this manner, users could subscribe to the thread of their choice directly from the blog by clicking on an RSS-like button.

Or there would be one node (not a separate node for each blog post!), as described at http://mail.jabber.org/pipermail/jdev/2008-March/026352.html

There already exists the Idavoll HTTP-XMPP PubSub gateway and Class.Jabber.PHP with ATOM over XMPP Pubsub. There is also the DiSo XMPP WordPress plugin in development.

XEP-0070 for the Drupal Jabber authentication module

Project description

Drupal implements a Distributed Authentication System which allows to use Jabber credentials to log onto every Drupal sites (e.g. the Ejabberd site). But it requires to pass the password to third-party sites often without encryption.

Inspired from The South African XMPP Federation OpenID Server, the Drupal Jabber authentication module could support XEP-0070: Verifying HTTP Requests via XMPP so that users could authenticate to Drupal sites with their JID in a secured manner thanks to a confirmation ticket.

SSH authentication validation with XEP-0070

Project description

The idea is to implement an additional security layer for SSH authentication with XEP-0070: Verifying HTTP Requests via XMPP.

When authenticating to the SSH server by password or by key, the user would receive an XMPP confirmation message which would need to be validated to achieve authentication. In this manner, even if the SSH password or the key were compromised they still could not be used.

It has the drawback of requiring to have an XMPP server always running and may not be suitable for some cases.

XMPP Webmin interface

Project description

This is an idea to implement an XMPP interface for Webmin, a web-based interface for system administration for Unix. Inspired by the example of XEP-0050: Ad-Hoc Commands, this software would allow system administrators to remotely manage and configure their server through data-forms.

It would also allow to select events to be notified of (via messages or PubSub), and processes to monitor (via presence or PubSub), perhaps in conjunction with SNMP.

This would require a high-level of security, especially end-to-end encryption.

Additionally, it could allow to use Jabber chat windows as shell consoles.

Flyspray Bot

Project description

It would be really nice to have a bot for the Flyspray bug tracking system which allows to add, delete and edit bugs via ad-hoc commands and chat messages. Additionally it could send out the XMPP notifications which is currently done by a php script.

Links

Client-Independent Serverless IM component

Currently, only some clients (iChat, Gajim) support server-less chatting, a feature which is very interesting to be able to discover and communicate with people on a local network, without the need to be connected to the internet. The reason behind the slow adoption of this protocol is probably that it breaks with the very fundamental way Jabber is designed (client-server architecture), and as such is a significant amount of work for an existing client to adapt its codebase. The aim of this project is to bring server-less messaging to every XMPP client, by implementing it outside of the client.

The goal of this project is to implement a lightweight Jabber daemon that acts as a regular jabber server on the client side, but uses Link Local Messaging on the server side. By connecting your favorite client to this daemon running on your own machine, you enable server-less messaging for this client. The project should be written in a cross-platform way to reach a large population of clients. Language can be chosen, as long as there is a decent library available to do zeroconf networking, and preferably a (core) xmpp library as well (examples include Python and C++).

Some information about link-local chatting (biased towards Psi) can be found here.

Client-Independent D-Bus Service for Jingle Audio

Many Jabber clients will want to implement the Jingle Audio protocol (and eventually other Jingle protocols as well), but may lack the technical possibility to keep an internal implementation. (or just the will to reinvent the wheel ☺) Tox (Talk Over XMPP) is a D-Bus service meant to provide Jingle functionality to a Jabber client able to communicate over D-Bus. It uses the Farsight library.

The goals of this project are:

  • Beat Tox into good enough shape to perform audio conversations
  • Make at least one Jabber client implement the Jingle protocol through Tox (possibly jabber.el, which is the current development platform)
  • (optional) In said client(s), support the protocol used by the Google Talk client for audio conversations
  • (optional) Jingle Video
  • (optional) Jingle File Transfer

This project needs a mentor, as User:Legoscia will be offline during great parts of the summer.