Smack
Support for XMPP over WebSocket
WebSockets (RFC 6455) are an alternative way to establish a connection between a server and a client. This project idea is about adding support for XMPP over WebSocket (RFC 7395) to Smack. The student needs to implementing a new XMPPWebSocketConnection which extends the existing XMPPConnection interface. The resulting API must be compatible to the existing Smack code and must also be usable on Android devices.
Keywords: Java, XMPP, Smack, WebSocket
Support for XEP-0390: Entity Capabilities 2.0
XEP-0390: Entity Capabilities 2.0 is an overhaul of XEP-0115: Entity Capabilities, which provides an efficient way for remote entities to signal their capabilities. This mechanism reduces network traffic and speeds up most other protocols.
In order to add support for XEP-0390, the existing ServcieDiscoveryManger code must be extended to support for plugable remote entity feature discovery mechanisms.
This issue is tracked as SMACK-792.
Keywords: Java
OMEMO Test Framework
There are some pitfalls to the OMEMO protocol, which can cause message loss. Since there are no explicit error messages, it might be desirable to have a test framework to ensure correct functionality of client implementations. The goal of this project idea is to create a test framework for Smack’s OMEMO API. This could include an echo bot which can be used to test OMEMO functionality of a client, but should ultimately be integrated in Smack’s integration test framework.
This task is expected to be of medium difficulty and requires knowledge of the OMEMO protocol specification and desirably (but not necessarily) knowledge of Smack’s OMEMO implementation.
Keywords: Java, Encryption, OMEMO, Smack, Integration-Tests
Add support for XEP-0301: In-Band Real Time Text
XEP-0301: In-Band Real Time Text makes XMPP based instant messaging more accessible by allowing for real time text, that is, text being submitted to the recipient while the sender is typing it. More information about real time text can be found at http://www.realtimetext.org/
This issue is tracked as SMACK-694.
Keywords: Accessibiltiy
Openfire
DNSSEC support
Being a XMPP (Jabber) protocol complient server implementation, Openfire, a cross-platform real-time collaboration server, allows your instant messaging domain to talk to other domains using server federation, or (s2s, server-to-server). This allows your users to interact with users on the remote domain. That principle is a cornerstone of the distributed characteristic of XMPP.
DNSSEC is a set of extensions to DNS, and is used to prevent the forgery of DNS records. A DNSSEC-capable resolver can verify that the looked-up records are valid and complete. In XMPP, the way how remote network entities are located is through DNS.
This project would result in a S2S implementation that validates DNSSEC-protected records of the remote domain when establishing XMPP server federation.
We believe this to be an easy assignment, as most of the functionality that’s to be implemented can be isolated from the existing functionality.
Keywords: Security, XMPP, DNS, DNSSEC, Java
Replacement webclient for FastPath
Openfire, a cross-platform real-time collaboration server based on the XMPP (Jabber) protocol, can be extended with support-desk oriented functionality, referred to as FastPath. This functionality allows an organization to integrate instant messaging functionality in their public website, allowing customers to chat directly with service/support employees. FastPath provides, amongst others, a web client that can be integrated in a website. Customers can then use that web client to talk to representatives of the site. From a protocols perspective, FastPath is an implementation of the XEP-0142 extension of the XMPP protocol.
The public web client used for FastPath is very dated. It specifically suffers from a very dated look-and-feel, as well as using technologies that make it impractical to integrate into an existing website (to todays standards). Replacing that client with a brand new implementation would make for a challenging GSoC project. The goal for this project would be to produce a webbased chat application that, using the protocols as defined in XEP-0142, allows users to contact support staff, is easily to integrate with existing websites, and is, UI and UX-wise, on par with current industry standards.
We’re expecting that this is a moderately difficult project: on the one hand, most technological complexity is documented, and working examples are available, but on the other hand, a lot of concepts are being touched.
Keywords: XMPP, FastPath, web development, instant messaging, integration
Improve HTTP File Upload implementation
A common feature in instant messaging clients is to transfer files between end-users. This typically occurs either explicitly (when a user selects a file using a file-picker), or implicitly (for instance, when taking a picture with the camera of a phone, after which the picture is shared).
The XMPP standards define various ways of transferring ‘data’ between users. A popular approach to share content is defined as XEP-0363: HTTP File Upload. Using this approach, a server-sided component is used where clients upload, using HTTP, data to be shared. The intended recipients are then send a link to that data, where they can download the data, again, using HTTP.
Openfire, a cross-platform real-time collaboration server based on the XMPP (Jabber) protocol, can act as such a repository in which files are shared. It’s implementation however is very bare-boned (it accepts files, stores them in a temporary folder, that eventually gets purged).
As a Google Summer of Code project, one could mature the existing implementation of the HTTP File Upload server-sided component in Openfire. Although as a student, we’d certainly welcome your own input on this, we believe that lots of value can be added by extending the administrative functoinality of the implementation. For instance, a file management feature and a supporting administatrative web page UI can be added. These should allow files to expire, garbage collected or pinned for persistence. Quota management (which users can send what data, in what amounts) is another interesting feature, as is integration with dedicated storage facilities (think Amazon S3 and friends).
We’re expecting that this would be a rather easy project, as the essence of the functionality is available. You can, however, make things as interesting as you like, by suggesting additional features or integrations.
Keywords: Java, XMPP, HTTP File Upload, instant messaging, Openfire
Spark
Message Carbons support
Spark is an Open Source, cross-platform, XMPP-based IM client optimized for businesses and organizations. It is developed in Java and is primarily based on the Smack library.
The XEP-0280 extension of the XMPP protocol allows clients to forward send and received messages to other connected resources (think: different clients that are used by the same user). The underlying Smack library (which is the base of Spark) already supports this, as well as many XMPP servers. Support should be added to Spark, so that it is automatically forwarding sent/received messages to other connected resources of the same JID to insert them into history, when a server supports XEP-0280.
We’re expecting that this would be a moderately easy project. Most of the bits that implement the required functionality are available, while all of it is clearly documented. Challenges might be found in finding the correct combination of parts, as well as proper UI interaction with the end user.
Keywords: XMPP, Instant Messaging, Java
Message Archive Management support
Spark is an Open Source, cross-platform, XMPP-based IM client optimized for businesses and organizations. It is developed in Java and is primarily based on the Smack library. The MAM extension (XEP-0313) of the XMPP protocol allows clients to store and retrieve history from the server (if it supports it).
The underlying Smack library (on which Spark is based) already supports this, as well some XMPP servers. Spark should be able to store/retrieve history from the server, instead of storing it locally when a server supports XEP-0313.
We’re expecting that this would be a moderately difficult project. Most of the bits that implement the required functionality are available, while all of it is clearly documented. It proves, however, difficult to keep a a complete record of chat history available at multiple sites.
Keywords: XMPP, Instant Messaging, Java
Rewrite Spark’s GUI to JavaFX
Spark is mature, but older XMPP Instant Messenger written in Java. At the time of its creation, Java Swing was good choice for a GUI library. However, in recent years, better alternatives have become available. For almost 10 years JavaFX has been emerging as the new graphic library for Java. Rewriting Spark’s GUI to FX could refresh current look of this Instant Messenger and use of the FXML files would help in the future development of Spark.
This project presumably can be really hard as it requires good knowledge of both worlds: Swing and JavaFX. What’s more: the codebase in which changes are to be applied is very large, as Spark was created by many people through many years. On the other hand: the project doesn’t require creating or adding new functionality in Spark. Most of the desired functionality is already there, it just need to be rewritten to the new technology. The main benefit of this project would be to gain a better separation between the presentation layer and application logic within the software. Abandoning legacy technology in favor of the new one could also attract new developers to Spark, something we’d welcome.
Keywords: Java, Spark, Swing, JavaFX
OMEMO plugin for Spark
Smack library for XMPP is recently supporting OMEMO encryption protocol. OMEMO is quite new protocol created during Google Summer of Code 2015. It is rapidly increasing on popularity and finds it’s way to new clients. Spark should have plugin which would allow users to send encrypted messages. Usage of Smack-omemo is quite easy, but fitting it into existing Instant Messenger can be challenging task.
Keywords: Java, Encryption, XMPP, OMEMO
Smack/Openfire combination
Support for XMPP over Openfire Virtual Connection
Implement a new XMPPOpenfireConnection which extends the existing XMPPConnection interface to provide a Smack connection object that can be used in Openfire plugins for server-side code that require multiple client connections. Example use cases are bots, focus users, etc.
Keywords: XMPP, Smack, Openfire, Bot