XMPP Service Operators - 2026-01-15

hmm, but the documentation explicitly says you should not load it on the pubsub component

global or under a vhost

If you don't have a vhost as a parent host of the pubsub component, you need some extra config under the vhost and pubsub component, so it is allowed to publish there and that it does find the pubsub service.

> Guus, I was looking at my server logs and I see you aggressively close connections at xmppnetwork.goodbytes.im, one minute after it’s been established, yet the default delay between publishes is three minutes so we reestablish the connection then. I don't recall explicitly closing connections. There is a server default, but i think that kicks in after half an hour of being idle or so. I'll have a look.

Link Mauve: you were absolutely right. I had configured that server to close idle s2s connections after 1 minute. I can only imagine that was done in some effort to debug something, forgetting to restore that setting. I've now changed it back to half an hour.

Kris: part of that documentation is written by me - a non-admin of Prosody. There's a chance that I've introduced incorrect details. If so, please let me know and I'll try to improve them.

Thanks!

No, thank you :)

> mandatory upgrade is standard for STARTLS these days, however there is a minor amount of metadata leak with STARTLS, so technically directls is better... No there is not ↺

The only data exchanged clear is the sni which is sent from TLS too

I've had customers that were very much appalled by the idea that not every bit of data that was exchanged was done over an encrypted connection, when encryption was configured to be mandatory anyway. Instead of having lengthy debates, being able to just have them use direct TLS is a convenient flexibility to have.

Kris, what do you want to monitor s2s connection for?

It sounds like you have a component that you want to monitor, so the module needs to be loaded on that component

If you want to monitor s2s connections for your pubsub component, then in that case you *would* load the module onto the pubsub component :)

But I assume that note in the docs was written because people loaded it only on the pubsub component, and expected it to see traffic across the whole server

MattJ - I'd love for you to improve the documentation of that module to get rid of my assumptions and misunderstanding of how Prosody works.

> Kris, what do you want to monitor s2s connection for? I just thought it would be nice if our server would be visible on that jabber network graph Guus made. ↺

Sorry, I meant 'what [host] do you...'

As in, whatever host(s) you want to report to Guus, they are where the module needs to be loaded

Connections to our muc component I guess.

Then load the module on the MUC component and it should work as you expect

Yeah, I can try that.

hmm adding it to the modules of the muc component also seems to make no difference.

I think I give up on trying this, probably just not compatible with an uncommon setup like ours

there are servers on there that have muc.example.com

im not sure why yours wouldnt work

are there any logs?

I don't see what's unusual about your setup

But feel free to share the config if you want further assistance

based.pt, ours serves only a muc component directly, no user accounts

oh, so its just an muc?

like a "space" yes.

how do you use it?

Kris, is there not VirtualHost at all? Prosody would normally shout about that

gota make accounts on other servers ✏

it is a service to host mucs for people from other servers to use, yes

> Kris, is there not VirtualHost at all? Prosody would normally shout about that i think it might no have any functionality, just the muc part

MattJ, well, technically there is one now on a subdomain to run the Riddim bot, but it worked fine before without one (yes there is some log spam)

Prosody requires at least one VirtualHost entry in the config (even if it's just "localhost")

maybe we had that

Seems like you have one now though, so your setup is the same as everyone else's

except that the muc component is not on a subdomain of a vhost like on 99% of other setups, and afaik that does cause some issues with modules and discovery

I don't think the network graph does discovery, assuming it's the MUC domain that was added

yeah that is what I am trying

there are muc domains on that, so i dont think thats a problem

For example, muc.xmpp.org is listed

send your config ✏

yes, but what is the "admin" of the pubsub component then?

do you have a pubsub?

yes we have

The MUC domain is creating the node and publishing items, so that's what you would put as the admin

oh ye the admin is the domain not an user

that is what I am trying, but apparently it doesn't work

Also, if you have the latest version of the module (from yesterday I think), you can run: prosodyctl shell module info pubsub_serverinfo

and it will show some info in the 'status' line

ok, that is worth a try

ah, it only loads on the vhost not the muc component

according to the output of that

are you restarting or only reloading? If you reload you have to explicitly load it on the vhost iirc

is there a reason why you would not restart?

Disruptive?

it's easier but worse for the active users joined to your MUCs, most of whom are using clients that unfortunately don't handle muc restarts well or at all

Kris, so: prosodyctl shell module load pubsub_serverinfo [your muc domain]

> it's easier but worse for the active users joined to your MUCs, most of whom are using clients that unfortunately don't handle muc restarts well or at all dont the most popular clients handle that?

yes I am trying to avoid restarts as we have a lot of remote users connected to our mucs

you could try and schedule a restsrt when theres fewer users

based.pt, and Prosody makes restarts effectively seamless for MUCs. But still, it's relatively disruptive for various reasons.

ik

> Kris, so: prosodyctl shell module load pubsub_serverinfo [your muc domain] hmm, that might have worked ↺

I mean, it's not the end of the world to restart a MUC service, but when there is no need to... why?

ok, it does look like something is happening now

I guess I need to note these things down for future use to avoid restarting

i dont know, i personally never use reloads because i thought they could bring issues

but if its the same thing theres clearly no reason to restart

If you're happy restarting, do it by all means. It's a good way to ensure that the server is "reset" and running from what's in config file

For example, if Kris's config doesn't load the module, it will not be loaded next time the server restarts

>> it's easier but worse for the active users joined to your MUCs, most of whom are using clients that unfortunately don't handle muc restarts well or at all > dont the most popular clients handle that? I'm not sure any do actually, conversations doesn't ↺

I guess we will probably add a check for that at some point (e.g. "this module is loaded, but isn't in your config")

conversations will sometimes helpfully say "you aren't connected to this muc anymore" only if you click into it after noticing no messages for hours/days

yeah I see issues like that all the time on remote server restarts

>> dont the most popular clients handle that? > > I'm not sure any do actually, conversations doesn't profanity does

This looks like success Kris: https://xmppnetwork.goodbytes.im/?focus=joinjabber.org

yeah. I think you could edit the readme that it is permissible to load the module on a muc component

if you add it globaly it only loads on vhosts ✏

If you can provide an exact wording that makes sense to Prosody devs, I'd be happy to add it.

"Enable this module in the global or a virtual host." is what threw me off.

I'll put something in

> This looks like success Kris: https://xmppnetwork.goodbytes.im/?focus=joinjabber.org for some reason i think ive seen that in there a long time ago, im not sure

it is possible that we had this working on a previous iteration of our server

ok