jdev - 2021-01-20

  1. Sam Whited

    I'm sure I've asked this before and don't remember if I ever got an answer, but BOSH defines a version string during negotiation, but as far as I can tell there is no actual version listed anywhere. The XEP version doesn't even match the same format (and of course involves lots of changes that wouldn't change a protocol version anyways), so I have no idea what value to put there?

  2. Sam Whited

    (not the xmpp:version from XEP-0206, but the ver attribute from XEP-0124, to be clear)

  3. Zash looks at Prosodys mod_bosh

  4. Zash

    It has '1.6' 🤷️

  5. Kev

    Urgh. If people are going to discuss BOSH can they at least put it in NSFW tags or something? :(

  6. Sam Whited

    hah, that would be a good April 1st XEP. NSFW feature (which could be a real feature) but also we list technologies such as BOSH that must be behind it.

  7. Zash

    There is that spoiler message XEP...

  8. Sam Whited

    Zash: 1.6 appears to be used in one of the examples and is a version of the BOSH XEP itself, so maybe that was the intent? I have no idea.

  9. Sam Whited

    Especially since the XEP version might be bumped just for typos and recent ones use major.minor.patch syntax which doesn't fit the bosh version syntax

  10. Sam Whited looks at who introduced the new version syntax and broke things… *blushes*

  11. Sam Whited

    *sigh* it would almost be easier to revive the websocket over HTTP/2 I-D than to continue implementing BOSH.

  12. Kev

    Swiften also sends 1.6, FWIW.

  13. Zash

    1.6 was probably the latest version when mod_bosh was written, it was committed ~2 months after 1.7 was published (according to the xep changelog)

  14. Kev

    But my view is that if you're implementing BOSH for anything less than a significant amount of money (or insert other motivator here), you're probably soft in the head.

  15. moparisthebest

    Sam Whited, revive what? doesn't https://tools.ietf.org/html/rfc8441 support it?

  16. Kev

    AFAICS, Swiften doesn't care at all about the ver, it just includes it at 1.6

  17. Kev

    I *suspect* that's true of every implementation, but have no evidence to support that.

  18. Zash

    Kev, Prosody doesn't seem to do the same

  19. Zash

    Kev, Prosody seems to do the same

  20. Sam Whited

    Kev: you're not wrong… this is the second or third time I've tried to do this (only once for money, and even then only a moderate amount of money)

  21. Sam Whited

    And every single time I think "this time's the one, this time it will work correctly" and I always end up abandoning it in frustration.

  22. Sam Whited

    I'll stick with 1.6 for compatibility then (why not). Thanks

  23. Kev

    I've implemented it once and a bit. I think another implementation is in my future, but I'm trying to avoid it.

  24. Sam Whited

    moparisthebest: thanks for the link, I thought this had never gotten beyond I-D for some reason. I'll have to re-read (assuming this is the same thing) and see. Maybe websockets actually does work on HTTP/2 now and I just have old info

  25. Sam Whited

    I guess I didn't abandon the commercial one in frustration, HipChat just ended up being sold and I left the company. No idea if they ever used it or not.

  26. moparisthebest

    Sam Whited: I was rather recently surprised by that RFC also :)

  27. moparisthebest

    The next question is will the same thing work over http/3

  28. Sam Whited

    Another stupid question which I just realized is a problem (potentially): what do people do in their libraries if someone tries to send an IQ without a namespace? Normally it would just be in the default namespace and therefore still a stanza, but if I implemented the websocket subprotocol as discussed earlier it wouldn't have a namespace and wouldn't be a stanza. Maybe I should detect anything called "iq", "message", or "presence" without a namespace set and just set it to the right thing (although technically I guess that's wrong and you could have a non-stanza thing called "iq", but that would be dumb so I'm not sure if I care)\

  29. Zash

    Dunno what libraries do, but Prosody tweaks the namespace on outgoing stanzas to have the proper jabber:client namespace if it's unset.

  30. flow

    ideally users are not able to construct IQ instances without a namespace

  31. Sam Whited

    Users can send whatever arbitrary XML they want, so that's not an option

  32. Zash

    I feel like there would be type system things you could do here

  33. Sam Whited

    But that's a good point, maybe if it's sent with the IQ struct I could find a way to make those always get the right namespace set at least

  34. Sam Whited

    Then if users deliberately encode XML tokens that include "<iq xmlns=''/>" that's fine, it's their problem, but if they use the safer library features they get the correct behavior

  35. flow

    ideally users are not able to construct IQ instances without a namespace (for the IQ child element)

  36. flow

    I just realized that we are talking only about jabber:client / jabber:server as namespace

  37. Zash

    That may be a nice place to enforce that iq stanzas have an @id attribute as well, and other constraints

  38. Sam Whited

    oh yah, sorry, wasn't thinking of the IQ child

  39. Sam Whited

    I have ID enforced at the stream level actually. It looks at all tokens passing through and if any of them are "iq", "message", or "presence" with namespace "jabber:client" or "jabber:server" it adds IDs (and "from" if it's an s2s connection)

  40. flow

    in Smack, stanzas implicitly have the right namespace (jabber:client in smack's case), and when the stanza is serialized, Smack will try to avoid printing the namespace declaration if it is redundant

  41. Sam Whited

    So right now if you sent "iq" with no namespace those rules wouldn't trigger either

  42. Sam Whited

    meh, maybe I'll just add the namespace to anything called "iq" with an empty namespace in the same place IDs are enforced. It's just easier and if it ever causes an actual problem I'll eat my hat

  43. Zash

    Similar in Prosody, missing xmlns attribute normally means it's the same as the parent, or the default stream namespace, but websocket being a bit special there means special care needs to be taken somewhere in the pipeline.

  44. Zash

    (Why couldn't we have a websockets-for-normal-clients that's just the same as the TCP binding but with WS framing?)

  45. Sam Whited

    I wonder that every time I read through this spec…

  46. Sam Whited

    I'm sure there was some sort of good reason for doing it this way, but I have no idea what it is.

  47. Zash

    It's because browsers don't have streaming XML parsers exposed to JavaScript

  48. Zash

    Thus every frame must be a vaid XML document.

  49. Sam Whited

    oh yah, that makes sense

  50. Sam Whited

    Actual other question: I was just thinking I'd do the client side because "why not?" (once I've done the receiving side it's pretty trivial to make the handshake work for a client connection too), but why would anything use websockets that's not actually the web?

  51. stpeter

    Heh, I still remember trying to convince Mike Shaver to add XMPP to Firefox at an OSCON in Portland around 2002/2003...

  52. Sam Whited

    I guess technically some server could only expose that

  53. Zash

    But WebSockets have sub-protocol negotiation, it wouldn't be super hard to add another for those with streaming parsers

  54. Sam Whited

    stpeter: as a javascript feature or as part of that chat product that was built in for a while? Either way, that would have been fun :)

  55. Zash

    You could have used it to get trough web stacks and firewalls, but now you could do that with ALPN instead.

  56. moparisthebest

    > why would anything use websockets that's not actually the web? another easy firewall bypass Sam Whited

  57. Sam Whited

    Oh yah, firewall bypass makes sense

  58. Zash

    There are desktop clients with BOSH support after all

  59. stpeter

    Sam Whited: the idea that DizzyD and I had was that they could use XMPP for real-time notifications and experiences within the browser

  60. moparisthebest

    you've got your network security people who refuse to expose anything to the internet that can't be "protected" by their enterprise (tm) WAF

  61. Sam Whited


  62. stpeter

    (this was before xmlhttprequest and such)

  63. moparisthebest

    stpeter, so you invented push notifications? :)

  64. Zash

    Oh, I though XHR dated back to the 90s, better recallibrate that.

  65. stpeter

    Zash: not sure actually

  66. Zash

    Or maybe it's just so long ago that my brain is compressing the 90-00 era into one...

  67. stpeter

    Well I'm wrong.

  68. stpeter


  69. Sam Whited

    I always think of XML only really taking off in the early 2000's, not that I was paying much attention at the time so I'm probably wrong