XSF Discussion - 2018-08-22


  1. pep.

    RFC6120, 7.6.1 > Once the server has generated an XMPP resourcepart for the client, it MUST return an IQ stanza of type "result" to the client, which MUST include a <jid/> child element that specifies the full JID for the connected resource as determined by the server. From what I understand, we generally assume that the resource can be forcibly assigned by the server. Does this sentence also mean any other part of the JID can be rewritten? (localpart, domain)

  2. moparisthebest

    New messenger, LAN only, https://github.com/dakhnod/Meshenger

  3. Maranda

    pep.: I *don't think so*. Host at least has to honour the stream to attribute.

  4. jonasw

    pep., yes, it can

  5. jonasw

    pep., before binding, there’s not really a JID anyway

  6. jonasw

    there’s just the SASL identity, and that doesn’t have to match the JID

  7. jonasw

    everything else (like stream @to) is just informational

  8. jonasw

    pep., there was a prosody module which would integrate with some forum software, and it would create a JID which didn’t match the SASL identity (based on the forum username) if the SASL identity contained stuff which wasn’t allowde in the JID

  9. Maranda

    I'd like to actually see a server that dishes out a different host in the jid than the one you opened a stream to c2s wise

  10. Maranda thinks he *won't*

  11. jonasw

    the host will probably stay what the client expects it to be, indeed

  12. jonasw

    not that it really matters

  13. jonasw

    (I also confused stream @to and @from)

  14. jonasw

    (@to isn’t quite that informational given that it’s used for TLS already)

  15. Maranda

    Aaaand I need cooooffeeee ☕

  16. Zash

    Maranda: The hosted GTalk thing would assign you a different host IIRC

  17. Maranda

    Zash: Huhu, I recall it opening s2s streams with no to or from and expecting those to be set from dialback. But that one sounds more hilarious

  18. Zash

    On c2s tho

  19. Maranda

    Yeah but me think clients would tell it where they're opening a stream to in that case 😆

  20. Link Mauve

    Could that mechanism be used for JID aliases?

  21. Link Mauve

    As a neat upgrade mechanism when for instance a provider upgrades from example.com to example.org?

  22. Maranda

    Wasn't there some 301 xmpp version proposal as opposed to that?

  23. jonasw

    Link Mauve, the main issue with changing domains isn’t the local, but the remote side

  24. Maranda

    Or rather make that "a xmpp version of status code 301"

  25. Maranda coughs lingua matrix failure 😞

  26. Link Mauve

    jonasw, sure, but when you did migrate your domain (I remember pep. having to do that), it makes it transparent for your users.

  27. jonasw

    Link Mauve, how is it going to be transparent when all the remote roster entries are borked?

  28. pep.

    Yeah, at least you don't have to have a flag day

  29. Link Mauve

    In a company, where you are already using shared groups and mostly communicating locally, it does make sense.

  30. jonasw

    right

  31. jonasw

    Link Mauve, rewriting the bare JID could be a helper, but I think there’s a stream error for it

  32. pep.

    You will indeed still need that flag day when actually switching the actual account

  33. Maranda thinks something like "Resource Moved Permanently" is far more trasparent and less clunky

  34. Maranda

    Than tellin' someone his jid magically changed when he/she binds a resource...

  35. pep.

    What I meant above would have been the opposite really. "you can use your new _credentials_, but for now it'll still bind to the same old jid"

  36. Maranda

    I'm pretty sure at least 95% of the clients out there would start coughing blood if there's a change to either the node or the host portion of a jid they don't expect anyways

  37. ralphm

    When I was working on XMPP (PubSub) based federation for social networking sites, we had full movability of objects. Something would move to a different site and we'd send a node deletion notification with <redirect/> element pointing to the new place.

  38. pep.

    It's not like it was explicitely forbidden, nor really specified by the RFC either. Send an errata?

  39. ralphm

    You can do something similar with the "gone" stanza error. It also has a way to specify the new location by putting a URI in the element.

  40. ralphm

    If somebody retrieves his roster, the server will send out presence probes. If the remote server responds with "gone" it could rewrite the roster item.

  41. pep.

    also <moved/>

  42. ralphm

    There's no <moved/> stanza error

  43. daniel

    Conversations will happily change the jid and use that for subsequent logins. Which in turn can be a problem some times. For example OpenFire will let you specify a jid like username@ip and on bind it gets changed to username@domain but domain won't resolve properly

  44. pep.

    -xep moved

  45. pep.

    bunneh!!

  46. Maranda

    ralphm: that's for far better than what mentioned by others ☺️

  47. pep.

    https://xmpp.org/extensions/xep-0283.html

  48. Maranda

    That's for sure*

  49. pep.

    But I don't like the bits in the security considerations, that defeats the point of the XEP

  50. Maranda

    Damn auto correction

  51. daniel

    Or they are other weird and broken servers that use something like email@domain to login and then change the jid on bind to username@domain. And then subsequent logins don't work

  52. pep.

    And I don't think it's much of an issue

  53. ralphm

    Maranda: thanks, there's a reason this stuff is there to begin with :-D

  54. ralphm

    pep.: ah yeah, I forgot about that one. I don't think (now) that this XEP is needed. What does it do better than "gone"?

  55. Maranda thinks he tried to desperately mention "301", "Moved Permanently" keywords for a few minutes to no avail also 😆🤸‍♂️

  56. Maranda

    🤷‍♂️

  57. pep.

    ralphm, with <gone/> you need to keep track of what's gone where. With moved it's a client thing, the account can be tombstoned or deleted

  58. pep.

    Only works for roster though

  59. ralphm

    yeah