Skip to main content

Project Introduction: XSF, XMPP and Prosody IM

Prosody: Plugin Installer

What is this all about?

This project aims at developing a tool to manage plugins in the XMPP server Prosody. It should have the power to install, remove, update and list them. A repository will be set up, and scripts should be provided to build and manage it.

XMP-What?

XMPP stands for eXtensible Messaging and Presence Protocol, which is a XML (eXtensible Markup Language) based communications protocol for message-oriented middleware.
Communication protocols are important, because they clearly state how entities should communicate. Without them, everybody would communicate in any manner they'd come up with, which would be a mess to understand. Even inside an organization, different parties could start with the same blueprint on how to pass information around and overtime make their own undocumented changes, as enhancements or as a way to become more exclusive for example, leading to incompatibility between systems. One such case is IBM's Bi-Sync Protocol (BSP) which has more than 50 variations of the original iteration. Finding a way to standardize communication is therefore desirable and needed.

Just a tiny bit of history

The origins of XMPP date from 1999, when Jeremie Miller developed his Jabber software. Jeremie wanted to build an open technology for instant messaging and presence, so besides building the software he also needed to state the rules on how it should communicate around so that people could build their own tools. The Jabber Software Foundation (JSF) was then formed and made the first protocol iterations, which were eventually formalized by the IETF (Internet Engineering Task Force), which is the entity in charge of overseeing Internet communication protocols.
Now this was all named after Jeremie's software, which was the starting point, but Jabber was just an implementation of the open protocol he intended to make. So in order to better clarify the mission of the foundation, the JSF was renamed XSF - XMPP Standards Foundation, which is the one in charge today of developing open extensions for the protocol. We can still find some references to the past in today's software. One such example is some ID's which are called "JID"s - Jabber Identification Number. Many times, XMPP services are just referenced as Jabber services.

So, who does what?                                      

There are two groups of protocols when we are talking about XMPP. One of them is in charge by the IETF, who declare the specifications relevant to this case in a Request For Comments format. RFC were originally designed by Steve Crocker to help unofficially document the development of the ARPANET and ask for feedback, but nowadays is a format the technology community usually employs when developing technology. The IETF adopts some of these documents as Internet Standards, and XMPP is one of such cases. Currently, there are 3 RFC related to XMPP, which are the RFC 6120, RFC 6121 and RFC 6122. On top of these there is a WebSocket binding defined in RFC 7395.
Now these only specify the main protocols. Thanks to its use of XML, it is possible to extend the protocol as we please to accomodate any new functionality desired. These are the protocols that the XSF takes charge. They are called XEP's - XMPP Extension Protocol, and there are currently around 350 specifications!

Why is XMPP relevant?

There are a lot of different solutions around that provide chat options, along with other functionalities, but one would be dependent on third parties. The main reasons to use XMPP are privacy, security and customization. We can build our own tool, run it on our own hardware and have total control of what is happening, while been given the power to add any feature we like. Having said that, and considering there are other possibilities regarding protocols, here are the selling points regarding XMPP:
  • Open - The way entities are communicating isn't a black box. The specifications are freely available to anyone who wants to make use of them
  • Standard - There are reliable entities - the IETF and the XSF - in charge of the specifications, which guarantees stability
  • Battle tested - Jabber was announced in 1998. That was the same year Google was founded, that is how old it is! Wide use since then as made the protocol into a war veteran among protocols! There are lots of clients, servers and libraries built to attest this
  • Decentralized - There isn't a main server when we are working with XMPP. Anybody can use his own server and communicate with others
  • Secure - Networks can be either public or private. Core XMPP specifications uses the SASL framework and TLS protocol to provide security
  • Extensible - Any new feature can be added, thanks to the power of XML namespaces.
  • Flexible - Besides Instant Messaging, we can deal with a lot more stuff, like file sharing, remote systems monitoring and gaming
  • Diverse - XMPP is being used by a lot of different companies and projects, since it allows the communication between implementations, independently of which technology was used. One of the best examples is obviously Prosody IM! 😁

Speaking of Prosody

Once again, XMPP is just a specification, a blueprint regarding how to communicate. It isn't software per se. This means we can implement it using any tool we like. There are clients, servers and libraries in many different programming languages. Turns out that Prosody IM is just one of said implemations, freely available, using the Lua programming language to build an easy to use server that can run on BSD/linux/MacOS. It is efficient, simple, modular, well documented, supported by an active community and Barney-approved.


Being modular, we can choose specifically which plugins (the terms Plugins and Modules are used interchangeably) we want to use, there is no need to load everything. Prosody comes with a specific group of plugins by default, but there are many more community modules available, which might be in different stages of development. To install a module we simply need to download the files and modify a configuration file accordingly. Similar manual labor is required when performing other operations with the software. 
We will develop a tool to make all of this more user-friendly, by doing all these small operations behind the scenes, while only asking the user what he wants to do, regarding Prosody modules.

Comments