jdev - 2025-12-29

does anyone have thoughts on a decent way to optionally prevent a client from joining bookmarked mucs ? other than editing each client to support this as an option which is maybe the best way

a server module to set auto-join false for specific resources or dropping join presences or something...

sounds desperate

to avoid the XY problem this is likely a rather niche use-case that I and maybe not many others have, which is I'm in hundreds of mucs *and* rely on XMPP as my only form of communication, and sometimes find myself on terrible networks where I can't login and send or receive important messages due to the muc joining floods 💀 I know I know stop punching yourself

moparisthebest: it seems bad that the popular mobile clients (a) don't make it easy to find the auto-join flag and (b) love to do the comprehensive MUC-MAM-pull every connect

yes but to be fair that's good default behavior and probably fine for like 99.99% of people

if I were redesigning the Conversations-family clients that do this, I'd have them respect the Android data saver feature as a signal to not autojoin MUCs this time

then you could toggle data saver on as a way to indicate the network sucks, but you at least need to be able to text individuals

that would actually be perfect imho, but would Android devs want this, singpolyma ? :) (I see no inputmice here)

I probably should just make a dedicated muc-only jid and use only it for public MUCs but the thought of migrating nicks and permissions makes me want to die

> to avoid the XY problem this is likely a rather niche use-case that I and maybe not many others have, which is I'm in hundreds of mucs *and* rely on XMPP as my only form of communication, and sometimes find myself on terrible networks where I can't login and send or receive important messages due to the muc joining floods 💀 I know I know stop punching yourself Sounds like the actual problem is the client failing to connect which should get fixed to work no mrtter how many MUCs you are in ↺

> if I were redesigning the Conversations-family clients that do this, I'd have them respect the Android data saver feature as a signal to not autojoin MUCs this time Why would you ever want to not join? It doesn't use much data and may well be the whole reason you are opening the app ↺

In borogove for example I make sure you are fully connected and 1:1 mam sync is done before I even start joining any MUC. Which I think would help here?

> if I were redesigning the Conversations-family clients that do this, I'd have them respect the Android data saver feature as a signal to not autojoin MUCs this time this is actually a really smart idea im going to mentally bookmark this ✏ ↺

potentially also battery saver modes

could be applicable on all platforms, i believe most modern os's have some way of communicating this for networks and power plans ✏

Joining a muc shouldn't use much data or battery though. If it does maybe that's the bigger concern

And also opening phone on metered connection to check the family group chat and having it not work would be super confusing

probably only applied to public MUCs though

>> to avoid the XY problem this is likely a rather niche use-case that I and maybe not many others have, which is I'm in hundreds of mucs *and* rely on XMPP as my only form of communication, and sometimes find myself on terrible networks where I can't login and send or receive important messages due to the muc joining floods 💀 I know I know stop punching yourself > Sounds like the actual problem is the client failing to connect which should get fixed to work no mrtter how many MUCs you are in like a kind of spotty connection where it connects and then is disconnected a few seconds later ↺

but something like that should be covered by stream management

and should not trigger any joining

Indeed

maybe, but regardless there's still the basic problem of trying to shove X data over a connection that can only handle X*0.10 data when some specific bit is more important than the rest

yeah, a data saver mode where MUCs are not joined would be a solution for this or?

Yep

but this is also client side, you asked for a solution not on the client

Which bit is getting missed in your experience?

I mean I've experienced this multiple times, but my focus is on getting the important message through and not trying to figure out what's going on

So your issue is with sending and the message seems to not send?

answering or making a call usually

If it's disconnecting constantly wouldn't the call drop anyway?

temporarily maybe, but it's not head-of-like blocked by 9999999 muc presences and mam responses