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]
