More Prosody Modules

This article is part of an ongoing series of posts, there’s an index here.

Welcome back! Let’s get good old Chinwag operational! I had a very busy April, but life’s settling down again now so it’s time to get rolling with this again.

OK, so if you look back at the Extra Modules and Dependencies post, the base functionality of an XMPP server is there, but the goal with ChinWag is to be a highly user-oriented system, and we want to add things to make life as easy as possible. I’m going to add most (but not all) of the final functionality to the server here, and start allowing public registration. After this, I’ll move on to getting the web site up and we’ll start identifying problems we have and some potential solutions.

Here are the additions to the “modules_enabled” section of our prosody.cfg.lua file in this pass.

        -- Additional
        "admin_web";
        "register";
        "register_web";
        "watchregistrations";
        "blocklist";
        "announce";
        "private";
        "bosh";
        "websocket";
        "carbons";
        "smacks";

Most of them don’t need a whole lot of explanation, so I’ll just do a quick mention of the simpler ones, and then get into some of the more esoteric modules.

The “admin_web” module unsurprisingly provides a web-based interface to server administration. The “register” and “register_web” allow users to self-register accounts, which is fairly handy for public servers, and not so much if you’re running a private or company server with some other authentication source – and “watchregistrations” will give a notification via XMPP to our admin accounts when someone does register.

Users can block other users from contacting them with “blocklist“, “announce” will allow admins to send notices to all logged-in users (in case of maintenance, downtime or issues), and “private” allows XMPP clients to store data server-side (such as bookmarks).

The modules “bosh” and “websocket” have a broadly similar purpose, and that’s to make XMPP a little more accessible via web-based clients. BOSH is the older method, websockets are a bit newer and definitely the way forward. We’ll be primarily using websockets on the site we’ll build, but BOSH support can be pretty handy for many clients whose only internet access is via restrictive HTTP proxy servers. We’ll get into this stuff in detail while setting up a web server in the next post.

Enabling “carbons” and “smacks” brings our functionality more in line with modern expectations of instant messaging. Back at the dawn of the 21st Century (stay with me kids) the broad trend was to have a single computer – we were not constantly connected and surrounded by a multitude of networked devices. When XMPP was first developed, the normal use case would be sitting down, logging in to a computer, possibly one that was not even connected to the internet, and then setting your IM status to “available”, possibly automatically when you finished dialling your ISP.

The “carbons” module attempts to keep all clients in sync, as far as message history and state go, so you can pick up your phone and resume a conversation you started on your PC at work. Client software support is required and it’s not 100% reliable as yet, but it’ll get there in time. This is behaviour much more appropriate to modern use than the original XMPP model.

Where “smacks” comes into play is mainly with mobile devices, particularly phones, that tend to be constantly gaining and losing network connectivity as they move around, and frequently changing IP address as they enter and leave different service areas and WiFi networks. This module allows reconnection to an existing “session” after a brief period of unavailability (five minutes by default) without reporting back any delivery failures to the sender systems.

Now let’s just go ahead and throw things open to the world. I’m changing this setting in the Prosody configuration.

allow_registration = true 

Let’s try it out! I’ve restarted Prosody, checked the log to see if it all looks sane.

# prosodyctl check
Checking config...
Done.

Checking DNS for host chinwag.im...

Checking certificates...
Checking certificate for chinwag.im
  Certificate: /etc/prosody/certs/chinwag.im.crt

All checks passed, congratulations!

We’ll get the IM Observatory to test us from the outside.

Looks good – I’ll use Pidgin to create a new account. Note the checkbox at the bottom. This uses In-Band Registration (IBR), which is not an ideal solution, and I’ll devote a post to the user creation process and replace this setup later. For now it’s enough to verify that user creation is possible, and the registration watch plugin is working and sends notifications when accounts are added.

Doing this in Pidgin is a great example of a terrible user experience, by the way. Even though every necessary piece of information is supplied in this form, you’re given another form that asks for it again, with an ambiguous field that just requires the username, without the domain. One thing we need to do when building systems like this is be consistent. All “username” and similar prompts throughout ChinWag should require the JID, username@chinwag.org, or clearly specify that the domain is not required if that’s not possible.

That’s definitely a post for the future though, when we get into the spit and polish sections. In the meantime, chinwag.im is open for registration and is intended to stay that way. Feel free to use it!