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.