XSF Discussion - 2021-09-29

  1. Ge0rG

    Did anyone have a look at https://xmpp.org/extensions/xep-0459.html#future to see what should be promoted?

  2. Ge0rG

    jonas’: CS'22 links to inbox/ibr-token instead of xep-0445. That's a minor editorial change, do you want to get a PR?

  3. jonas’

    I like PRs

  4. Ge0rG

    anything to add in the revision history, or just the content itself?

  5. Ge0rG

    Not sure how many other Council members are still pending their vote for advancement

  6. emus

    General unexperience question: Why do we always make it a new XEP? why not update the existing one each year? So referencing would be easier?

  7. emus

    previous states could be archived somehow?

  8. Ge0rG

    emus: because archiving old version of XEPs is hard.

  9. Ge0rG

    emus: we have this discussion every year, and the TLDR is: we have a process for XEPs, so we use that process even if it's not perfectly suitable for CS, but making a new process for CS would be harder

  10. emus

    Ah ok, sorry. Did not knew it. Agreed

  11. Ge0rG

    marc: would you be opposed to issuing a Last Call on XEP-0401?

  12. Sam

    The fiscal host blog post was merged a few days ago, but it never showed up. Is the website broken?

  13. Sam

    (or something about the post maybe?)

  14. jonas’

    someone needs to poke it manually currently because of docker/travis changes

  15. Zash

    Does it work locally?

  16. Zash

    Did someone poke iteam about deploying?

  17. Sam

    Seems to work locally

  18. MattJ

    I'll deploy the website now

  19. Sam


  20. MattJ


  21. Ge0rG

    jonas’: https://github.com/xsf/xeps/pull/1110

  22. Ge0rG

    Holger: does ejabberd implement any of XEP-0379, XEP-0401 and XEP-445?

  23. Holger

    Ge0rG, no.

  24. Ge0rG

    Holger: do you have plans to?

  25. Holger

    I had a go at understanding this stuff just a few days ago (thanks to MattJ for explaining things). So if I got things right, marc's idea was to consume tokens based on XEP-0389 (in order to solve other problems, such as password recovery, in the same go). He has a patch for that. I take it you guys were unhappy with the '389 approach and went for '445 instead. AFAICS I'd mostly have to throw away his patch and start from scratch to go that route 😕

  26. Holger

    I might do that, but not right now.

  27. Ge0rG

    Holger: I wasn't unhappy with 0389, I was not expecting anybody to implement it any time soon

  28. MattJ

    Same here (I was just typing that)

  29. Holger

    🤷‍♂️️ whatever.

  30. Holger

    Just saying I think we have 0 lines of "Snikket code" right now (while I was wrongly assuming we did, before) ...

  31. Ge0rG

    Holger: XEP-445 is an alternative mechanism to 0389, so you could have clients use either.

  32. Holger


  33. Holger

    I'm not complaining about anything, mind 🙂

  34. MattJ

    You don't even have the ad-hoc commands?

  35. Holger


  36. Holger

    (Unrelated to '389 vs. '445, I know. I just had wrong assumptions about the state of affairs 🙂)

  37. MattJ


  38. bung

    Now is XMPP has received funds?

  39. Holger

    It's probably not rocket science, but does require a bit of thought, esp. the failure paths (token valid, registration fails and whatnot) with different DB backends.

  40. Holger

    But I see there's quite some interest and I do have some motivation to give into that demand, eventually 🙂 I see how the functionality can be nice to have.

  41. moparisthebest

    bung: what

  42. bung


  43. bung


  44. Ge0rG

    > If the <field/> element type is anything other than "fixed" (see below), it MUST possess a 'var' attribute that uniquely identifies the field in the context of the form (if it is "fixed", it MAY possess a 'var' attribute). So the recent disco#info result on this room was a protocol violation indeed

  45. Daniel

    General Compliance suite ramble: we have like 2ish clients that kinda come close to implement it completely. If we keep moving the goal post we will never have more clients that actually implement the whole thing

  46. marc

    Ge0rG: what was changed in 401?

  47. Guus

    Daniel: the document could also be used by third parties creating a proprietary client, as a guideline to 'how to do sensible things with XMPP' - but otherwise, yes, not having public clients that adhere to it is not ideal.

  48. Ge0rG

    marc: nothing, it should just get advanced from Deferred to Stable. But I'm looking at it and see things that got moved into 0445, so looks like my last PR wasn't merged?!

  49. Guus

    Then again: most of the developers that I'm talking to tend to read up on the documentation of the API of whatever library that they're using, and not-so-much XEPs. Sadly.

  50. Ge0rG

    Daniel: what's your proposal?

  51. Zash

    So should I again mention that maybe there should be two documents, one "current best practices" and one "future vision"q

  52. Zash

    So should I again mention that maybe there should be two documents, one "current best practices" and one "future vision"?

  53. Guus

    Yes please mention that again.

  54. Zash

    "that", again 🙂

  55. marc

    I'm not up-to-date, sorry

  56. Guus

    ba-dum tissshhh

  57. Daniel

    Nothing I'm just rambling. But maybe some form of stablilty. We started to have annual compliance suits but this somehow seems to put us under the pressure to put something new in every year

  58. Daniel

    However there is also value in being a bit more stable with the list of xeps

  59. Daniel

    I guess that's what I'm saying. Just thinking out loud really

  60. Guus

    Are we adding XEPs to the new compliance suits that didn't exist in the year before?

  61. Zash

    We didn't, unless something happens at the last minute

  62. Guus

    chat isn't that new. You'd think that the set of functionality that's deemed "sensible" does not change much year over year.

  63. Zash

    There's only a single change between 2021 and 2022, in that XEP-0156 is now required

  64. Ge0rG

    Zash: I proposed more changes just a few minutes ago

  65. Ge0rG

    Also we do have a "Future Developments" section that developers can use to look for exciting new things, and I'd normally not suggest bypassing that for new XEPs

  66. Ge0rG

    The exception is 0441 which was already part of 0313 before

  67. Ge0rG

    Some notable 0313 history... https://github.com/xsf/xeps/pull/547

  68. Ge0rG

    Can we get into our time machine and just merge that change back in 2017 please?

  69. Ge0rG

    marc: history of my proposed changes is https://github.com/xsf/xeps/pull/874

  70. Ge0rG

    (looks like it got lost in gitlab)

  71. Kev

    I have proposed in the past, I Think, that we have a document that defines what we think is needed to implement a decent client/server, and we version it rather than year it.

  72. Daniel

    I promise that once we have MUC-PAM you want mam to store groupchats

  73. Ge0rG

    Daniel: yes, and that will be defined in the MUC-PAM XEP and not be part of 0313

  74. Ge0rG

    Daniel: even if we made 0313 say "MUST NOT store groupchat", a later spec could easily override that

  75. Ge0rG

    On the other hand, making servers store groupchat without a clear way to query for that data or a clear use case is not a sign of a good protocol design

  76. Ge0rG

    But I sound like a broken record again.

  77. Zash

    Ge0rG: querying or filtering errors is a thing one might think about

  78. Ge0rG

    Zash: is anyone even storing errors?

  79. Zash

    Prosody (trunk)

  80. Kev

    FWIW, I’d be fine with not advancing MAM and leaving it until we’ve sorted all the XMPP2 type decisions we need to make, but I understand the desire to advance it given its wide use.

  81. Ge0rG

    Kev: given its wide use, advancing it is obviously not solving any problems beyond Council and the XSF looking incompetent about our process.

  82. MattJ

    If we're not going to advance stuff in wide use, I question the entire process :)

  83. Ge0rG

    MattJ: but wouldn't it make sense to compare what we advance with what's actually implemented?

  84. marc

    Ge0rG, I thought the new version of 401 referers to the new XEP that defines "your IBR" approach? I don't see this reference

  85. Ge0rG

    marc: yes, that PR was never merged

  86. marc

    Why is that?

  87. Ge0rG

    marc: I think it's because I used gitlab and because we have too few editors

  88. marc

    Okay, because that would be necessary before we can move 401 to stable IMO

  89. Ge0rG

    marc: I agree with that. Would you want a Last Call after https://gitlab.com/xsf/xeps/-/merge_requests/33 is merged?

  90. marc


  91. Ge0rG

    jonas’: ⬆️ would you like to get a github PR of that tomorrow?

  92. jonas’

    Ge0rG, yes