6 May
2026
6 May
'26
10: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