[Standards] 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.