Re: MUC Occupancy and forwarding

On Wed, 6 May 2026 at 17:23, Dave Cridland <[email protected]> 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
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]