Difference between revisions of "Summer of Code 2008"

From XMPP WIKI
Jump to navigation Jump to search
Line 185: Line 185:


=== Serverless (Link-Local) IM component ===
=== Serverless (Link-Local) IM component ===
Submitter:  ([[User:Remko|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 (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 (examples include Python and C++).

Revision as of 06:57, 18 March 2008

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!

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

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

Message history

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.

Servers

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://jabber.org.


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.

Libraries

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 Nick Vidal 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 eco-system.

Blogs could support an autodiscovery element like :

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

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.

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

Flyspray Ad-Hoc Commands


Serverless (Link-Local) IM component

Submitter: (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.

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 (examples include Python and C++).