Hi, I'm not sure how widely known this is, but XEP-0045 describes a configuration option `muc#roomconfig_presencebroadcast` which allows to decide which roles' presences should be broadcasted. This makes it trivial to get the "presence spam" under control. I remember this was mentioned in the context of gateways. Some legacy networks don't have the same notion of a room presence that XMPP has. Often, presence is globally and not specific to the room. If there is no room-specific presence in the legacy network, there is also no reason to map their global presence (or worse, their membership) to a group presence; instead group affiliation should be used. If you suggest we need improved handling of affiliation lists to reduce the amount of data sent to handle updating those, this was what XEP- 0463 was meant to do. When the question comes up which messages to receive, joining the room means to receive all live messages, not joining means to not receive live messages. There are experimental modules for some servers to send messages to participants when they are mentioned but not currently joined (mostly intended for the purpose of push notifications). Maybe standardizing a mechanism to register for mention notification could be helpful. Marvin On Fri, 2026-01-30 at 10:49 +0100, Goffi wrote:
Hi,
Following what I've said yesterday at the summit, I would like to explain more my idea, and get your feedback.
So basically the problem with presence in large MUC is that we get 2 things: - initial presence when we join the room - all the presence update when people join and leave, which is quite often with people on mobiles.
So my point was that we are seeing MUC by the way it's used today. But we don't have to.
We don't have to be actively in the room. What we want when we are in a large room, is to be able to check it when we want, and be notified when we are mentioned.
For smaller rooms, we may want to be notified on each new message.
The way I see it, we could have 2 ways to join a MUC: active and passive.
The active join would be what we do today, we get all the presence, and updates, it's really bandwidth intensive.
The passive join, on the other hand, would only say "we are in the room". The MUC service would then notify the client only in case of mention (or for any message in case of "subscribed" room).
Benefit: - we don't have presence spam anymore, the client does an active join only when the user want to actually be in the room. So it's only one room at the time. - client doesn't have to actively parse message to look for mention, on mobile it will get a push notification and wake up only when necessary - It should be easy to implement on top on existing MUC implementation - It's backward compatible: non-compatible client will just to "active" join all the time, and get all the presence spam.
Probably we can also optimize the initial presence in case of active join, but that's another topic.
I think that solves the presence issue. Let me know what you think about it.
Best, Goffi