jdev - 2020-05-01

  1. Wojtek

    hi, I have a question about forwarding IQ in semi-anonymous rooms. As per https://xmpp.org/extensions/xep-0045.html#bizrules-iq "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)

  2. jonas’


  3. jonas’

    it depends™

  4. jonas’

    and it’s written down nowhere what the right thing is

  5. Wojtek

    I know ]:->

  6. 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.

  7. jonas’

    of course, the fun really starts when there’s more than one full JID behind the same nickname

  8. Wojtek

    yup, and I was driving at that because we forward everything to FullJID, which obviously breaks vCard...

  9. Wojtek

    and 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

  10. MattJ

    Wojtek, we forward everything to the full JID unless it looks like a protocol we understand to require the bare JID

  11. MattJ

    It should only handle vCard requests to the bare JID

  12. jonas’

    Wojtek, I’m pretty sure that a server handling IQ requests to the full JID would violate RFC 6120

  13. MattJ

    Sending to the full JID is not invalid, but per the RFC that stanza must be routed to the client

  14. pep.

    and forwarding jids also has implications re privacy

  15. pep.

    and forwarding IQs also has implications re privacy

  16. MattJ

    ejabberd also got this the wrong way around in some ancient versions

  17. pep.

    As a server dev I'm not sure I'd want to forward any IQs tbh, in semi-anon rooms

  18. MattJ

    It's up to clients if they choose to respond

  19. MattJ

    (and how)

  20. 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?

  21. MattJ


  22. pep.

    is it really up to me the client if you query pep?

  23. Wojtek

    @MattJ "unless it looks like a protocol we understand to require the bare JID" that does feel kinda inflexible

  24. pep.

    someday I'll write that script to deanonymize contacts :p

  25. jonas’

    if you want the correct flexible solution, invest in MIX ;)

  26. pep.

    does mix fix this in any way?

  27. jonas’

    pep., it’s supposed to by making resources addressable, removing the ambiguity

  28. Zash

    It fixes it by not fixing it?

  29. pep.

    "realjids everywhere anyway"?

  30. Zash

  31. jonas’

    pep., oh, I wasn’t talking about the privacy thing

  32. pep.

    jonas’: ah

  33. jonas’

    I was talking about the flexibility thing

  34. MattJ

    Wojtek, I totally agree, but it has worked this way for 20 years, and here we are :)

  35. jonas’

    pep., build that script and donate it to sjn so that we finally get accurate user counts ;)

  36. MattJ

    The amount of flexibility that has been required is quite low

  37. pep.

    jonas’: haha, and you deal with privacy laws? :p

  38. Zash

    Didn't ejabberd "solve" that by handling vcard requests sent to full JIDs?

  39. MattJ

    Zash, yes, in the olden days

  40. jonas’

    pep., something about infomration manifestly made public and me not storing it, just counting

  41. Zash

    And Prosody currently redirects vcard, vcard4 and PEP requests to the bare JID

  42. Wojtek

    @jonas’ MIX - it's basically ready, with MIX-MUC ;-)