jdev - 2024-12-09

> not telling them is the default crashing behavior that needs to be handled most, the divestos muc runs ejabberd and reboots daily and that's the only I notice clients never rejoin automatically lmao ↺

doge: *plonk* (only joking)

isn't ejabberd written in erlang which is supposed to be all highload and constant uptime etc how do you end up with it rebooting daily...

I've seen occasional "technical error" or similar popups with button to rejoin other mucs too.

> isn't ejabberd written in erlang which is supposed to be all highload and constant uptime etc > how do you end up with it rebooting daily... Server running bleeding edge fedora or similar, needs reboot for some updates. ↺

why on earth would you even... do that...

Paranoia, need to lead and bleed? IDK, ask the dev if you can.

> isn't ejabberd written in erlang which is supposed to be all highload and constant uptime etc > how do you end up with it rebooting daily... meanwhile prosody seemingly never goes down no matter what i do, and allows for you to dynamically reload the whole thing to update without going down ↺

(as far as i know)

Prosody can be even be restarted without anyone dropping out of MUCs

Doesn't work if it actually crashes tho ✏

But for that whole problem space, I've had a good experience after writing a plugin that checks if I'm still in MUCs when their s2s connection terminate, telling my client it dropped out if it doesn't get a positive response.

that would be nice to have, i do get a lot of weirdness in gajim when a friend will fully restart their vps. ive just always chalked it up to gajim being a mess

https://modules.prosody.im/mod_ping_muc.html fwiw

imagine if software could have only parts of it to restart

and not the entire thing?

> https://modules.prosody.im/mod_ping_muc.html fwiw ill look into that when i get a chance, thanks ↺

i mean.. imagine if software were written and designed like that

lol

Like the original jabberd, which was a collection of microservices? :)

i mean, you could replace or restart one component

without shutting down the whole thing

Or like the modular, hot-code-reloadable approach of Prosody?

the protocols and clients should be made in such a way as to make server restarts completely unnoticeable to the user

doge, please do.

it has been done. with proprietary social networks you have no idea of server restarts.

doge, look, this room is about XMPP development, not about proprietary social networks. You can talk all day long about how things could have been, but unless you work towards changing them it’s unlikely to change.

> the protocols and clients should be made in such a way as to make server restarts completely unnoticeable to the user One can use a cluster of servers instead of a single server for the XMPP backend so that individual servers can be taken down, and the service remains online. However, this increases the cost and complexity of running the service, so most server operators do not do this. Some of the XMPP servers have documentation on how to do this.

> it has been done. with proprietary social networks you have no idea of server restarts. doge: they use ejabberd and XMPP and clustering FYI ↺

The divestos mucs restart daily after kernel updates, the whole VPS restarts, nothing to do with ejabberd

> The divestos mucs restart daily after kernel updates, the whole VPS restarts, nothing to do with ejabberd Other than forcing ejabberd to also restart, and lacking graceful client reconnects... ↺

Hi. I was looking at XEP-0114 (Workgroup Queues); I'm seeing each server is reimplementing it. However, there's the XMPP Component Protocol; I have experience with Biboumi and it seems to be rock solid and plugging into almost all XMPP servers. Is there any reason why Workgroup Queues shouldn't be implemented in a Component? Did anybody already do that? I've searched the web, but wasn't able to find one.

XEP-0114 is now Workgroup Queues, it's the Component protocol.

XEP-0142 is Workgroup queues

Is that implemented by more servers than just Openfire?

If memory serves, the workgroup queues does use a distinct component. I think that's basically a MUC component, with some additional features.

I don't see why you couldn't make that an external component - but you may need to duplicate a lot of functionality from a MUC component.

I'm not sure if the XEP separates the 'queuing' from the 'chatting' in that XEP. It is possible that an implementation could use an external MUC service (but I kind of doubt it, to be honest).

Then again, if the queuing service would properly provision a chat room on demand... I think the handoff is based on invitations - that might actually work.

Guus, Openfire uses the "fastpath" plugin to implement it. No idea if that internally uses the component protocol. The ejabberd page says it also supports Workgroup Queues.

that's why I thought every server is supporting it separately, which - given the size of the development community - would be a bit of a waste of energy.

Hmm. I'll need to read up on the MUC part of it.

Having to duplicate MUCs doesn't sound like an attractive idea.

hmm. it seems to be really clever. if the workgroup service were able to create rooms, it seems the standard will re-use an existing MUC service.

From XEP-0142: > The end result of a workgroup interaction is to negotiate and route a user and workgroup member (a.k.a. agent) to an appropriate chat room for a chat conversation using the multi-user chat (MUC) protocol. However, multi-user chat essentially 'takes over' when the workgroup protocol successfully completes so there is no overlap between the two protocols. Seems that it's even intended to be totally disjoint. It seems that there's no reason for the workgroup to maintain the MUC when the MUC created by the workgroup service is a temporary one: the MUC service will clean it up automatically... Thanks for your thoughts! ✏