6 May
2026
6 May
'26
11:22 a.m.
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.
6 May
6 May
1:14 p.m.
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.
1: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
4:19 p.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
33
days inactive
33
days old
3 comments
4 participants
participants (4)
-
Dave Cridland -
Marvin W. -
Matthew Wild -
Stephen Paul Weber