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 _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
