Wojtekhi, I have a question about forwarding IQ in semi-anonymous rooms. As per
"If an occupant wants to send an IQ stanza to another user in a semi-anonymous room, the sender can direct the stanza to the recipient's occupant JID and the service SHOULD forward the stanza to the recipient's real JID. However, the MUC service MUST NOT reveal the sender's real JID to the recipient at any time, nor reveal the recipient's real JID to the sender."
such IQ should be forwarded to FullJID or BareJID? (DMs for example stipulate FullJID)
jonas’and it’s written down nowhere what the right thing is
WojtekI know ]:->
jonas’Wojtek, for example, you’d want to route PEP and vCard requests (if you let them pass through) to the bare JID, but disco#info and ping should go to the full JID.
jonas’of course, the fun really starts when there’s more than one full JID behind the same nickname
Wojtekyup, and I was driving at that because we forward everything to FullJID, which obviously breaks vCard...
Wojtekand a followup question - should server handle vcard requests send only to BareJID or also to FullJID? 0045/00153 mentions "send to BareJID" but there is no MUST nor mention that sending to FullJID is invalid
MattJWojtek, we forward everything to the full JID unless it looks like a protocol we understand to require the bare JID
MattJIt should only handle vCard requests to the bare JID
jonas’Wojtek, I’m pretty sure that a server handling IQ requests to the full JID would violate RFC 6120
MattJSending to the full JID is not invalid, but per the RFC that stanza must be routed to the client
pep.and forwarding jids also has implications re privacy
pep.and forwarding IQs also has implications re privacy
MattJejabberd also got this the wrong way around in some ancient versions
pep.As a server dev I'm not sure I'd want to forward any IQs tbh, in semi-anon rooms
MattJIt's up to clients if they choose to respond
jonas’also you need to somehow keep routing info in the stanza so that you know where to route the response to. do server’s do that (in the @id?), or is that based on luck?
pep.is it really up to me the client if you query pep?
Wojtek@MattJ "unless it looks like a protocol we understand to require the bare JID" that does feel kinda inflexible
pep.someday I'll write that script to deanonymize contacts :p
jonas’if you want the correct flexible solution, invest in MIX ;)
pep.does mix fix this in any way?
jonas’pep., it’s supposed to by making resources addressable, removing the ambiguity
ZashIt fixes it by not fixing it?
pep."realjids everywhere anyway"?
jonas’pep., oh, I wasn’t talking about the privacy thing
jonas’I was talking about the flexibility thing
MattJWojtek, I totally agree, but it has worked this way for 20 years, and here we are :)
jonas’pep., build that script and donate it to sjn so that we finally get accurate user counts ;)
MattJThe amount of flexibility that has been required is quite low
pep.jonas’: haha, and you deal with privacy laws? :p
ZashDidn't ejabberd "solve" that by handling vcard requests sent to full JIDs?
MattJZash, yes, in the olden days
jonas’pep., something about infomration manifestly made public and me not storing it, just counting
ZashAnd Prosody currently redirects vcard, vcard4 and PEP requests to the bare JID
Wojtek@jonas’ MIX - it's basically ready, with MIX-MUC ;-)