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

Jump to navigation Jump to search

Summer of Code 2011 Project Ideas (view source)

Revision as of 09:26, 23 June 2017

83 bytes added ,  09:26, 23 June 2017
Restored from backup.
m (Everyore else has been adding their ideas to the end of the document. It seems only fair for OSW to do the same.)
 
(Restored from backup.)
 
Line 1: Line 1:
Listed below will be some project ideas for the XSF's involvement in [http://socghop.appspot.com/ GSoC 2011]. Visit our [[Summer of Code 2011]] page for information about applying. You are also very welcome to propose your own ideas for the participating projects below, but please be aware that the XSF generally prefers contribution to existing projects that are active in the community, and shies away from proposals to create entirely new software projects.
Listed below will be some project ideas for the XSF's involvement in [http://socghop.appspot.com/ GSoC 2011]. Visit our [[Summer of Code 2011]] page for information about applying. You are also very welcome to propose your own ideas for the participating projects below, but please be aware that the XSF generally prefers contribution to existing projects that are active in the community, and shies away from proposals to create entirely new software projects.


== Open Social Network projects ==
= Open Social Network projects =


I believe we are at an important stage in the evolution of social networks where users start to run their own nodes using software from groups like Diaspora, OSW and buddycloud.  
I believe we are at an important stage in the evolution of social networks where users start to run their own nodes using software from groups like Diaspora, OSW and buddycloud.


We all know why distributed social networks are a good thing. But we are missing components that provide additional services to social networks. Plug-ins if you will. A plug-in to manage location. A plug-in to manage media etc.
We all know why distributed social networks are a good thing. But we are missing components that provide additional services to social networks. Plug-ins if you will. A plug-in to manage location. A plug-in to manage media etc.


The unix philosophy of "write programs that do one thing and do it well, write programs to work together" is very relevant to building an open social network.  
The unix philosophy of "write programs that do one thing and do it well, write programs to work together" is very relevant to building an open social network.


XMPP, like Unix's design, gives us a nice interface to [http://m.buddycloud.com/tmp/proofs/buddycloud%20architecture.png build components that handle tasks] of work like calculating location, delivering media, serving a directory of channels.
XMPP, like Unix's design, gives us a nice interface to [http://m.buddycloud.com/tmp/proofs/buddycloud%20architecture.png build components that handle tasks] of work like calculating location, delivering media, serving a directory of channels.


New buddycloud clients will have "plugins" that are really just addresses to xmpp components:
New buddycloud clients will have "plugins" that are really just addresses to xmpp components:
 
* media server: media.picture-vault.com
* media server: media.picture-vault.com
* location server: engine.location-service.com
* location server: engine.location-service.com
* channel directory: directory.example.com
* channel directory: directory.example.com
* search service: channels.collecta.com
* search service: channels.collecta.com
All project work will work in parallel with an upcoming XEP that will try to codify an approach to providing standardized federated social networking services.
All project work will work in parallel with an upcoming XEP that will try to codify an approach to providing standardized federated social networking services.


=== Mentoring process ===
== Mentoring process ==
GSOC mentors need to devote significant time to the process; we're passionate about creating an open social network and getting buddycloud usable by everyone. We are willing to devote all the time necessary to make you efficient at "building the future".
 
GSOC mentors need to devote significant time to the process; we're passionate about creating an open social network and getting buddycloud usable by everyone. We are willing to devote all the time necessary to make you efficient at "building the future".


