Changes

Jump to navigation Jump to search
m
no edit summary
Line 3: Line 3:  
= High-Level Priorities =
 
= High-Level Priorities =
   −
The high-level priorities for the XMPP community are listed here with summaries (see also the [http://xmpp.org/xsf/roadmap.shtml XSF Roadmap]). You may work to implement them in any of the clients, servers or libraries lacking support (see the project-specific lists below).
+
The high-level priorities for the XMPP community are listed here with summaries (see also the [https://xmpp.org/xsf/roadmap.shtml XSF Roadmap]). You may work to implement them in any of the clients, servers or libraries lacking support (see the project-specific lists below).
    
Choose which project you would like to work with, based on the language their codebase is written in, and how well you fit with their community. Discuss your proposal with them directly to see if it is a good idea.
 
Choose which project you would like to work with, based on the language their codebase is written in, and how well you fit with their community. Discuss your proposal with them directly to see if it is a good idea.
Line 9: Line 9:  
== Jingle File Transfer ==
 
== Jingle File Transfer ==
   −
We are working to migrate from the old file transfer method [http://xmpp.org/extensions/xep-0096.html XEP-0096] to a more robust method based on [http://xmpp.org/extensions/xep-0166.html Jingle]. The new Jingle-based method has been implemented in Pidgin but not yet in other clients. We'd love to see more implementations and get more deployment experience with this method so that we can correct and advance the relevant specs, which are:
+
We are working to migrate from the old file transfer method [https://xmpp.org/extensions/xep-0096.html XEP-0096] to a more robust method based on [https://xmpp.org/extensions/xep-0166.html Jingle]. The new Jingle-based method has been implemented in Pidgin but not yet in other clients. We'd love to see more implementations and get more deployment experience with this method so that we can correct and advance the relevant specs, which are:
   −
* [http://xmpp.org/extensions/xep-0234.html XEP-0234: Jingle File Transfer]
+
* [https://xmpp.org/extensions/xep-0234.html XEP-0234: Jingle File Transfer]
* [http://xmpp.org/extensions/xep-0047.html XEP-0047: In-Band Bytestreams]
+
* [https://xmpp.org/extensions/xep-0047.html XEP-0047: In-Band Bytestreams]
* [http://xmpp.org/extensions/xep-0065.html XEP-0065: SOCKS5 Bytestreams]
+
* [https://xmpp.org/extensions/xep-0065.html XEP-0065: SOCKS5 Bytestreams]
* [http://xmpp.org/extensions/xep-0260.html XEP-0260: Jingle SOCKS5 Bytestreams Transport Method]
+
* [https://xmpp.org/extensions/xep-0260.html XEP-0260: Jingle SOCKS5 Bytestreams Transport Method]
* [http://xmpp.org/extensions/xep-0261.html XEP-0261: Jingle In-Band Bytestreams Transport Method]
+
* [https://xmpp.org/extensions/xep-0261.html XEP-0261: Jingle In-Band Bytestreams Transport Method]
    
Pidgin already has Jingle File Transfer, but it still needs implementing in other clients and libraries, see below.
 
Pidgin already has Jingle File Transfer, but it still needs implementing in other clients and libraries, see below.
Line 21: Line 21:  
== Reliability Improvements ==
 
== Reliability Improvements ==
   −
The XSF has defined two specifications that make XMPP communication more reliable: [http://xmpp.org/extensions/xep-0198.html Stream Management] and [http://xmpp.org/extensions/xep-0184.html Message Receipts]. We won't know if these technologies solve the problem until we have more implementation and deployment experience, so we need to get busy coding.
+
The XSF has defined two specifications that make XMPP communication more reliable: [https://xmpp.org/extensions/xep-0198.html Stream Management] and [https://xmpp.org/extensions/xep-0184.html Message Receipts]. We won't know if these technologies solve the problem until we have more implementation and deployment experience, so we need to get busy coding.
    
Servers, clients and libraries need this support (see below).
 
Servers, clients and libraries need this support (see below).
Line 29: Line 29:  
== Mobile Optimizations ==
 
== Mobile Optimizations ==
   −
As with reliable communication, the XSF is actively working on optimizations for mobile environments. The two most relevant specifications are [http://xmpp.org/extensions/xep-0237.html Roster Versioning] and [http://xmpp.org/extensions/xep-0273.html SIFT]. Here again we're looking for more implementation and deployment experience.
+
As with reliable communication, the XSF is actively working on optimizations for mobile environments. The two most relevant specifications are [https://xmpp.org/extensions/xep-0237.html Roster Versioning] and [https://xmpp.org/extensions/xep-0273.html SIFT]. Here again we're looking for more implementation and deployment experience.
    
== Stronger Security ==
 
== Stronger Security ==
Line 35: Line 35:  
Information security is a never-ending, multi-faceted challenge. Some relevant technologies in the XMPP community are:
 
Information security is a never-ending, multi-faceted challenge. Some relevant technologies in the XMPP community are:
   −
* [http://xmpp.org/extensions/xep-0158.html CAPTCHA Forms]
+
* [https://xmpp.org/extensions/xep-0158.html CAPTCHA Forms]
* [http://xmpp.org/extensions/xep-0275.html Entity Reputation]
+
* [https://xmpp.org/extensions/xep-0275.html Entity Reputation]
* [http://xmpp.org/extensions/xep-0268.html Incident Reporting]
+
* [https://xmpp.org/extensions/xep-0268.html Incident Reporting]
    
In addition, we have several competing proposals for end-to-end encryption but they are fairly experimental.
 
In addition, we have several competing proposals for end-to-end encryption but they are fairly experimental.
   −
* [http://xmpp.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-02.html XTLS]
+
* [https://xmpp.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-02.html XTLS]
* [http://xmpp.org/internet-drafts/draft-miller-3923bis-01.html AES]
+
* [https://xmpp.org/internet-drafts/draft-miller-3923bis-01.html AES]
    
= General projects =
 
= General projects =
Line 88: Line 88:  
== Gajim ==
 
== Gajim ==
   −
Gajim is a full-featured and easy to use Jabber client. It is written in Python, uses GTK and integrates well with the GNOME desktop environment (but does not depend on it). You can visit [http://trac.gajim.org/wiki/GajimGSOC Gajim's wiki].
+
Gajim is a full-featured and easy to use XMPP client. It is written in Python, uses GTK and integrates well with the GNOME desktop environment (but does not depend on it). You can visit [http://trac.gajim.org/wiki/GajimGSOC Gajim's wiki].
   −
=== Jingle File Transfer [http://xmpp.org/extensions/xep-0234.html XEP-0234] ===
+
=== Jingle File Transfer [https://xmpp.org/extensions/xep-0234.html XEP-0234] ===
    
Gajim already has socks5 bytestream working, and a work in progress IBB patch. Gajim also has jingle negotiation implemantation for audio / video sessions. So making jingle file transfer work shouldn't be too hard. A harder part is to write the ICE-UDP transport layer, or use XMLL-TLS to encrypt transfers.
 
Gajim already has socks5 bytestream working, and a work in progress IBB patch. Gajim also has jingle negotiation implemantation for audio / video sessions. So making jingle file transfer work shouldn't be too hard. A harder part is to write the ICE-UDP transport layer, or use XMLL-TLS to encrypt transfers.
   −
=== Stream Management [http://xmpp.org/extensions/xep-0198.html XEP-0198] ===
+
=== Stream Management [https://xmpp.org/extensions/xep-0198.html XEP-0198] ===
    
This extensions has to be implemented at the lowest layer of Gajim: xmpp parser. It requires a carefull implementation to not break things, but should not be a hard project.
 
This extensions has to be implemented at the lowest layer of Gajim: xmpp parser. It requires a carefull implementation to not break things, but should not be a hard project.
   −
=== CAPTCHA Forms [http://xmpp.org/extensions/xep-0158.html XEP-0158] ===
+
=== CAPTCHA Forms [https://xmpp.org/extensions/xep-0158.html XEP-0158] ===
    
There are 2 places where captchas can be presented to users: when registering an account, or when joining a groupchat. Here we need to be able to download a picture / sound / video and present it to user so he can reply to the captcha. Gajim has the required code to doewnload files asynchronously. Showing a picture or playing a sound is also possible. What needs to be done is to present them to users when they arrive (using an external tool when it's a video) and show a field to answer. This sounds quite simple to implement.
 
There are 2 places where captchas can be presented to users: when registering an account, or when joining a groupchat. Here we need to be able to download a picture / sound / video and present it to user so he can reply to the captcha. Gajim has the required code to doewnload files asynchronously. Showing a picture or playing a sound is also possible. What needs to be done is to present them to users when they arrive (using an external tool when it's a video) and show a field to answer. This sounds quite simple to implement.
Line 104: Line 104:  
== Psi ==
 
== Psi ==
   −
Psi is a powerful cross-platform Jabber client. It is written in C++ with Qt. You can visit [http://psi-im.org/ Psi's homepage].
+
Psi is a powerful cross-platform XMPP client. It is written in C++ with Qt. You can visit [http://psi-im.org/ Psi's homepage].
   −
=== Stream Management [http://xmpp.org/extensions/xep-0198.html XEP-0198] ===
+
=== Stream Management [https://xmpp.org/extensions/xep-0198.html XEP-0198] ===
    
Support acknowledging messages and restoring sessions from broken connections, so that Psi can be relied on in even the worst of networking conditions. This development would happen in Psi's underlying XMPP library, Iris.
 
Support acknowledging messages and restoring sessions from broken connections, so that Psi can be relied on in even the worst of networking conditions. This development would happen in Psi's underlying XMPP library, Iris.
   −
=== Jingle RTP Encryption [http://xmpp.org/extensions/xep-0167.html#srtp XEP-0167: Negotiation of SRTP]===
+
=== Jingle RTP Encryption [https://xmpp.org/extensions/xep-0167.html#srtp XEP-0167: Negotiation of SRTP]===
    
Currently, voice calls in Psi are not encrypted. Ideally, SRTP would be implemented in Psi's avcall module, though that may depend on how tight of a relationship SRTP needs with the RTP session. If a tight relationship is required, then SRTP may need to be implemented in a lower level module like PsiMedia or GStreamer instead.
 
Currently, voice calls in Psi are not encrypted. Ideally, SRTP would be implemented in Psi's avcall module, though that may depend on how tight of a relationship SRTP needs with the RTP session. If a tight relationship is required, then SRTP may need to be implemented in a lower level module like PsiMedia or GStreamer instead.
   −
=== MUC Overhaul [http://xmpp.org/extensions/xep-0045.html XEP-0045] ===
+
=== MUC Overhaul [https://xmpp.org/extensions/xep-0045.html XEP-0045] ===
    
Psi has decent MUC support but the user interface is lacking in some ways. Better browsing of MUCs, seamless converting of one-to-one chats to MUCs, ability to hide open MUCs or minimize them to the roster, and reconciliation of the join window, MUC bookmarks, and recently joined history, are all things that would be great to see.
 
Psi has decent MUC support but the user interface is lacking in some ways. Better browsing of MUCs, seamless converting of one-to-one chats to MUCs, ability to hide open MUCs or minimize them to the roster, and reconciliation of the join window, MUC bookmarks, and recently joined history, are all things that would be great to see.
   −
=== Whiteboarding [http://xmpp.org/extensions/inbox/sxe.html (Shared XML Editing inbox spec)] ===
+
=== Whiteboarding [https://xmpp.org/extensions/inbox/sxe.html (Shared XML Editing inbox spec)] ===
    
Psi already has a fairly complete implementation of whiteboarding using the experimental SXE spec. In fact it was worked on as a previous GSoC project. However, it is not fully finished and contains some bugs. Given the age of the existing code and specs, a student choosing this project should approach it with a fresh perspective, evaluate the existing proposed XEPs and consider pushing them through XSF standardization, and then correct/refactor/rewrite Psi's existing whiteboarding code as appropriate.
 
Psi already has a fairly complete implementation of whiteboarding using the experimental SXE spec. In fact it was worked on as a previous GSoC project. However, it is not fully finished and contains some bugs. Given the age of the existing code and specs, a student choosing this project should approach it with a fresh perspective, evaluate the existing proposed XEPs and consider pushing them through XSF standardization, and then correct/refactor/rewrite Psi's existing whiteboarding code as appropriate.
   −
=== Message Archiving [http://xmpp.org/extensions/xep-0136.html XEP-0136] ===
+
=== Message Archiving [https://xmpp.org/extensions/xep-0136.html XEP-0136] ===
    
Storing message history centrally on the user's server is a longtime requested feature of Psi and XMPP in general. Also, Psi's user interface for message history is quite dated and should be given a facelift. This was also attempted in a previous GSoC project, although none of the code was merged into Psi.
 
Storing message history centrally on the user's server is a longtime requested feature of Psi and XMPP in general. Also, Psi's user interface for message history is quite dated and should be given a facelift. This was also attempted in a previous GSoC project, although none of the code was merged into Psi.
Line 128: Line 128:  
== MCabber ==
 
== MCabber ==
   −
MCabber is a small console-based Jabber client, which includes features such as SASL support, history logging, commands completion, dynamic modules and external actions triggers. See our [http://wiki.mcabber.com/ Wiki] and [http://mcabber.com Homepage].
+
MCabber is a small console-based XMPP client, which includes features such as SASL support, history logging, commands completion, dynamic modules and external actions triggers. See our [http://wiki.mcabber.com/ Wiki] and [http://mcabber.com Homepage].
   −
=== Jingle File Transfer [http://xmpp.org/extensions/xep-0234.html XEP-0234] ===
+
=== Jingle File Transfer [https://xmpp.org/extensions/xep-0234.html XEP-0234] ===
    
MCabber has no file transfer support. There is an experimental file transfer module (which may not be up-to-date), but we would really be interested in adding Jingle File Transfer.
 
MCabber has no file transfer support. There is an experimental file transfer module (which may not be up-to-date), but we would really be interested in adding Jingle File Transfer.
Line 152: Line 152:  
=== Web interface ===
 
=== Web interface ===
   −
''Difficulty: Easy'' A dynamic web interface for managing the server. This would ideally use [http://xmpp.org/tech/bosh.shtml BOSH], [http://code.stanziq.com/strophe Strophe.js] and [http://xmpp.org/extensions/xep-0133.html XEP-0133] to make it a server-independent project. The primary language would be Javascript, with a possibility of some Lua.
+
''Difficulty: Easy'' A dynamic web interface for managing the server. This would ideally use [https://xmpp.org/tech/bosh.shtml BOSH], [http://code.stanziq.com/strophe Strophe.js] and [https://xmpp.org/extensions/xep-0133.html XEP-0133] to make it a server-independent project. The primary language would be Javascript, with a possibility of some Lua.
    
=== Pubsub support ===
 
=== Pubsub support ===
   −
''Difficulty: Medium'' A mod_pubsub for Prosody, implementing [http://xmpp.org/extensions/xep-0060.html XEP-0060]. In the spirit of Prosody it should be simple, modular and extensible.
+
''Difficulty: Medium'' A mod_pubsub for Prosody, implementing [https://xmpp.org/extensions/xep-0060.html XEP-0060]. In the spirit of Prosody it should be simple, modular and extensible.
    
=== Spam/abuse prevention ===
 
=== Spam/abuse prevention ===
Line 164: Line 164:  
Links:
 
Links:
   −
* [http://xmpp.org/extensions/xep-0158.html CAPTCHA Forms]
+
* [https://xmpp.org/extensions/xep-0158.html CAPTCHA Forms]
* [http://xmpp.org/extensions/xep-0275.html Entity Reputation]
+
* [https://xmpp.org/extensions/xep-0275.html Entity Reputation]
* [http://xmpp.org/extensions/xep-0268.html Incident reporting]
+
* [https://xmpp.org/extensions/xep-0268.html Incident reporting]
    
=== The ultimate server migration tool ===
 
=== The ultimate server migration tool ===
   −
''Difficulty: Medium'' The Prosody team have developed many tools for converting the different server storage formats around. Unify them and produce a tool capable of reading the data from one server and exporting another supported format (e.g. [http://xmpp.org/extensions/xep-227.html XEP-0227]), making server migration painless, no matter where you are moving from or to.
+
''Difficulty: Medium'' The Prosody team have developed many tools for converting the different server storage formats around. Unify them and produce a tool capable of reading the data from one server and exporting another supported format (e.g. [https://xmpp.org/extensions/xep-227.html XEP-0227]), making server migration painless, no matter where you are moving from or to.
    
== jabberd2 ==
 
== jabberd2 ==
Line 178: Line 178:  
=== Ideas ===
 
=== Ideas ===
   −
* [http://xmpp.org/extensions/xep-0060.html XEP-0060]: Publish-Subscribe
+
* [https://xmpp.org/extensions/xep-0060.html XEP-0060]: Publish-Subscribe
* [http://xmpp.org/extensions/xep-0163.html XEP-0163]: Personal Eventing Protocol
+
* [https://xmpp.org/extensions/xep-0163.html XEP-0163]: Personal Eventing Protocol
* [http://xmpp.org/extensions/xep-0136.html XEP-0136]: Message Archiving
+
* [https://xmpp.org/extensions/xep-0136.html XEP-0136]: Message Archiving
    
== Openfire ==
 
== Openfire ==
Line 200: Line 200:  
''Difficulty:'' Medium
 
''Difficulty:'' Medium
   −
Currently the server supports a single Jabber/XMPP domain. Each user of the service must specify the domain in their IM client connection configuration. To host an additional domain, one may consider installing a second instance of Openfire, but this creates networking communication conflicts because each instance is set to reuse the same ports by virtue of established client/server conventions. Instead a proposal began circulating to modify so that it can internally host multiple XMPP domains. This was described as, "virtual hosts", where the server acts as multiple domains, with a separate set of users on each domain. [http://www.igniterealtime.org/issues/browse/OF-162 [3]]
+
Currently the server supports a single XMPP domain. Each user of the service must specify the domain in their IM client connection configuration. To host an additional domain, one may consider installing a second instance of Openfire, but this creates networking communication conflicts because each instance is set to reuse the same ports by virtue of established client/server conventions. Instead a proposal began circulating to modify so that it can internally host multiple XMPP domains. This was described as, "virtual hosts", where the server acts as multiple domains, with a separate set of users on each domain. [http://www.igniterealtime.org/issues/browse/OF-162 [3]]
    
=== Portable Import/Export for XMPP servers ===
 
=== Portable Import/Export for XMPP servers ===
Line 208: Line 208:  
''Difficulty:'' Medium - Easy
 
''Difficulty:'' Medium - Easy
   −
Different implementations of XMPP-IM servers store user data in various ways, and many implementations have more than one storage format. This leads to problems when a server administrator wants to switch to another implementation or storage format -- the implementation is as likely as not to have an import mechanism that can read the user data in its current form. Modify to support a common file format for import and export of user data in XMPP-IM servers via Openfire plugin. [http://xmpp.org/extensions/xep-0227.html [5]]
+
Different implementations of XMPP-IM servers store user data in various ways, and many implementations have more than one storage format. This leads to problems when a server administrator wants to switch to another implementation or storage format -- the implementation is as likely as not to have an import mechanism that can read the user data in its current form. Modify to support a common file format for import and export of user data in XMPP-IM servers via Openfire plugin. [https://xmpp.org/extensions/xep-0227.html [5]]
    
=== Reducing the database footprint of Rosters ===
 
=== Reducing the database footprint of Rosters ===
Line 216: Line 216:  
''Difficulty:'' Medium
 
''Difficulty:'' Medium
   −
User Rosters (e.g. buddy contact lists) are stored in the database and requires a large per-user footprint and does not scale well. Modify to reduce the database footprint of rosters by possibly replacing the relation persistence model with a new model based on No-SQL-techniques (e.g. examples of nosql are "Document stores and CouchDB", "Graph databases and Neo4J", "Key/Value stores and Redis", "Column-oriented databases and Cassandra" See Article [http://www.h-online.com/open/features/The-H-speed-guide-to-NoSQL-981275.html [6]] ). [http://xmpp.org/extensions/xep-0227.html [7]]
+
User Rosters (e.g. buddy contact lists) are stored in the database and requires a large per-user footprint and does not scale well. Modify to reduce the database footprint of rosters by possibly replacing the relation persistence model with a new model based on No-SQL-techniques (e.g. examples of nosql are "Document stores and CouchDB", "Graph databases and Neo4J", "Key/Value stores and Redis", "Column-oriented databases and Cassandra" See Article [http://www.h-online.com/open/features/The-H-speed-guide-to-NoSQL-981275.html [6]] ). [https://xmpp.org/extensions/xep-0227.html [7]]
    
=== Constructive performance enhancements ===
 
=== Constructive performance enhancements ===
190

edits

Navigation menu