The XMPP Standards foundation had its 21st Summit this past month in Brussels, Belgium just prior to a strong showing at FOSDEM in the same city. With a good showing of members, the meeting’s discussion was certainly lively and members made a clear statement that the XSF, and XMPP as a whole is poised to make some changes. Some real change is needed if XMPP is to grow and continue to be relevant in the IT world.
Perhaps the most immediate thing that stuck me was that I was able to sit in a summit with a far wider range of talent to see than before. The flexibility of XMPP was really on display, but I had a hard time keeping track of all the various use cases for the protocol that each team had used. While this variety is important for any protocol, there is little in the way of documented use cases available. Yes, nearly every publication will suggest using XMPP as a chat protocol, but little else. While XMPP fits this function just fine, it can do so much more. A shop foreman wanting to secure manufacturing control using in-house developed software could be forgiven if the idea of using XMPP does not come across his desk. The vast open world of possibility still needs some signposts to help along the way, and a robust centralized use case guide is essential. Our explore section contains use cases that we have used XMPP servers for, and it is our hope that other developers do the same. Another challenge for XMPP is presence; currently the protocol is represented by any software that cares to use it. Although this stance can provide a variety of projects that run XMPP, it can also lead to some problems. Namely for the neophyte not knowing what software will be compatible with which XEPs. It’s far too easy for somebody to test out old unsupported software and get the impression that the protocol is not for them. Worse still, it’s not at all unimaginable that somebody could feel that on a cursory inspection there is not an active development community; deciding the protocol dead or unsupported. The recent website renovation at xmpp.org is a fantastic start to change an otherwise aging face, but more is needed. We, owe ourselves to be able to say what software falls within our compliance standards. This may be accomplished in a number of ways. A voluntarily entry by developers can put an onus on developers to not only improve their products, but showcase the XEPs it supports. Or support lists may be done internally, by XSF staff testing, although this may be too resource intensive. Ideally, it would be best to develop a test for function availability or compliance. For servers this might be as easy as running a modified disco#info for some XEP functionalities. However it is done, this can provide an objective bar to what XMPP should look like in its most current state. Though some use cases do not demand the latest features, so a software list should not be exclusive to just compliant releases.
Lastly, one of the great opportunities for XMPP is the Internet of Things. A protocol can define a standard for a generation, and it is not too far wrong to think that XMPP can serve as a secure and unifying backbone to the IoT field. Most IoT devices currently rely on proprietary communication methods, typically on a one to one format with devices. The scale of thing such as smart home interoperability are limited by manufacturer, and sometimes platform version. Not to mention that many consumer IoT devices currently use little more than a plaintext password. IoT currently lacks an industry standard, and I believe that XMPP should make a push to be the protocol for that standard. This is a potential within reach of the XSFs best efforts! As of late, I am encouraged by the potential appointment of an IEEE liaison on the subject to communicate how XMPP can become that standard. Tigase, for our part, has developed a few IoT framework using a Raspberry Pi 3 as a bridge to demonstrate how XMPP may be used. In fact these methods were displayed at the Free Open Source Developers Meeting held just after the Summit. We are excited to spread word of this work, and hopefully encourage others to do the same. The more ground work put in, the easier it will be to move forward.
There are certainly some challenges that lay ahead for the protocol, and the members as a whole. Surely more than I’ve laid out here in this small blog. However, from this last summit, it was very much made clear that the members are interested in moving forward with some of these ideas. We at Tigase, have already begun to push the protocol forward toward its potential. With the help of the XSF and other developers we are capable of that goal.
If you would like to learn more about our efforts, or aid in our tasks, feel free to browse our projects, or contact us with ideas or questions.