To make you efficient we plan on doing this by coming up with good [http://en.wikipedia.org/wiki/User_story user-stories] (RFC MUST/SHOULD style plus acceptance criteria), creating specific technical tasks, code review sessions, and testing. Astro will be your main mentor and available for all code and XMPP questions. Simon Tennant will be your backup mentor and help arrange your meeting plans and connect you with the right people at each stage of your project. He will also help you define the system architecture and a timeline. Rene will also be available for client and server specific code questions. Additionally there is an active buddycloud dev chat-room and mailing list for general questions.
To make you efficient we plan on doing this by coming up with good [http://en.wikipedia.org/wiki/User_story user-stories] (RFC MUST/SHOULD style plus acceptance criteria), creating specific technical tasks, code review sessions, and testing. Astro will be your main mentor and available for all code and XMPP questions. Simon Tennant will be your backup mentor and help arrange your meeting plans and connect you with the right people at each stage of your project. He will also help you define the system architecture and a timeline. Rene will also be available for client and server specific code questions. Additionally there is an active buddycloud dev chat-room and mailing list for general questions.
 
== Open social location server ==


=== Open social location server ===
build a social location server that helps users share their location in a trusted way with their friends and query for nearby data.
build a social location server that helps users share their location in a trusted way with their friends and query for nearby data.


Line 29: Line 33:


A social location server needs to allow uses to bookmark locations that are then stored as either just a name or with incrementally more information such as address, associated wifi and cellID data and perhaps even a lat/long. The location server runs as an XMPP component and should be deployable by anyone that wants to offer location services to anyone else on buddycloud (or other networks too). The server should:
A social location server needs to allow uses to bookmark locations that are then stored as either just a name or with incrementally more information such as address, associated wifi and cellID data and perhaps even a lat/long. The location server runs as an XMPP component and should be deployable by anyone that wants to offer location services to anyone else on buddycloud (or other networks too). The server should:
* Receive XEP-0255 formatted beacon data (wifi-MACs, Cell-ID, GPS)
* Receive XEP-0255 formatted beacon data (wifi-MACs, Cell-ID, GPS)
* Pull in with Open StreetMap data and Google Local data sources to reverse geo-locate lat-long
* Pull in with Open StreetMap data and Google Local data sources to reverse geo-locate lat-long
Line 40: Line 45:
Skills: GIS functions, database scaling techniques, XMPP component design
Skills: GIS functions, database scaling techniques, XMPP component design


=== iOS XMPP client with pub-sub support ===
== iOS XMPP client with pub-sub support ==


'''An open-source XMPP client for iPhones and iPads with support for open social networking. AKA, get standards compliant XMPP based social networking into the hands of of the masses.'''
'''An open-source XMPP client for iPhones and iPads with support for open social networking. AKA, get standards compliant XMPP based social networking into the hands of of the masses.'''
Line 46: Line 51:
Difficulty: ''Medium - Hard''
Difficulty: ''Medium - Hard''


To be successful, this project will deliver and XMPP client that is easy to use, and standards compliant. It should handle roster synchronisation and use XEP-0198 to ensure reliable message delivery on an unreliable mobile network. The iOS client should also provide integrated social networking functions that can challenge the closed Twitter and Facebook hegemony.  
To be successful, this project will deliver and XMPP client that is easy to use, and standards compliant. It should handle roster synchronisation and use XEP-0198 to ensure reliable message delivery on an unreliable mobile network. The iOS client should also provide integrated social networking functions that can challenge the closed Twitter and Facebook hegemony.


It should provide the following social features:
It should provide the following social features:
* location updating and sharing with XEP-0080 and XEP-0255
* location updating and sharing with XEP-0080 and XEP-0255
* do channel posting and updating using pub-sub
* do channel posting and updating using pub-sub
Line 58: Line 64:
Skills: Good XMPP knowledge. XMPPFramework skills.
Skills: Good XMPP knowledge. XMPPFramework skills.


===Realtime search service for pub-sub nodes ===
==Realtime search service for pub-sub nodes ==


"Build a library that makes it easy to search for content in pub-sub nodes"
"Build a library that makes it easy to search for content in pub-sub nodes"


Difficulty: ''Medium - Hard''
Difficulty: ''Medium - Hard''


Pub-sub servers shipped with XMPP servers are gaining increased use. Additionally pub-sub like "code-on-a-node" projects are gaining traction.  
Pub-sub servers shipped with XMPP servers are gaining increased use. Additionally pub-sub like "code-on-a-node" projects are gaining traction.


The aim of this project is to develop a library to help search through indexed pub-sub node content.
The aim of this project is to develop a library to help search through indexed pub-sub node content.
Line 70: Line 76:
The library should be easily re-usable in other applications to enable searching and notifications based on content or specific changes to that content.
The library should be easily re-usable in other applications to enable searching and notifications based on content or specific changes to that content.


This would let users perform queries like "Show me all pub-sub updates that contain #FOSDEM" or "Show me all changes to nodes already containing #FOSDEM"
This would let users perform queries like "Show me all pub-sub updates that contain #FOSDEM" or "Show me all changes to nodes already containing #FOSDEM"


Ideally this content could even be redistributed using pub-sub.
Ideally this content could even be redistributed using pub-sub.
Line 76: Line 82:
Skills: pub-sub, node.js (or similar async languages)
Skills: pub-sub, node.js (or similar async languages)


=== Channel Directory ===
== Channel Directory ==
"make it super easy for users to find interesting channels"
 
"make it super easy for users to find interesting channels"


Difficulty: ''Medium - Hard''
Difficulty: ''Medium - Hard''


When a user joins a new social network it's really important to get them hooked up with interesting content. Fast. The user needs to have an almost immediate "this is cool" or "I didn't know that there were other channels or users nearby" moment in the first minute of using a client.
When a user joins a new social network it's really important to get them hooked up with interesting content. Fast. The user needs to have an almost immediate "this is cool" or "I didn't know that there were other channels or users nearby" moment in the first minute of using a client.


This project aims to build a distributed directory service that would run as an XMPP component.
This project aims to build a distributed directory service that would run as an XMPP component.


Channel server operators would select a node running your software as the recommended directory service to find channels. Channel clients query your software for "show me channels nearby to lat/long", "show me channels similar to beer@budvar.cz". Your service would then return lists of channels based on nearby-ness, popularity, or if you feel like getting clever, a [http://mahout.apache.org mahout] based taste engine.
Channel server operators would select a node running your software as the recommended directory service to find channels. Channel clients query your software for "show me channels nearby to lat/long", "show me channels similar to beer@budvar.cz". Your service would then return lists of channels based on nearby-ness, popularity, or if you feel like getting clever, a [http://mahout.apache.org mahout] based taste engine.


Skills: pub-sub, perhaps mahout, component design.
Skills: pub-sub, perhaps mahout, component design.


=== Media Vault ===
== Media Vault ==
 
...because all social networks need cat pictures.
...because all social networks need cat pictures.


Difficulty: ''Medium''
Difficulty: ''Medium''


I'm throwing this up here as an idea and if someone is interested in chatting more and coming up with a firmer project spec then please [mailto:simon@buddycloud.com ping me].  
I'm throwing this up here as an idea and if someone is interested in chatting more and coming up with a firmer project spec then please [mailto:simon@buddycloud.com ping me].


The old non-federated buddycloud had a way to inject media links into your channel. Originally it was a side project of Tuomas Koski, but it really took off with users. Hugely so.  
The old non-federated buddycloud had a way to inject media links into your channel. Originally it was a side project of Tuomas Koski, but it really took off with users. Hugely so.


If this were to turn into a project, the goals would be to find an elegant way to share content in the XMPP world (in your channel) and also in the HTTP world. The solution would also need to be really simple to implement in clients and also fit nicely with ATOM formatted entries.
If this were to turn into a project, the goals would be to find an elegant way to share content in the XMPP world (in your channel) and also in the HTTP world. The solution would also need to be really simple to implement in clients and also fit nicely with ATOM formatted entries.
Line 102: Line 110:
[mailto:simon@buddycloud.com ideas]?
[mailto:simon@buddycloud.com ideas]?


== Swift ==
= Swift =
 
[http://swift.im Swift]'s goal is to provide an IM client that does things 'right': good user interface, solid quality, and standards-compliant. Since Swift is still a young project, there are still several opportunities for new functionality. This page lists some of the high priority tasks the Swift development team has. If you're interested in any of these (or other) Swift ideas, please jump into the [xmpp:swift@rooms.swift.im?join swift@rooms.swift.im] room and chat it over with Remko and Kev. Swift is a C++ project, so C++ proficiency is required, with either knowledge of or willingness to learn about unit testing (and ideally test-driven development).
[http://swift.im Swift]'s goal is to provide an IM client that does things 'right': good user interface, solid quality, and standards-compliant. Since Swift is still a young project, there are still several opportunities for new functionality. This page lists some of the high priority tasks the Swift development team has. If you're interested in any of these (or other) Swift ideas, please jump into the [xmpp:swift@rooms.swift.im?join swift@rooms.swift.im] room and chat it over with Remko and Kev. Swift is a C++ project, so C++ proficiency is required, with either knowledge of or willingness to learn about unit testing (and ideally test-driven development).


=== Conversation History ===
== Conversation History ==
 
* '''Summary''': Implement all aspects of keeping conversation history, both local and remote.
* '''Summary''': Implement all aspects of keeping conversation history, both local and remote.
* '''Difficulty''': Easy-Medium
* '''Difficulty''': Easy-Medium
* '''Details''': Swift doesn't currently store any transcripts. A student would likely start by producing a prototype user interface for accessing chat history, then write the library code to access a remote archive, and plug these together and finally work on a local archive. This is likely to be a very satisfying project, with enough challenge to be interesting, but not so much that it's frustrating - plus it's a very popular feature request.
* '''Details''': Swift doesn't currently store any transcripts. A student would likely start by producing a prototype user interface for accessing chat history, then write the library code to access a remote archive, and plug these together and finally work on a local archive. This is likely to be a very satisfying project, with enough challenge to be interesting, but not so much that it's frustrating - plus it's a very popular feature request.


=== File Transfer Support ===
== File Transfer Support ==
 
* '''Summary''': Implement file exchange using the Jingle XMPP protocol
* '''Summary''': Implement file exchange using the Jingle XMPP protocol
* '''Difficulty''': Medium-Hard
* '''Difficulty''': Medium-Hard
Line 116: Line 127:
** Implement Jingle signaling protocol for file exchange
** Implement Jingle signaling protocol for file exchange
** Implement existing transports for File Transfer in XMPP: SOCKS5 Bytestreams, In-Band-Bytestreams
** Implement existing transports for File Transfer in XMPP: SOCKS5 Bytestreams, In-Band-Bytestreams
** Implement & experiment with new transports, using ICE(-TCP), TURN, ... protocols for firewall traversal
** Implement & experiment with new transports, using ICE(-TCP), TURN, ... protocols for firewall traversal
 
== VoIP Support ==


=== VoIP Support ===
* '''Summary''': Implement support for voice (and optionally video) communication.
* '''Summary''': Implement support for voice (and optionally video) communication.
* '''Difficulty''': Hard. This project requires a strong background in VoIP and Networking
* '''Difficulty''': Hard. This project requires a strong background in VoIP and Networking
Line 125: Line 137:
** Implement firewall traversal (using standard traversal protocols: ICE, TURN, ...)
** Implement firewall traversal (using standard traversal protocols: ICE, TURN, ...)
** Implement real-time-protocol (using standard RTP)
** Implement real-time-protocol (using standard RTP)
** Investigate frameworks for hardware interaction & media encoding/decoding.
** Investigate frameworks for hardware interaction & media encoding/decoding.
 
== Constrained Swift ==


=== Constrained Swift ===
* '''Summary''': Implement support for XMPP protocols that are targeted towards (resource-)constrained environments
* '''Summary''': Implement support for XMPP protocols that are targeted towards (resource-)constrained environments
* '''Difficulty''': Medium
* '''Difficulty''': Medium
* '''Details''': XMPP provides protocols for dealing with 'constrained' environments: session resumption and incremental roster retrieval for bandwidth-constrained situations, BOSH for places where keeping a long-lived connection is hard, SIFT for limiting the amount of incoming traffic, Link-local for serverless locations, ... Support for these protocols is not only interesting when XMPP software is used in these particular situations, it also makes the client faster and more reliable in general. In this project, you will study the protocols that can improve Swift in these situations (Session Management, BOSH, SIFT, Link-local, ...), and extend Swift (and the underlying Swiften XMPP library) to support these use cases.
* '''Details''': XMPP provides protocols for dealing with 'constrained' environments: session resumption and incremental roster retrieval for bandwidth-constrained situations, BOSH for places where keeping a long-lived connection is hard, SIFT for limiting the amount of incoming traffic, Link-local for serverless locations, ... Support for these protocols is not only interesting when XMPP software is used in these particular situations, it also makes the client faster and more reliable in general. In this project, you will study the protocols that can improve Swift in these situations (Session Management, BOSH, SIFT, Link-local, ...), and extend Swift (and the underlying Swiften XMPP library) to support these use cases.


=== Multi-account Support ===
== Multi-account Support ==
 
* '''Summary''': Implement support for multiple accounts
* '''Summary''': Implement support for multiple accounts
* ''Difficulty'': Medium
* ''Difficulty'': Medium
* '''Details''': Swift currently only supports one account at a time. Supporting multiple accounts is one of the most requested features for Swift. Although this is technically not hard to implement, it involves quite some design decisions on providing a clear and easy-to-understand user interface. This project is about designing a good user interface for multiple account support.
* '''Details''': Swift currently only supports one account at a time. Supporting multiple accounts is one of the most requested features for Swift. Although this is technically not hard to implement, it involves quite some design decisions on providing a clear and easy-to-understand user interface. This project is about designing a good user interface for multiple account support.


=== Multi-resource support ===
== Multi-resource support ==
* '''Summary''': Implement and standardize techniques & protocols for supporting being connected with multiple clients simultaneously.
 
* '''Summary''': Implement and standardize techniques & protocols for supporting being connected with multiple clients simultaneously.
* '''Difficulty''': Medium
* '''Difficulty''': Medium
* '''Details''': Although XMPP has supported multiple simultaneously connected clients from the start, the user experience is in practice seldom what a user would expect. This has not been a big problem up until recently, since most people tend to connect with only one client at the same time. These days, however, people are constantly going back and forth between their always-on mobile IM client and their desktop. Enabling a good user experience for this requires new protocols and techniques for transferring conversations between devices, ... This project is about implementing these protocols to streamline the use case of multiple resources
* '''Details''': Although XMPP has supported multiple simultaneously connected clients from the start, the user experience is in practice seldom what a user would expect. This has not been a big problem up until recently, since most people tend to connect with only one client at the same time. These days, however, people are constantly going back and forth between their always-on mobile IM client and their desktop. Enabling a good user experience for this requires new protocols and techniques for transferring conversations between devices, ... This project is about implementing these protocols to streamline the use case of multiple resources


=== Multi-User Chat Support ===
== Multi-User Chat Support ==
 
* '''Summary''': Implement full MUC protocol support, and improve MUC-related UI aspects
* '''Summary''': Implement full MUC protocol support, and improve MUC-related UI aspects
* '''Difficulty''': Easy
* '''Difficulty''': Easy
* '''Details''': Although Swift already supports multi-user chats, the support for it is still basic. For example, things that are still missing are room management/administrutaion, converting a one-to-one chat to a MUC, and other more advanced use cases. This project will improve the MUC support currently present in Swift to also support the more advanced use cases, while still providing a clear and usable UI. Another goal of this project is to work out how to provide a UI that allows you to be in a large number of rooms simultaneously (which is currently hard to manage in most XMPP clients, including Swift).
* '''Details''': Although Swift already supports multi-user chats, the support for it is still basic. For example, things that are still missing are room management/administrutaion, converting a one-to-one chat to a MUC, and other more advanced use cases. This project will improve the MUC support currently present in Swift to also support the more advanced use cases, while still providing a clear and usable UI. Another goal of this project is to work out how to provide a UI that allows you to be in a large number of rooms simultaneously (which is currently hard to manage in most XMPP clients, including Swift).


== User activity/profile ==


=== User activity/profile ===
* '''Summary''': Implement social aspects in user profiles
* '''Summary''': Implement social aspects in user profiles
* '''Difficulty''': Easy
* '''Difficulty''': Easy
* '''Details''': XMPP (Through the PEP offerings) supports many social-ish data structures, including a user's location, their mood and their current activity. A student working on this project would add support for these protocols to Swiften, and build a 'user profile' UI around these data to give a view on a contact's state that goes beyond the usual 'Name, address, telephone number' profile. A nice touch would be adding map overlays to the location data, so you could see where all your friends were on a map together, and the suchlike.
* '''Details''': XMPP (Through the PEP offerings) supports many social-ish data structures, including a user's location, their mood and their current activity. A student working on this project would add support for these protocols to Swiften, and build a 'user profile' UI around these data to give a view on a contact's state that goes beyond the usual 'Name, address, telephone number' profile. A nice touch would be adding map overlays to the location data, so you could see where all your friends were on a map together, and the suchlike.


== Gajim ==
= Gajim =
 
[http://gajim.org Gajim] is a jabber client written in python and GTK. If you're interested in this (or other) project, please jump into the [xmpp:gajim@conference.gajim.org?join gajim@conference.gajim.org] room and talk to Asterix.
[http://gajim.org Gajim] is a jabber client written in python and GTK. If you're interested in this (or other) project, please jump into the [xmpp:gajim@conference.gajim.org?join gajim@conference.gajim.org] room and talk to Asterix.


=== Stream Management ===
== Stream Management ==
 
* '''Summary''': Implement all [http://xmpp.org/extensions/xep-0198.html XEP-0198]
* '''Summary''': Implement all [http://xmpp.org/extensions/xep-0198.html XEP-0198]
* '''Difficulty''': Medium
* '''Difficulty''': Medium
* '''Details''': This extensions has to be implemented at the lowest layer of Gajim: XMPP parser. It requires a careful implementation to not break things, but should not be such a hard project.
* '''Details''': This extensions has to be implemented at the lowest layer of Gajim: XMPP parser. It requires a careful implementation to not break things, but should not be such a hard project.


== Prosody ==
= Prosody =
 
[http://prosody.im Prosody] is an easily extensible jabber server written in [http://lua.org Lua]. If you're interested in any of the following project or have a different nice project idea you want to chat about you can reach the Prosody community in their [http://prosody.im/discuss#chatroom chatroom].
[http://prosody.im Prosody] is an easily extensible jabber server written in [http://lua.org Lua]. If you're interested in any of the following project or have a different nice project idea you want to chat about you can reach the Prosody community in their [http://prosody.im/discuss#chatroom chatroom].


=== Server-side Jingle Support Features ===
== Server-side Jingle Support Features ==
 
* '''Summary''': Implement basic STUN/TURN server and [http://xmpp.org/extensions/xep-0278.html Jingle Relay Nodes] as prosody module.
* '''Summary''': Implement basic STUN/TURN server and [http://xmpp.org/extensions/xep-0278.html Jingle Relay Nodes] as prosody module.
* '''Difficulty''': Medium
* '''Difficulty''': Medium
* '''Details''': STUN and TURN greatly increases the success rate of a connection for protocols using ICE, like [http://xmpp.org/extensions/xep-0176.html XEP-0176].
* '''Details''': STUN and TURN greatly increases the success rate of a connection for protocols using ICE, like [http://xmpp.org/extensions/xep-0176.html XEP-0176].


=== Realtime Monitoring and Statistics ===
== Realtime Monitoring and Statistics ==
 
* '''Summary''': Implement realtime monitoring and statistics viewable via various interfaces, i.e. web interface, for Prosody.
* '''Summary''': Implement realtime monitoring and statistics viewable via various interfaces, i.e. web interface, for Prosody.
* '''Difficulty''': Medium
* '''Difficulty''': Medium
* '''Details''': Collect, prepare and present realtime statistics of a running prosody instance in numbers and fancy graphs. The system should be easy to extend and could include metrics like, memory usage, stanza throughput per connection, connected clients and so on.
* '''Details''': Collect, prepare and present realtime statistics of a running prosody instance in numbers and fancy graphs. The system should be easy to extend and could include metrics like, memory usage, stanza throughput per connection, connected clients and so on.


= PySoy =


== PySoy ==
[http://www.pysoy.org/ PySoy] is 3d cloud game engine for Python 3. The game engine uses XMPP as an open game network in much the same way as the closed Steam, PSN or XBox Live networks. Interested students should join #PySoy on irc.freenode.net and/or [http://lists.pysoy.org/mailman/listinfo/pysoy-dev pysoy-dev@pysoy.org].
[http://www.pysoy.org/ PySoy] is 3d cloud game engine for Python 3. The game engine uses XMPP as an open game network in much the same way as the closed Steam, PSN or XBox Live networks. Interested students should join #PySoy on irc.freenode.net and/or [http://lists.pysoy.org/mailman/listinfo/pysoy-dev pysoy-dev@pysoy.org].
 
== Chat Widgets ==


=== Chat Widgets ===
* '''Summary''': Add new widgets (soy.widgets.*) specifically designed for XMPP IM between players both in and out of game.
* '''Summary''': Add new widgets (soy.widgets.*) specifically designed for XMPP IM between players both in and out of game.
* '''Difficulty''': Easy
* '''Difficulty''': Easy
* '''Details''': Support for buddy lists, chat windows, and [http://xmpp.org/extensions/xep-0050.html ad-hoc command execution] would make implementing a network game much easier. These widgets should be implemented in a generic manner so they can be used for other purposes and modify/extend soy.net classes to be used with them.
* '''Details''': Support for buddy lists, chat windows, and [http://xmpp.org/extensions/xep-0050.html ad-hoc command execution] would make implementing a network game much easier. These widgets should be implemented in a generic manner so they can be used for other purposes and modify/extend soy.net classes to be used with them.
 
== XMPP Client Plugin ==


=== XMPP Client Plugin ===
* '''Summary''': Write a Soy plugin for a popular XMPP client, such as Empathy or Pidgin
* '''Summary''': Write a Soy plugin for a popular XMPP client, such as Empathy or Pidgin
* '''Difficulty''': Easy to Medium (client dependent)
* '''Difficulty''': Easy to Medium (client dependent)
* '''Details''': PySoy is designed such that the Python game code runs on a server and Soy clients, using the same libsoy backend, connect to the server such that games can be played without downloading them. One goal is to allow users to launch a game one of their friends is playing directly inside their XMPP client. As libsoy uses glib/gobject, writing a plugin for a GTK-based XMPP client may be easiest. There's already an early example plugin for web browsers as a starting point, but some additional integration will be needed.
* '''Details''': PySoy is designed such that the Python game code runs on a server and Soy clients, using the same libsoy backend, connect to the server such that games can be played without downloading them. One goal is to allow users to launch a game one of their friends is playing directly inside their XMPP client. As libsoy uses glib/gobject, writing a plugin for a GTK-based XMPP client may be easiest. There's already an early example plugin for web browsers as a starting point, but some additional integration will be needed.
 
== Jingle Voice ==


=== Jingle Voice ===
* '''Summary''': Implement support for player-to-player voice chat using XMPP/Jingle.
* '''Summary''': Implement support for player-to-player voice chat using XMPP/Jingle.
* '''Difficulty''': Medium
* '''Difficulty''': Medium
* '''Details''': Using libraries we already depend on (loudmouth, libnice, libspeex, openal), add voice support support such that players can chat voice with other players and friends who aren't playing the same game but are also using an XMPP/Jingle client with speex support.
* '''Details''': Using libraries we already depend on (loudmouth, libnice, libspeex, openal), add voice support support such that players can chat voice with other players and friends who aren't playing the same game but are also using an XMPP/Jingle client with speex support.


=OneSocialWeb=


==OneSocialWeb==
The [http://onesocialweb.org OneSocialWeb] project aims at leveraging the similarities that XMPP has with social networking, by taking advantage of its capabilities in terms of security, real-time messaging and identity, in order to create a free, open, decentralized, privacy-aware social web. We think of a future in which all social networks work together in a decentralized and open manner similar to e-mail.


The [http://onesocialweb.org OneSocialWeb] project  aims at leveraging the similarities that XMPP has with social networking, by taking advantage of its capabilities in terms of security, real-time messaging and identity, in order to create a free, open, decentralized, privacy-aware social web. We think of a future in which all social networks work together in a decentralized and open manner similar to e-mail.
Our project has an active open-source community, federation is alive and we are increasing the number of protocol implementations. Our code can be found at our [http://github.com/onesocialweb github] site. We have developed a server-side plugin, and one mobile and one web client. You can also join our [http://groups.google.com/group/onesocialweb mailing list] to start getting in touch.


Our project has an active open-source community, federation is alive and we are increasing the number of protocol implementations. Our code can be found at our [http://github.com/onesocialweb github] site. We have developed a server-side plugin, and one mobile and one web client. You can also join our [http://groups.google.com/group/onesocialweb mailing list] to start getting in touch.
Please visit our [http://github.com/onesocialweb/osw-openfire-plugin/wiki/GSoc-Ideas-Page ideas page] to see some of what we propose for the GSoc. Students are also free to come up with their own ideas and suggestions and we will certainly consider them. We will have one mentor to help a student get familiar with the OSW architecture, code and provide guidance on XMPP and related technologies.
Please visit our [http://github.com/onesocialweb/osw-openfire-plugin/wiki/GSoc-Ideas-Page ideas page] to see some of what we propose for the GSoc. Students are also free to come up with their own ideas and suggestions and we will certainly consider them. We will have one mentor to help a student get familiar with the OSW architecture, code and provide guidance on XMPP and related technologies.


Any ideas, questions, etc., please contact: [mailto:diana.cheng@vodafone.com]
Any ideas, questions, etc., please contact: [mailto:diana.cheng@vodafone.com [1]]
Retrieved from "https://wiki.xmpp.org/web/Special:MobileDiff/20"

Navigation menu