Sign in Subscribe
chinwag

Conferences, Rooms, MUCs ... What?

Mike

• 4 min read
Conferences, Rooms, MUCs ... What?

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

I was originally going to write a post on setting up Jappix before covering MUC configuration, but changed my mind. It’ll be good to have a working chat room to join when we test Jappix, and there are some other components and services we need to revisit DNS for around then, so let’s avoid doing that part twice and just get our conferences up.

If you noticed in that last paragraph I used three different terms to refer to exactly the same thing, congratulations. It was deliberate because I’m going to use part of this post to go over one of my first user experience issues with many XMPP services – a lack of consistent terminology. One thing I want to be sure of while setting up and polishing ChinWag is to use terms unambiguously, so I need to pick my name for multi-user conferences right now.

I’m going with room. It’s short, it’s easy, and it’s a very good metaphor for the concept. Being invited into a room makes sense. Conversing with a group of people in a room makes sense. It’s not annoying to type. Our conference server will be rooms.chinwag.im.

The actual setup in prosody.cfg.lua is quite simple, and I’ll add in some extra stuff along the way. One thing I’m explicitly not covering right now is conference and chat logging, I’ll get to that in the spit-and-polish phase later in development. I’m kind of at a stage where I’m wanting to rush ahead and deploy anything and everything at once right now. I’m making myself take this slowly, and documenting as I go. It’s not the way I usually work! Here are the additions.

Right at the end of the config file, after our VirtualHost section, I’m adding a new Component line.

Component "rooms.chinwag.im" "muc"
    name = "ChinWag Chat Rooms"

Now, something I’m not doing here is adding “muc” to our modules_enabled section. The Component directive seems to imply the module loading. This seems reasonable, but I’m not 100% sure if there’s any kind of best-practice rule that says I should be doing an explicit module load as well. If anyone’s got anything concrete to add on this topic, I’d like to hear it.

One module I am going to add right now though, is “default_bookmarks“. I’m going to put a room bookmark in place for all new users to our default room – lobby@rooms.chinwag.im. Users will be free to delete this after, but I’d like to at least introduce them to the concept of the rooms existing from the start.

modules_enabled = {
    -- Other modules
    "default_bookmarks";
}

default_bookmarks = {
        { jid = "lobby@rooms.chinwag.im", name = "Lobby" };
}

Now we need to add a DNS record. If we only care about our own server’s users joining the rooms, we’re actually done at this point, as the server will always be aware of its own components. If we want, say, joe@otherjabber.org to be able to join in though, we need a pointer in the DNS to tell them where to find rooms.chinwag.im.

Just like the server itself, the first way a client should attempt to find the server information is via an _xmpp-server SRV record. See the previous post about SRV records again if you want a refresher.

If that doesn’t exist, it will fall back to looking for an A record for the host, just like it does for the server itself. We’re going to do things “the proper way” and using SRV records for a bunch of extra components, which I’m about to add. You’ll want a zone file that looks like this. If you’re using a GUI of some sort from a hosting provider, it’ll look different, of course.

_xmpp-server._tcp.rooms SRV 1 1 5269 xmpp.chinwag.im.
_xmpp-server._tcp.proxy SRV 1 1 5269 xmpp.chinwag.im.
_xmpp-server._tcp.pubsub SRV 1 1 5269 xmpp.chinwag.im.
_xmpp-server._tcp.search SRV 1 1 5269 xmpp.chinwag.im.

OK, so what are those other things in there? Let’s enable them in the config file and see where we get to. I’m keeping all the Component definitions together down the bottom, but do whatever makes you happiest.

Component "rooms.chinwag.im" "muc"
    name = "ChinWag Chat Rooms"

Component "proxy.chinwag.im" "proxy65"
        proxy65_acl = { "chinwag.im" }
        proxy65_address = "xmpp.chinwag.im"

Component "pubsub.chinwag.im" "pubsub"

Component "search.chinwag.im" "vjud"

The “muc” component is our chat rooms, as previously discussed. “proxy65” is a helper for file transfers for clients behind firewalls. The “pubsub” module allows clients to subscribe to data “nodes” similarly to an RSS feed – I don’t want to go too deep into this right now, but Jappix uses it so we’ll add it in now. The “vjud” component supports a searchable user directory – it’s configured on an opt-in basis by default, it may not see much use, but I’ll make sure at the least my “admin” user is searchable for potential support purposes.

OK, we now have a pretty solidly functional XMPP server, that offers a good base range of services. We’re pretty well up and running now, and all we need now is a usable web front end and we’re in business … sort of. The rough edges are going to really start showing soon and it’ll be time to start actively looking for solutions.

Feel free to come visit the lobby at some point!

Sign up for more like this.

Enter your email
Subscribe