MUC Occupancy and forwarding
Hi all, I'm trying to summarise a discussion in the council@ chatroom, and - like an LLM - I am not perfect so may misrepresent or misunderstand some views. Errors, therefore, I shall claim as my own; views however are not. First, some history. In the early days of XEP-0045, each occupant corresponded to precisely one full jid (ie, a client session). All stanzas sent to the occupant jid were, therefore, forwarded through directly to that full jid. This general model of "pure forwarding" has been maintained throughout XEP-0045's history, but it has been modified heavily. Quite early on - Kev thought 2001, MattJ thought 2003 - the need to have vCards in particular be different started changing rules, and when Prosody started doing MUC (and also M-Link) they started intercepting vCard to the MUC occupant jid and forwarding that to the user's bare jid. Prosody now does this with PEP as well. In addition, "nick sharing" - allowing multiple full jids of the same user behind a single occupant jid - makes forwarding most IQ stanzas complicated. All this causes existing problems with preserving privacy in semi-anonymous rooms. What we do in the future (under MUC2/GC3/IRC4 whatever) broadly falls into 3 options that were discussed. Option 1: The occupant jid forwards nothing, but has a way of requesting a contact jid. Option 2: The occupant jid forwards everything to the user's bare jid, and their server "deals" with it. Option 3: The occupant jid responds itself, without forwarding, and data (vCards, PEP, etc) need to be uploaded by the user and stored by the MUC. Option 4: The occupant jid has rules set by the user, which cause it to either forward or reject particular traffic. I imagine some of these rules will cause PEP subscriptions and event forwarding/fanout, potentially. There were proponents of each of these approaches (and some proponents of multiple). There's a further discussion in xsf@ that I've not yet properly read. My opinions follow: Of these options, I think I'd like Option 4, but will settle for Option 2. Option 2 feels like the natural fallback for Option 4 anyway. One outcome is that in Future-MUC, there's an implication that Private Messages, PEP, and vCard will go to the *bare* Jid, and that unless we do something "clever", so will Jingle calls to Occupants. We would then control these with existing (or new) access control on our own server, or Option 4's new rules, or some combination of both. I appreciate the simplicity of Option 1, but I think it's too simple - even for Private Messages I'd need to reveal my identity. If I'm in a sensitive room (say a healthcare related one) I might really want (or need) PMs but not be willing to reveal my identity. Option 3 seems very heavyweight and expensive to maintain and manage. I don't particularly want to upload an avatar (and more) to each MUC room, and nor do I see how those will work with (for example) Jingle. As noted, I may have misconstrued the options presented! Dave.
Option 1: The occupant jid forwards nothing, but has a way of requesting a contact jid.
Option 2: The occupant jid forwards everything to the user's bare jid, and their server "deals" with it.
Option 2 seems pretty ok to me. As you said forwarding of iq to fulljid has never had a way of actually working anyway -- it goes to a "random" fulljid of the ones joined. So unless we are going to have sub-addressing (and I think there are good reasons we don't want to if we want to keep semi-anon) I think going to the barejid as the default is all we really can do. However I don't think we need to write this in a way that makes it impossible for a compliant implementation to make another choice. For example a MUC might intercept BoB requests, know which fulljid sent that originall, and forward there. Or other such advanced case-by-case things. But I think barejid is the right default.
I appreciate the simplicity of Option 1, but I think it's too simple - even for Private Messages I'd need to reveal my identity. If I'm in a sensitive room (say a healthcare related one) I might really want (or need) PMs but not be willing to reveal my identity.
I've long felt that full bidirectional PMs in a semi-anon MUC are more trouble than they're worth, but we do need some way to get eg a chat request through which I think would likely use message stanzas.
On Wed, 6 May 2026 at 17:23, Dave Cridland <dave@cridland.net> wrote:
Hi all,
I'm trying to summarise a discussion in the council@ chatroom, and - like an LLM - I am not perfect so may misrepresent or misunderstand some views. Errors, therefore, I shall claim as my own; views however are not.
Appreciated. From my perspective, I think you captured everything.
In addition, "nick sharing" - allowing multiple full jids of the same user behind a single occupant jid - makes forwarding most IQ stanzas complicated.
Not only IQ, messages are also a pain. Does the server fan out, or do we rely on carbons? Today's answer is that currently the MUC server fans out to all (joined) resources when you receive a PM, and your own server fans out (via Carbons) when you send a PM. This leaves a lovely asymmetric mess in your MAM archive.
What we do in the future (under MUC2/GC3/IRC4 whatever) broadly falls into 3 options that were discussed.
Option 1: The occupant jid forwards nothing, but has a way of requesting a contact jid.
Option 2: The occupant jid forwards everything to the user's bare jid, and their server "deals" with it.
This gets my vote (note that it can be combined with option 1, I would like a way to bootstrap from PM to a "real" conversation).
Option 3: The occupant jid responds itself, without forwarding, and data (vCards, PEP, etc) need to be uploaded by the user and stored by the MUC.
As mentioned, I disagree with this approach quite a bit, pretty much for the reasons you mentioned.
Option 4: The occupant jid has rules set by the user, which cause it to either forward or reject particular traffic. I imagine some of these rules will cause PEP subscriptions and event forwarding/fanout, potentially.
I'm not strongly opposed to this, I think it would be easy enough to implement. But I don't know if it's overall the right approach vs building better access control on the user account side.
One outcome is that in Future-MUC, there's an implication that Private Messages, PEP, and vCard will go to the *bare* Jid, and that unless we do something "clever", so will Jingle calls to Occupants. We would then control these with existing (or new) access control on our own server, or Option 4's new rules, or some combination of both.
FWIW most clients are using JMI (XEP-0353) to bare JID for years now. Obviously the subsequent session is between two clients, but client-to-client is just as broken in MUC1 when multiple sessions are joined, so we need to solve this anyway. That's the attraction of option 1 - the MUC is only used for bootstrap. Regards, Matthew
Hi, Regarding option 1, I'd like to point out that XEP-0383 is a thing, thus providing a bare jid does not necessarily require providing the identity. And as Matt already pointed at, a protocol for Option 1 can even be useful when combined with one of the other options. In fact, the protocol for option 1 can even be extended to current MUC and would be beneficial there. Experience within the scope of current MUC can be helpful to decide which of the options make the most sense for a MUC2. Regarding the problem in general, I think it might be interesting to explore which iq-based functionality is desirable to work with semi- anonymous MUCs. Then for each of those, it can be evaluated what the best solution for them is. The ones that were mentioned here: vCard, avatar, private message, jingle vCard: Most of the fields in a vCard are identifying information which kind of defeats the purpose of (semi-)anonymity provided in MUCs. Some popular XMPP clients don't make use of vCards other than for the purpose of avatars. I wonder if people sincerely want to use vCard while maintaining semi-anonymity. Avatar: I fully understand that usecase and see need for good solutions for it. I'd like to point out that it may be desirable to be able to show avatars of users no longer participating in a room (but that previously have send messages to it) and also potentially to moderate avatars, given they are effectively part of the room payload. Jingle: This is a protocol that inherently is between devices, not users. It's use also typically reveals sensitive personal information (voice, video, ip address for connectivity) making it naturally not well fit for use in (semi-)anonymous scope. Private message: While generally a desirable functionality, I don't think it is necessarily desirable to have the messages technically routed through a MUC if not necessary. If you have other usecases in mind, please also mention them here, so we can get a better understanding of what is desirable. Marvin On Wed, 2026-05-06 at 17:22 +0100, Dave Cridland wrote:
Hi all,
I'm trying to summarise a discussion in the council@ chatroom, and - like an LLM - I am not perfect so may misrepresent or misunderstand some views. Errors, therefore, I shall claim as my own; views however are not.
First, some history.
In the early days of XEP-0045, each occupant corresponded to precisely one full jid (ie, a client session). All stanzas sent to the occupant jid were, therefore, forwarded through directly to that full jid. This general model of "pure forwarding" has been maintained throughout XEP-0045's history, but it has been modified heavily.
Quite early on - Kev thought 2001, MattJ thought 2003 - the need to have vCards in particular be different started changing rules, and when Prosody started doing MUC (and also M-Link) they started intercepting vCard to the MUC occupant jid and forwarding that to the user's bare jid. Prosody now does this with PEP as well.
In addition, "nick sharing" - allowing multiple full jids of the same user behind a single occupant jid - makes forwarding most IQ stanzas complicated.
All this causes existing problems with preserving privacy in semi- anonymous rooms.
What we do in the future (under MUC2/GC3/IRC4 whatever) broadly falls into 3 options that were discussed.
Option 1: The occupant jid forwards nothing, but has a way of requesting a contact jid.
Option 2: The occupant jid forwards everything to the user's bare jid, and their server "deals" with it.
Option 3: The occupant jid responds itself, without forwarding, and data (vCards, PEP, etc) need to be uploaded by the user and stored by the MUC.
Option 4: The occupant jid has rules set by the user, which cause it to either forward or reject particular traffic. I imagine some of these rules will cause PEP subscriptions and event forwarding/fanout, potentially.
There were proponents of each of these approaches (and some proponents of multiple).
There's a further discussion in xsf@ that I've not yet properly read.
My opinions follow:
Of these options, I think I'd like Option 4, but will settle for Option 2. Option 2 feels like the natural fallback for Option 4 anyway.
One outcome is that in Future-MUC, there's an implication that Private Messages, PEP, and vCard will go to the *bare* Jid, and that unless we do something "clever", so will Jingle calls to Occupants. We would then control these with existing (or new) access control on our own server, or Option 4's new rules, or some combination of both.
I appreciate the simplicity of Option 1, but I think it's too simple - even for Private Messages I'd need to reveal my identity. If I'm in a sensitive room (say a healthcare related one) I might really want (or need) PMs but not be willing to reveal my identity.
Option 3 seems very heavyweight and expensive to maintain and manage. I don't particularly want to upload an avatar (and more) to each MUC room, and nor do I see how those will work with (for example) Jingle.
As noted, I may have misconstrued the options presented!
Dave. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (4)
-
Dave Cridland -
Marvin W. -
Matthew Wild -
Stephen Paul Weber