XSF Discussion - 2020-01-02

  1. Ge0rG

    Maybe the right answer is not "have an easy but ugly way to stuff JSON into XMPP", but "have an easily accessible short book on how to properly XMPP"?

  2. Zash

    Maybe title it "The definitive guide" or something?

  3. Zash

    dwd: 1) Why not `send_json(wrapper_xmlns, wrapper_name, payload)` and tell people to put their company URL as xmlns and wrapper_name becomes ~datatype. 2) what about pubsub? :D

  4. dwd

    Ge0rG, I think you'd still need a relatively consistent API so you got the same results in each library. Otherwise interop - the thing that should be a given with XMPP - becomes hard.

  5. Zash

    Implementation notes?

  6. dwd

    Zash, (1) Might work, I agree. But how do you tell your library to listen for those? (2) Yeah. You could stuff UDT into pubsub, I guess. But realistically that's getting "hard". I bet more people would be using pubsub if we did that, though.

  7. Zash

    FWIW we (Prosody) already shove JSON (in JSON containers) over pubsub for reasons.

  8. dwd

    Zash, Also on (1), how would you structure the XEP-0030 stuff consistently?

  9. dwd

    Zash, For sure. And I have no doubt at all that you don't need UDT at all.

  10. Zash

    Verse has a nice `client:hook_pep(xmlns, callback)` API, tho for PEP.

  11. Zash

    `hook_udt(xmlns, name, stuff...)` something something I don't know, API design is hard.

  12. dwd

    Yes, some libraries have good ways of doing things aligned with UDT's goals easily. But even when they're good, they're inconsistent.

  13. Zash

    That PEP hook call magically adds the correct +notify flag too. A UDT API could do something similar.

  14. pep.

    And then you're recreating your whole library API on top of UDT?

  15. dwd

    Zash, That is, thus far, what UDT says to do. The only different is that I hardcoded you `name` argument.

  16. Zash

    and xmlns

  17. Zash

    and disco prefix

  18. dwd

    Zash, Sort of. I made the payload element a fixed XMLNS and added another, really.

  19. dwd

    Zash, And that mostly because I felt it was easier to specify, write a schema for, and write code for.

  20. dwd

    Zash, In particular, UDT has the advantage that "unknown UDT" is identifiable as UDT. Which might be useful during development.

  21. Zash

    I guess, but it seems an un-XML/XMPP-ish thing.

  22. dwd

    It is, though less un-XML/un-XMPP than stuffing things into convenient pre-existing slots with wildly different semantics.

  23. Zash

    On a scale from WebDev to XMPP dev, how un-XMPPy is it? :P

  24. dwd

    Well. I would argue that it's minimally conformant to XMPP. It's not ideal for any specific circumstance, but it's not harmful either. So while it's idiomatically "impure", I don't think it's actively wrong.

  25. dwd

    So while the correct answer to the question "Should I use UDT for X?" is probably always "No", the answer is probably always "Yes" if they didn't ask the question in the first place - and that seems to be the usual case.

  26. dwd

    Also, I'm enjoying that UDT is generating all the discussion, which will allow the much-more-complex MAMFC to get a number without any scrutiny.

  27. dwd

    But Fallback, which I was hoping would generate more conversation, is not. Boo.

  28. Zash

    Ye ol' bike shed vs nuclear power plant issue?

  29. dwd

    Yes, indeed.

  30. jonas’

    Zash, re xmlns/name in the API: I agree with dwd that it’d be better to be able to detect UDT as UDT without having to know the specific use-case

  31. jonas’

    at least as payload. the disco feature could indeed be separate

  32. ralphm bangs gavel

  33. ralphm

    0. Welcome

  34. ralphm

    Hi all. Who do we have?

  35. pep.


  36. nyco

    (here, for the minutes)

  37. ralphm

    Guus sent his regrets.

  38. ralphm

    Seve, MattJ ?

  39. pep.


  40. ralphm

    Well, I didn't really expect much of a turnout the day after new years, so we should be declare a non-meeting

  41. pep.


  42. ralphm unbangs gavel

  43. pep.

    Usual time next week?

  44. ralphm


  45. nyco

    can you do that? :)

  46. ralphm

    nyco: I am a well-trained percussionist.

  47. nyco

    can you unpercussion?

  48. nyco

    that anti-drums, isn't it? :)

  49. ralphm

    That's classified.

  50. nyco


  51. dwd

    nyco, Banging an anti-drum is the same as unbanging a normal drum, I believe.

  52. nyco

    And unbanging an anti-drum?

  53. dwd

    nyco, Never do that, Obviously.

  54. MattJ

    Hey, sorry about skipping the meeting... I was unexpectedly somewhere without phone signal or wifi

  55. MattJ

    Well, I lie. There was wifi, and it required mandatory selling of your soul to various marketing agencies, along with your email, postal address and date of birth

  56. MattJ

    The privacy policy was pretty clear on that

  57. waqas

    That's meant to be a creative outlet, you are supposed to make up a persona

  58. MattJ

    I failed the test then

  59. ralphm


  60. waqas

    Yes, the turing test is based around real people not reading privacy policies and such.

  61. dwd

    Boris Johnson has signed up to a number of free WiFi services around here.

  62. dwd

    One can only assume those technology lessons really helped.

  63. jonas’

    brace for impact. I just deferred 21 XEPs. It was overdue.

  64. Zash


  65. jonas’

    (I’m going to post a reply on the deferral of OMEMO so that nobody thinks that this is a political move)

  66. Zash

    Cover up!

  67. pep.


  68. pep.

    politics everywhere!

  69. jonas’


  70. pep.


  71. jonas’

    now that I’ve an allocated slot for catching up on XSF work (tuesday evenings), I should be able to run deferrals more regularly

  72. jonas’

    it’s also much less frustrating now that I found out that I can simply docker push.

  73. dwd

    jonas’, My problem not yours, but it'd be really helpful if the mailstorm for deferred hadn't coincided with a couple of updates. I was wondering how XEP-0426 had been deferred already for a moment...

  74. jonas’

    dwd, not just your problem, which is why I specifically and manually sorted the updates to the end of the mailstorm

  75. jonas’

    otherwise they would’ve been mixed

  76. jonas’

    will be better in the future since there’ll be fewer deferrals

  77. Guus

    jonas’: massive amounts of appreciation for the massive amount of work that you perform!

  78. Guus

    (aka: I just opened my mailbox)

  79. jonas’

    Guus, please, also clap for pep., who’s been doing most of the editor work in the last months

  80. jonas’

    the deferrals was literally just running a script

  81. Guus claps for pep.

  82. Guus

    Also, there are plenty of others that put in massive amounts of work - these emails just happened to catch my eye today. That's not to say all other work is equally appreciated.

  83. pep.

    I'm only using jonas’' scripts

  84. dwd

    flow, Have you done anything in Smack for SASL2?

  85. flow

    dwd, nope, I have a major redesign of the connection mechanism to pave the way for ISR and the like ahead of me

  86. dwd

    flow, Oh? Any timeframe?

  87. flow

    the classical "when it's done", i have already forked a branch and did some thinkering. It's a high priority item of my does-not-pay-the-bills todo list. But SASL2 is a subsequent job, and I still don't like that SASL2 and Bind2 are unnecessarly coupled

  88. flow

    dwd, it sure would speed up the implementation if I implement do SASL2 without Bind2 and vice versa

  89. Zash

    https://xmpp.org/extensions/xep-0078.html but not a weird iq-like thing!

  90. dwd

    I didn't think Bind2 was coupled with SASL2 currently.

  91. Zash

    Oh and did we figure out how security-related the normal SASL stream restart was?

  92. Zash

    And whether it's safe to get rid of it

  93. dwd

    Yeah. It's important if you have no TLS (or do not trust it) and you do have a SASL security layer.

  94. dwd

    Which basically nobody does. We could insist that we do a stream restart if and only if there's a security layer inserted by SASL, or something.

  95. Zash

    Or don't trust the XML parser (maybe it has its own buffering or somesuch)

  96. dwd

    I think that only matters with a security layer, again.

  97. flow

    > dwd> I didn't think Bind2 was coupled with SASL2 currently. that's great then, but please make it the other way around too

  98. dwd

    flow, Meaning?

  99. flow

    dwd, possible I am talking about stuff that did not (yet) went into the xep(s). do you remember the discussion for last year's summit?

  100. dwd

    We talked a lot about a lot of stuff. (Hence the discussion in Council earlier). But yes, my overall thinking is that binding should end up as part of the SASL2 flow, because why not? Saves an RTT.

  101. flow

    dwd, that is fine, but if my memory serves me right, then I think it could be done optional

  102. flow

    I believe jonas’ aggreed with me, maybe he remembers more

  103. flow

    IIRC it was just a minor thing, like the placement of an element as child vs sibling, that would make a huge difference

  104. flow

    skimming over the xeps doesn't help me to recall what it was exactly, and potentially we discussed at the summit stuff that is not yet in the xeps

  105. flow

    dwd, sasl2 states "the main distinction is that initial-response data is held within an element", but isn't the initial response also within an element in sasl1?

  106. flow

    and what's the benefit of "A SASL2 success always includes the authorization identifier"? Don't you learn that also when binding?

  107. flow

    maybe return the authentication identity here, and not the authorization identity?

  108. dwd

    The initial response is bare within the authenticate element, whereas it's in a child element in SASL2 so we can add other stuff there.

  109. dwd

    And yes, you do learn the authzid in bind, but it's nice to have it sooner (especially if you need it for something else).

  110. dwd

    The authcid isn't always a string (for TLS/X.509/EXTERNAL it's the certificate).

  111. flow


  112. Zash

    Oh, that's a thing for IBR2 to deal with too

  113. flow

    not sure about the "it's nice to have it sooner part"

  114. Zash

    Funky cases where sasl username ≠ jid localpart

  115. flow

    otoh, if bind2 only returns the resourcepart, then it's probably a good idea to return the jid in sasl2

  116. Zash

    Or! Stream restart and the server gives you a JID in the stream header

  117. Zash

    No need to bind at all

  118. Zash

    And yes you may remember that I'm against imbuing resources with semantics

  119. flow

    but it appears that bind2 returns the full jid, and hence if you use sasl2+bind2 the sasl2 <success/> nonza will contain redundant information and waste bandwith. terrible!

  120. flow

    (just kidding)

  121. Zash

    Or TLS client certificate auth with resource in it, instant ready to use session!

  122. flow

    session in a can

  123. flow

    dwd, I am still confused about "the main distinction is that initial-response data is held within an element, so the "=" special case no longer applies.", in sasl1 the initial response data is also the textual content of an element and here we have the '=' special case

  124. flow

    ahh, now I get it, if <initial-response/> is non existent then there is no data

  125. flow

    if it carries the empty string, then the initial response data is zero-length

  126. flow

    ok, time to go to bed

  127. dwd

    Zash, What if the TLS cert had an ISR token in it?

  128. Zash

    What if?

  129. Zash

    And when do we get encrypted ClientHellos so all those TLS client cert things become realistic and not privacy nightmares?

  130. dwd

    Don't we already have those in TLS1.3?

  131. Zash

    Or what about them password based TLS key things?

  132. Zash

    dwd, nope

  133. Zash

    Didn't Big Cloud get those deferred until .. soon I hope?

  134. Zash

    Cloudflare says they have it. But does that mean only if I use their DNS over HTTPS thing?

  135. Zash

    It as in Encrypted SNI. But what about other ClientHello bits, like client certificates or whatever

  136. Zash

    Ah, yeah, ESNI is only enabled with DoH. D'oh!

  137. moparisthebest

    Yea and esni doesn't protect ALPN either