Presence problem in large MUC rooms.
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
Le vendredi 30 janvier 2026, 10:52:31 heure normale d’Europe centrale Stephen Paul Weber a écrit :
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.
So you want to have the option to not only not get presence live, but also not get live messages?
??? Why we would not have the live messages? If the client is in the room, it's an "active" join, and it's working as usual.
Somebody signing messages as Goffi wrote:
Le vendredi 30 janvier 2026, 10:52:31 heure normale d’Europe centrale Stephen Paul Weber a écrit :
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.
So you want to have the option to not only not get presence live, but also not get live messages?
??? Why we would not have the live messages? If the client is in the room, it's an "active" join, and it's working as usual.
Yes but your whole proposal is about adding this "passive" join which I understood to not want live messages, correct?
Le vendredi 30 janvier 2026, 11:10:36 heure normale d’Europe centrale Stephen Paul Weber a écrit :
Somebody signing messages as Goffi wrote:
Le vendredi 30 janvier 2026, 10:52:31 heure normale d’Europe centrale Stephen Paul Weber a écrit :
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.
So you want to have the option to not only not get presence live, but also not get live messages?
??? Why we would not have the live messages? If the client is in the room, it's an "active" join, and it's working as usual.
Yes but your whole proposal is about adding this "passive" join which I understood to not want live messages, correct?
Yes, for rooms where the client is not actively displaying the chat, and you get notifications when you are mentioned (or we can add another option to get notification for every message, we still skip <presence> in this case). In short the room automatically get from "active" to "passive" when the client is not actively showing it and vice versa.
Hi, I think some people worked on a new MUC spec. Maybe we can ask them to put the proposal online. Regards On Fri, Jan 30, 2026, at 11:29, Goffi wrote:
Le vendredi 30 janvier 2026, 11:10:36 heure normale d’Europe centrale Stephen Paul Weber a écrit :
Somebody signing messages as Goffi wrote:
Le vendredi 30 janvier 2026, 10:52:31 heure normale d’Europe centrale Stephen Paul Weber a écrit :
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.
So you want to have the option to not only not get presence live, but also not get live messages?
??? Why we would not have the live messages? If the client is in the room, it's an "active" join, and it's working as usual.
Yes but your whole proposal is about adding this "passive" join which I understood to not want live messages, correct?
Yes, for rooms where the client is not actively displaying the chat, and you get notifications when you are mentioned (or we can add another option to get notification for every message, we still skip <presence> in this case).
In short the room automatically get from "active" to "passive" when the client is not actively showing it and vice versa. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Attachments: * signature.asc
Le vendredi 30 janvier 2026, 12:02:01 heure normale d’Europe centrale Philipp Hörist a écrit :
Hi,
I think some people worked on a new MUC spec. Maybe we can ask them to put the proposal online.
Regards
It seems that that's one of the ideas behind GC3 indeed. But I'm not sure about the progress on that, would be nice to have an update from MattJ or whoever is working on it.
On Fri, 30 Jan 2026 11:29:10 +0100 "Goffi" <goffi@goffi.org> wrote:
Le vendredi 30 janvier 2026, 11:10:36 heure normale d’Europe centrale Stephen Paul Weber a écrit :
Somebody signing messages as Goffi wrote:
Le vendredi 30 janvier 2026, 10:52:31 heure normale d’Europe centrale Stephen Paul Weber a écrit :
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.
So you want to have the option to not only not get presence live, but also not get live messages?
??? Why we would not have the live messages? If the client is in the room, it's an "active" join, and it's working as usual.
Yes but your whole proposal is about adding this "passive" join which I understood to not want live messages, correct?
Yes, for rooms where the client is not actively displaying the chat, and you get notifications when you are mentioned (or we can add another option to get notification for every message, we still skip <presence> in this case).
In short the room automatically get from "active" to "passive" when the client is not actively showing it and vice versa.
so, if i'm understanding proper, it would be a bit like Client State Indication where we are dumped the messages when we are actually looking at the MUC, right?
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
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.
But thats set by the admin, not by the client. So its not the client that gets presences spam under control, its the admin that decides if clients are spammed or not. That alone is worth to have a new spec. Then there are other obstacles which would need to be solved - XEPs that depend on presence (Hats, comes to mind) - Discovering the real-jid (Altough unlikely that big MUCs are non-anonymous, the protocol should not make it impossible) If presence would be optional, we also would not need to find a solution to get messages, if the client is not joined, because a join is just 2 stanzas, one to join, one back that join was successful, so very cheap. The other big topic is a refactor around roles and affiliations. I don't think its worth to further add hacks on top of XEP-0045. Desperately trying to salvage a protocol that was design with presences in mind. its relatively easy to create a new MUC protocol which is perfectly backwards compatible. - Send join for new muc standard - Add indication if client wants to receive presence or not (Presence is optional) - If joined with new muc standard, real-jid needs to be attached to each message, if chat is non-anonymous - Revise the Hats XEP to not depend on presence - Add new efficient IQs to get affiliations There are no breaking changes here, a MUC can be operated with both protocols at the same time. And this solves all problems that i know of. Except maybe the refactor around affiliation or roles, but i would say we can live with that if it means MUCs stay backwards compatible. Regards
Hi, Just to make that clear: I'm all-in on creating the new GC3 protocol, but that ideally would tackle many more issues than just the presence spam (and many of which have already been discussed elsewhere), so the "easy" protocol you had in mind doesn't really do it. The main reason why I proposed making use of the existing things, is that those are already available and we will be able to get implementation experience quicker. This implementation experience can be very valuable for the GC3 protocol. On Mon, 2026-02-02 at 08:48 +0100, Philipp Hörist wrote:
But thats set by the admin, not by the client. So its not the client that gets presences spam under control, its the admin that decides if clients are spammed or not.
Which is fine in many cases: Large rooms (especially if bridged from legacy networks that don't have a room-presence logic) produce the same amount of presence spam for everyone. There is always a limit of the amount of presence spam that is bearable to the client. I doubt that this is something that the enduser will want to decide on (no matter if as a participant or room owner), so it would just be arbitrary limits selected by client developers. The question thus is just if those arbitrary limits are selected by client developers or server/gateway developers. Doing it on the server using existing mechanisms instead of involving the client also has the advantage that it immediately is to the benefit of every client, as it doesn't require any client changes.
Then there are other obstacles which would need to be solved - XEPs that depend on presence (Hats, comes to mind)
Sure, this might be interesting problems to solve. But they also need to be solved for GC3 independently. Again, getting the implementation experience on top of MUC and trying different ways how those issues can be solved based on the existing infrastructure is likely easier than starting a GC3 from scratch and having to think about everything from the beginning. Marvin
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.
This is fine, but then you never get the presence. My read here wrs something more like CSI "only show me presence and most live messages when I'm looking rt the room in UI. Else queue them"
Hi, It was not mentioned in this thread, so I need to ask: wouldn't 0436 and 0463 (presence and affiliation versioning) solve most of presence spam on (re)joining a MUC? I plan (someday) to implement it in slidge, is there still interest from client developers about it? Maybe, just an idea, if we have a certain type of "space" where we expect everybody to be in all rooms, the XEPs could be extended to be "trans-MUC", not specific to a single MUC? -- Nicolas
participants (6)
-
Goffi -
Marvin W. -
Nicolas Cedilnik -
Philipp Hörist -
Stephen Paul Weber -
Yuri Lucia