XSF Discussion - 2024-03-18


  1. Daniel

    As announced last week the editor just started the Last Call for two more XEPs.

  2. Daniel

    We still have more in the pipeline (stuff council has already voted on that didn't get processed and stuff that council will likely vote on soon)

  3. MSavoritias fae.ve

    > The benefit to a XEP being published with an official number is a sense of it being real and approved, and we can say as loudly as we like that experimental xeps are not real nor approved but no one outside this room will ever understand that, since it's not how basically any comparable process works agreed yeah. xsf could benefit more from an ietf model where it is basically "free" to publish a xep but then it needs work for it to get a number.

  4. jonas’

    well we do have protoxeps

  5. jonas’

    those are basically free to publish

  6. jonas’

    you make a PR on github, editor merges that, done

  7. jonas’

    but that also automatically triggers a council vote

  8. jonas’

    we could change that process to *not* trigger a council vote on numbering

  9. jonas’

    we could change that process to *not* trigger a council vote

  10. jonas’

    so that you have to request that separately.

  11. MSavoritias fae.ve

    yeah thats my thinking. basically remove the council vote and remove the numbers

  12. MSavoritias fae.ve

    and then the council only have to make sure in stable as in they get a number

  13. MSavoritias fae.ve

    that they process was followed and the xep looks good

  14. MSavoritias fae.ve

    that would make the work of council less and more focused and we wouldn't be having so many XEPs on the website with a number that are barely done

  15. jonas’

    might also need IPR policy modifications though, not sure.

  16. MSavoritias fae.ve

    what is an IPR policy?

  17. jonas’

    basically the XEP CLA

  18. jonas’

    https://xmpp.org/about/xsf/ipr-policy/

  19. MSavoritias fae.ve

    ah yeah probably. i imagine the signing of CLA and such can be moved to when the XEP becomes stable

  20. MSavoritias fae.ve

    there is probably less point to do it before that

  21. jonas’

    no, it should be done as early as possible

  22. jonas’

    to avoid ambiguities when multiple authors are involved

  23. MSavoritias fae.ve

    hmm your right. if there are multiple authors it could get tricky

  24. jonas’

    and multiple authors in some sense are involved the moment you ask for feedback on standards@

  25. Daniel

    what’s the issue with the approach of sharing it around privately in the very very early stages and then submit to council for experimental?

  26. Daniel

    it's not like council is rejecting XEPs left and right

  27. MSavoritias fae.ve

    its not about rejecting. its about less burden on council, and also less numbers used and more "official" xeps as singpolyma put it

  28. jonas’

    I can think of a few instances where XEPs have been rejected which should not have been rejected.

  29. Daniel

    jonas’, such as?

  30. jonas’

    the MUC avatar XEP?

  31. jonas’

    and I think I submitted something for MUC Tags ages ago which got rejected becasue "it should've been a registry update [ignoring that the registry is absolutely malfunctional]"

  32. MSavoritias fae.ve

    thinking about it wouldnt also cases like xhtml would have been handled better?

  33. MSavoritias fae.ve

    as in if it doesnt have a number we dont have to care that much about it being there

  34. MSavoritias fae.ve

    while now its a whole issue

  35. jonas’

    well, XHTML-IM was even accepted as Stable at that point, so not related

  36. MSavoritias fae.ve

    ah it was.

  37. MSavoritias fae.ve

    i wonder also if the xeps that float around could be submitted without a number and somebody could pick them up there

  38. MSavoritias fae.ve

    > well, XHTML-IM was even accepted as Stable at that point, so not related even so i wonder how xhtml would be submitted again given all the questions around it

  39. MSavoritias fae.ve

    with the number system

  40. Daniel

    jonas’: I'm trying to find what you are referring to with tags. That's seems to be an update to 45

  41. Daniel

    Not a new xep

  42. jonas’

    ah, right

  43. jonas’

    slightly different case ten

  44. jonas’

    slightly different case then

  45. Daniel

    not disagreeing just wondering which ones you have in mind

  46. Daniel

    > not disagreeing just wondering which ones you have in mind Sorry that was Dino sending a delayed message

  47. kurisu

    Can jingle content-add come before session-initiate?

  48. Daniel

    No

  49. jonas’

    Daniel, in any case, even that single rejection is unfortunate and caused much pain.

  50. jonas’

    having a space where such standards can be developed even without numbering would help keeping those who care engaged, and as a space to convince the XEP council that it's indeed a good idea.

  51. flow

    and we probably don't have to change much to accomodate for that, maybe just create a directory protoxeps/ in the xeps repo and make sure that the XEPs there are also published on xmpp.org

  52. Daniel

    just for me understanding. does your proposal also include listing the xeps somewhere?

  53. jonas’

    flow, we already have that, it's called "inbox"

  54. flow

    jonas’, I know that inbox/ exists, but it has usually the implict constraint that ProtoXEPs there will be submitted to council. It seems to stand for "council inbox". And even if not, it seems sensible to distinguish ProtoXEPs that are soon to be proposed to council and ProtoXEPs that are currently incubating with no immediate plan to propose them to council

  55. flow

    Daniel, that is what I meant with "publish on xmpp.org"

  56. Daniel

    if you include them on let's say xmpp.org/extensions you are essentially creating an additional state. imho we are already not good at moving xeps from state to state

  57. Daniel

    just like xeps currently stay in experimental for way longer then they should they will stay in inbox mode

  58. jonas’

    we could kill the experimental state in exchange for that, and now that discussion suddenly feels very deja vu

  59. flow

    Daniel, I had something like xmpp.org/extensions/protoxeps in mind. as first step similar to https://xmpp.org/extensions/inbox, which contained, IIRC, previously the html version of the inbox

  60. flow

    as second step, I would suggest immutable ProtoXEP states, so you have xmpp.org/extensions/protoxep/my-xep/my-xep-0.0.1.html and my-xep/my-xep-0.0.2.html and so on

  61. flow

    IMHO experimal still has a reason for existence, one distinguishing factor between XEPs in the ProtoXEP state and in the experimental state is that the latter should now allow breaking changes without a namespace bump

  62. flow

    IMHO experimal still has a reason for existence, one distinguishing factor between XEPs in the ProtoXEP state and in the experimental state is that the latter does not allow breaking changes without a namespace bump

  63. Daniel

    > in the experimental state is that the latter does not allow breaking changes without a namespace bump is it?

  64. MSavoritias fae.ve

    > we could kill the experimental state in exchange for that, and now that discussion suddenly feels very deja vu we could kill also deffered with it too

  65. Daniel

    imho what you are all describing is just the experimental state and we should be way better at moving things out of experimental

  66. flow

    Daniel, if what we are describing is experimental state then how come that this "new" push xep is not in it?

  67. Daniel

    experimental means author can basically push what ever they want

  68. MSavoritias fae.ve

    you are right in the sense that experimental state could move to accomodate that

  69. MSavoritias fae.ve

    i have said before that we have too many states anyways

  70. Daniel

    which new push xep?

  71. flow

    exactly, people not knowing about what is being developed is one reason we should accomodate better for protoxeps

  72. Daniel

    if there is something in the inbox that council has missed voting on please tell me

  73. Daniel

    if there is a PR that adds an inbox xep that editor missed please tell me

  74. flow

    there isn't, because people tend to develop things a bit before proposing it to council

  75. Daniel

    if it's not submitted for the inbox ask the author

  76. jonas’

    I think what would help much more than another state and protoxep inbox and whatnot would be a hedgedoc

  77. jonas’

    because this still requires interaction with git, which is cumbersome

  78. flow

    hedgedoc seems to be simply a concrete implementation to the abstract concept of a pre-experimental state

  79. Daniel

    the criteria for council to accept a new XEP should be very low. I say that in my council application. I encourage other council people to do the same

  80. MSavoritias fae.ve

    we could repurpose inbox to just be the experimental xeps without a number

  81. MSavoritias fae.ve

    then we dont need to change much except add a listing for inbox and thats it

  82. Daniel

    if people are 'affraid' of council please don’t be

  83. Daniel

    or speak to us privately on how we can change that

  84. MSavoritias fae.ve

    we dont have to create new states or new listings

  85. flow

    I don't think it's people being afraid of council, it's probably more "we don't want to submit to council while it is still a heavily moving target". but that's just an assumption on my end, would be nice to hear from the affected parties

  86. jonas’

    flow, it is a concrete implementation of an *easily accessible* protoxep state. what has been discussed before is not that (because git and so on)

  87. flow

    jonas’, I am not sold on the git argument, you have to find your way around git to submit later on anyway

  88. flow

    that said, making your processes easier is always a good idea, but then again, we would need the resources to do so

  89. flow

    therefore, I'd rather build on existing tooling, and this includes git

  90. jonas’

    flow, but iterating fast on a git repository where you are reliant on others to merge your changes feels wasteful both for those who are iterating and for the editor role who has to hit merge on everything.

  91. flow

    From my experience, git is sufficently agile even in the early phases in the life of a xep. it may not be ideal at the birth phase, we you ideally sit together for a few days, here, something like hedgehoc is cearly better suited to brainstorm the ideas. For example, OX started on etherpad, but at one point, someone sat down and write a first version of the XEP, of course with many holes in it. but from there on, it was git and the xml format of the xep

  92. flow

    From my experience, git is sufficently agile even in the early phases in the life of a xep. it may not be ideal at the birth phase, we you ideally sit together for a few days, here, something like hedgehoc is cearly better suited to brainstorm the ideas. For example, OX started on etherpad, but at one point, someone sat down and wrote a first version of the XEP, of course with many holes in it. but from there on, it was git and the xml format of the xep

  93. moparisthebest

    What exactly are we trying to solve with not giving a number early and instead leaving in inbox ?

  94. flow

    moparisthebest, giving people a place where they can develop their xep until they deem that it is ready for council

  95. flow

    and avoiding that this place is some random repo somewhere on the internetz where it is not visible to others

  96. moparisthebest

    Isn't this fully supported now though? Create protoxep PR, mark it draft, done?

  97. MSavoritias fae.ve

    > What exactly are we trying to solve with not giving a number early and instead leaving in inbox ? less states, less work for council, more "offcial" xeps

  98. MSavoritias fae.ve

    potentially better focus when the xeps do come to stable also

  99. jonas’

    moparisthebest, PRs to the xeps repo are not explicitly IPR covered, AIUI

  100. moparisthebest

    The proposition is an extra state, council is mostly idle

  101. Daniel

    I don't council has complained about too much work

  102. MSavoritias fae.ve

    nope. we can reuse experimental and inbox

  103. MSavoritias fae.ve

    and we can remove at least 3 states because of it

  104. Kev

    Not in recent years, anyway. I remember when it was hours of work a week.

  105. Daniel

    Btw part of the process is Last Call which involves reading other people's XEPs and providing feedback. We currently have 4 xeps in Last Call

  106. singpolyma

    Speaking of I was a bit surprised to see bind2 in last call? Isn't it just one and two half client implementing so far?

  107. jonas’

    last call doesn't even strictly need implementations.

  108. MSavoritias fae.ve

    isnt that a mistake?

  109. MSavoritias fae.ve

    to go to stable it should be widely supported

  110. singpolyma

    I have implemented bind2 and I think it's more or less ready, but I was still a bit surprised

  111. Daniel

    > isnt that a mistake? > > to go to stable it should be widely supported No? That's final

  112. singpolyma

    Stablu just means we won't make breaking changes every day on a whim

  113. singpolyma

    Stable just means we won't make breaking changes every day on a whim

  114. Daniel

    Besides bind2 would probably even make the final criteria at least what number of implementations is concerned

  115. singpolyma

    Makesure to do namespace versioning, changes must pass council, etc

  116. singpolyma

    > Besides bind2 would probably even make the final criteria at least what number of implementations is concerned Because this are two servers?

  117. Daniel

    Two servers or three servers. At least one client

  118. singpolyma

    I guess there's kind of two clients since I did the xmpp.js

  119. Daniel

    Prosody, ejabberd, mongoose (IIRC), Conversations

  120. Daniel

    But I'm not suggesting making it final

  121. Kev

    Remember that the reason for renaming Draft to Stable was presented as being that people weren't willing to implement specs labelled as Draft or Experimental. Following that logic we wouldn't expect a great many implementations to be available when things are advanced to Drable.

  122. Kev

    That said, I wouldn't expect things to go to Drable without having somewhat stable implementations proving the approach. I'm just not sure it's likely to be many.

  123. Daniel

    I can't think of an instance during my involvement with the XSF where we made a xep drable too early

  124. Daniel

    Which doesn't mean we shouldn't look out for it

  125. Kev

    Nothing comes immediately to mind for me, either.

  126. Daniel

    But again both sasl2 and bind2 have implementations

  127. Kev

    It seems like the right time to LC both, to me.

  128. singpolyma

    > Remember that the reason for renaming Draft to Stable was presented as being that people weren't willing to implement specs labelled as Draft or Experimental. Following that logic we wouldn't expect a great many implementations to be available when things are advanced to Drable. I do find it humerous that now we've swung the other way and most conversations are about too many people implementing experimental xeps. Can't win

  129. Kev

    I was never convinced by the Drable rename, but I think "Can't win" is exactly right.

  130. Kev

    There's some middle ground on most of these things where we try not to be making too many bad choices too often.

  131. Kev

    See also: Spec first vs. Implementation first. Both have major drawbacks.

  132. mathieui

    Kev: the perfect state is when you have neither the spec nor the implementation

  133. Kev

    It is certainly the cleanest :)

  134. MSavoritias fae.ve

    what is the usecase for final?

  135. MSavoritias fae.ve

    instead of stable

  136. Daniel

    It won't change any more

  137. MSavoritias fae.ve

    but why make that a state instead of keeping it stable?

  138. Daniel

    Stable changes but with NS bump

  139. MSavoritias fae.ve

    which already requires a lot

  140. MattJ

    Yeah, I agree Final is a bit weird and I wouldn't miss it

  141. MattJ

    In theory things like XEP-0045, which we'll never bump the namespace on, should be Final

  142. MattJ

    In reality, we have made multiple changes to XEP-0045 in recent years

  143. MattJ

    Mostly just notes and clarifications, but they would technically be disallowed if it were Final

  144. MSavoritias fae.ve

    like why would you want something to not change ever and create duplicate numbers? when as i understand a stable being NS bumped is essentially a whole new XEP for implementations to work on

  145. MSavoritias fae.ve

    same effort i mean

  146. MattJ

    Once it is so widely implemented that a change would be highly disruptive, for example

  147. MSavoritias fae.ve

    but then people can just keep using the old NS no?

  148. MSavoritias fae.ve

    but then again maybe xep numbers is cleaner

  149. MattJ

    Yeah, that would get a bit messy

  150. jonas’

    mmm let's bump the namespace of '30

  151. MattJ

    Well there are changes I would love to make to '30 :)

  152. jonas’

    :>

  153. Daniel

    Numbers are relatively cheap

  154. MattJ

    Developer cognitive load is precious

  155. MSavoritias fae.ve

    lol

  156. MattJ

    I think too many numbers can be daunting, and that's what a lot of our discussions are ultimately about

  157. MattJ

    E.g. deferred isn't really an interesting status, other than making the XEP list less daunting

  158. MSavoritias fae.ve

    ^

  159. MSavoritias fae.ve

    yep

  160. singpolyma

    It's mostly a branding thing. The biggest comment you see about XMPP from developers at this time is that you have to "know which one hundred extensions to implement" of course this is false, but having hundreds listed does sort of lead to that thinking slightly

  161. singpolyma

    Of course, an alternate solution is to have libraries good enough that devs mostly stop looking at xeps

  162. MSavoritias fae.ve

    also so many states to click or not click

  163. MattJ

    There's no perfect answer. The Other Protocol has only "one" spec, but their MSC-xxxx numbers are in the thousands already, and implementing those is often necessary for e.g. interop with Element

  164. MSavoritias fae.ve

    true true

  165. MattJ

    For comparison, see https://spec.matrix.org/proposals/#proposal-tracking

  166. MattJ

    and then you have the IETF, where every RFC is Final, and important updates/corrections can easily be missed if you don't go looking for them

  167. MSavoritias fae.ve

    right thats also a bad thing there

  168. flow

    singpolyma, having hundred extensions does not itself lead to that thinking. not having a good map for the xep jungle does. we improved on that a bit with the compatibility suites

  169. flow

    and yes, I heard that exact comment too, IIRC on the train to FOSDEM a few years ago. What we should better communicate is that there is really no way around having hundreds of extensions. every protocol that exists over multiple decades will accumulate extensions

  170. flow

    and yes, I heard that exact same comment too, IIRC on the train to FOSDEM a few years ago. What we should better communicate is that there is really no way around having hundreds of extensions. every protocol that exists over multiple decades will accumulate extensions

  171. jonas’

    or it will die

  172. MSavoritias fae.ve

    i was told to try to write an email server, but then i saw all the RFCs so yeah i get it

  173. jonas’

    (IRC)

  174. MSavoritias fae.ve

    but but IRCv3 /s

  175. jonas’

    see

  176. jonas’

    extensions :)

  177. Daniel

    The other counter argument to 'too many xeps' is 'only look at stable' which is why we need to be better at moving things to stable

  178. MSavoritias fae.ve

    i do think there comes a time where you should make the XEPs less tho. in the sense of when a bunch of MUC extensions get standardized or base XMPP you put them to the base MUC/XMPP/whatever specification

  179. jonas’

    also compliance suites, Daniel.

  180. MSavoritias fae.ve

    otherwise you end up with a bunch of conflicting stuff

  181. Daniel

    > also compliance suites, Daniel. Both

  182. flow

    MSavoritias fae.ve, I don't think that it really matters if you have four XEPs or one XEP. What matters is that those are clearly written and use correct cross references. Plus, an argument of "small XEPs are better" can be made. MIX was split into multiple XEPs for a good reason (IMHO). And a few summits back ralphm and zash litterarly tried to cut xep60 into smaller pieces

  183. MSavoritias fae.ve

    could go both ways yeah. the MUC xep is too big anyways

  184. singpolyma

    I added a github action to auto-label PRs to https://github.com/xsf/xeps/pull/1319

  185. cal0pteryx

    Nice!

  186. edhelas

    👍

  187. Kev

    Thanks.