6 May
2026
6 May
'26
7:50 p.m.
On Wed, 6 May 2026 at 17:23, Dave Cridland <dave(a)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