XMPP Council - 2023-08-30

  1. daniel

    I'm going to be on my mobile phone during the council meeting later so I'm checking the pending votes now...

  2. daniel

    Ge0rG: you are still pending on muc token invites. The meeting is your last chance to vote

  3. daniel

    Nothing else pending

  4. Ge0rG

    daniel: thanks for the reminder, I've finally taken the time to go through the proto-XEP, and I have questions.

  5. Ge0rG

    pep.: re MUC token invite, it reminds me very much of XEP-0401 (I happen to have had some time to consider a similar use case, inviting for an account instead of a room membership). Is there a reason to implement this via custom IQs instead of ad-hoc commands? The token request could be completely implemented using XEP-0401 syntax (if extended with optional time limit / count attributes). Token management could also be mapped to ad-hoc commands probably, without new protocol. You only need to define the form fields, command names and feature, plus the token-as-room-password part.

  6. daniel

    It's time

  7. daniel

    1) roll call

  8. larma


  9. Ge0rG

    (bonus points for offering the token creation feature to all clients that implement ad-hoc already)

  10. Ge0rG


  11. jonas’


  12. daniel

    We don't have an agenda this week so I'm just going to jump to date of next and AOB after quickly asking Ge0rG for his vote

  13. daniel

    2) pending votes

  14. daniel

    Ge0rG on muc token invites

  15. daniel

    You had feedback but does this block this being accepted as experimental?

  16. Ge0rG

    daniel: I'm very much inclined to -1 based on the above question.

  17. Ge0rG

    the proto-XEP complies with the formal requirements, but IMHO it creates redundant protocol that could be solved by ad-hoc commands with just a bit more boilerplate.

  18. daniel

    OK... Overlap imho isn't a blocker.

  19. daniel

    Anything can be done with adhoc commands

  20. Ge0rG

    I see value in defining the use cases, but I'd love to see the custom IQs replaced by ad-hoc, or at least a good rationale for not using them.

  21. Ge0rG

    Okay, in that case I'm +1, and I'm strongly urging the authors to either change that to ad-hoc ASAP or to provide a rationale for why-not, and I'd defer the -1 for a later stage of the XEP process.

  22. daniel

    OK. Thanks

  23. daniel

    3) date of next

  24. daniel

    +1w wfm

  25. jonas’

    +1w may not work for me, we'll see

  26. Ge0rG

    being the narcistig guy I am, I of course want to see the XEP-0401 syntax reused 1:1

  27. larma

    +1w wfm

  28. Ge0rG

    it looks like I'm blocked +1w and +2w

  29. daniel

    (I have thoughts on ad hoc commands Ge0rG. But now that the xep has been accepted maybe put your criticism into a mail to the standards list after it has been published and I'll respond with my thoughts on ad hoc commands)

  30. daniel

    (as noted earlier I'm on my phone and the council meeting is probably not the best venue for this anyway)

  31. Ge0rG

    daniel: I might forget that, so feel free to push me into writing that mail as you deem appropriate :)

  32. daniel

    > it looks like I'm blocked +1w and +2w Noted

  33. daniel

    4) aob

  34. daniel

    Looks like none

  35. daniel

    5) close

  36. daniel

    Thank you all

  37. larma

    Thanks daniel

  38. Ge0rG

    Thanks daniel

  39. jonas’

    thanks daniel

  40. larma

    Ge0rG, just my opinion on ad-hoc: I think it makes sense to use ad-hoc for usecases where clients that just implement plain disco + ad-hoc (= without understanding the details of the protocol) will still get reasonable user experience. Otherwise, it makes very little sense to use ad-hoc instead of just plain IQ. Now the question remains what is reasonable user experience. Looking at XEP-0401, the expire field in the result form for creating a user invitiation is already beyond of what I would consider reasonable user experience (because it contains data that would be displayed to endusers in a naive client but is not end user readable). Also the form lacks labels, but I blame that on the fact its still experimental (well, it seems it was proposed)

  41. Ge0rG

    larma: I agree there is probably no reasonable way to implement time-delta in ad-hoc, unless you just ask for days.

  42. Ge0rG

    I'm not a proponent of ad-hoc in general, and I'm pretty sure somebody convinced me to use it in 0401, but maybe it wasn't too bad after all

  43. Ge0rG

    I could well imagine having two or three ad-hoc commands along the lines of "Create a one-time invitation link" or "Create an unlimited inivtation link"

  44. Ge0rG

    My client shows a 401 invitation as: > Invite web page: https://yax.im/i/#yax.im%3fregister%3bpreauth%3d... > Invite URI: .... > Invite valid until: 2023-09-06T15:23:25Z

  45. Ge0rG

    and that's not too bad.

  46. larma

    It's fine for you. If you show that date string to a non tech person, they're gonna be confused

  47. Ge0rG

    yes, you'd have to convert it to local time and representation.

  48. larma

    But if you are a naive ad-hoc client, you don't know that this thing is meant to be a date.

  49. jonas’

    but the protocol is still usable

  50. jonas’

    nothing stops a client from handling specific ad-hoc commands specially to give them a nice UI

  51. jonas’

    you can't have that with random IQ protocols

  52. jonas’

    basic IQ protocols don't degrade as nicely as ad-hoc commands do

  53. larma

    sure, my point was that if the protocol *requires* that the client has special handling to have a reasonable UI, using ad-hoc doesn't add any benefit over plain iq

  54. jonas’

    '401 is not such a case though

  55. larma

    401 is a borderline case, because users can just ignore the confusing expires field

  56. larma

    I'm not saying that 401 shall not use ad-hoc

  57. larma

    I was just picking an example from the XEP that I had just opened in my browser 😉

  58. Ge0rG

    can we go back in time and add "date", "time" and "datetime" to 0004?

  59. jonas’


  60. larma

    Can we just replace 0004 with "current HTML form draft"

  61. Kev

    With both client and server dev hats on, I'd rather avoid specs using adhoc :)

  62. Ge0rG

    can we just replace XML with XHTML?

  63. larma

    I here one should use CBOR or Protobuf these days instead of XML

  64. Ge0rG

    Kev: so you'd always go with custom protocol?

  65. Kev

    I'm not saying 'always' as there's never a good reason to use adhoc, but I would generally default to not using it, rather than defaulting to using it.

  66. Kev

    Handling of the XML structures isn't the pain point in pretty much any XEPs, whereas any time you have to touch adhoc you find some sort of pain.

  67. daniel

    Ad hocs commands should only be used if you want to show them through 'dynamic' UI. Meaning 'specifying' ad hoc commands rarely makes sense in my view.

  68. Kev

    Hyperbole, but it's not far from the truth.

  69. daniel

    If you plan to use a custom UI an actual protocol is always easier to implement

  70. daniel

    So kinda/sorta what Kev said 😉

  71. Ge0rG

    I understand that we cannot fix the pain points in 0004.

  72. daniel

    And fwiw I hate that 401 uses ad hoc 😂

  73. Ge0rG

    Still, I think that specifying an ad-hoc command in a fashion that allows it to be used both by dynamic UI in legacy clients and by custom UI in modern clients is a Good Thing™

  74. Kev

    When M-Link added 191, we also added an equivalent adhoc to do the same thing.

  75. Kev

    Then later we were able to drop the adhoc interface, and were glad of it.

  76. Kev

    I think that's a more sensible approach than specifying protocols to use adhoc.

  77. Ge0rG

    I see, I'm way too idealistic

  78. Zash

    Since '0004 is a separate XEP, I don't see any reason why you couldn't pass any other kind of payload in ad-hoc

  79. Zash

    Nothing at all is a legitimate payload used for some parameter-less commands already

  80. Ge0rG

    Zash: you can pass any kind of payload, but you need a defined data type for it to be properly processed. and you need it twenty years ago

  81. Zash

    Tho at some point you just have a more complicated iq protocol :)

  82. Link Mauve

    There are already extensions to XEP-0004 field types, such as XEP-0221.

  83. Zash

    Unrelated to that, on the topic of invite tokens. I've been looking at OAuth 2.0 *a lot*, and it's basically all just passing tokens around and trading tokens for other tokens. So. Uh. It's all just tokens, all the way down!

  84. Zash

    ... down to the password

  85. Kev

    Which is a token

  86. Zash

    Oh no

  87. pep.

    So.. I see many voices against adhoc. What to do?

  88. Ge0rG

    I see people who dislike ad-hoc, but not so much substantial arguments against it. I suppose I'll have to withdraw my threat of -1ing and you can go on

  89. pep.

    Is there actually anything that says there shall be no overlaps? Why would a XEP get a -1 for that? It's not like there aren't many file transfer xeps, or avatars, or bookmarks, or whatever. What changed?

  90. pep.

    I'm sure there are overlapping RFCs too, not reusing whatever "pieces" have been defined here and there. (Since we're kinda following what IETF does?)

  91. daniel

    pep.: the wording is 'does it fill a gap in the xmpp'

  92. daniel

    And it's something to take into account before moving to stable.

  93. daniel

    Maybe not a hard blocker. But something to take into consideration

  94. daniel

    And while we have overlapping xeps currently hopefully not a lot of them are stable or above

  95. daniel

    You mention avatars. But vCard for example is historical (IIRC)

  96. pep.


  97. daniel

    Furthermore personally I don't necessarily agree that 401 and muc token overlap

  98. Zash

    One thing to think about is that we have a few cases of premature genericness

  99. daniel

    Only a few?

  100. pep.

    Yeah I wouldn't say overlap either, but I'm happy to say they're related. And I have been wondering if it's possible to make it so that a token allows to either create an account and allow in the MUC, or if the user already has an account then just allow in the MUC :x

  101. Zash

    Heh. Yeah. Things like Fastening.

  102. Zash

    Things that later turn out to be too generic and doesn't account for all the edge cases you find when you actually implement and deploy. So it might be better to wait with that until we have a bunch of similar protocols to think about wether they can be merged.