XSF Discussion - 2020-03-02

  1. Link Mauve

    larma, at some point I wanted to go through all deferred XEPs and move them either to obsolete or to experimental, but Council couldn’t agree to a process.

  2. jonas’

    Link Mauve: The process is there, and AFAIK all it needs is someone to drive it (does not need to be in council)

  3. jonas’

    all you need is to agree to shepherd all the XEPs you propose

  4. jonas’

    nobody stops you from doing that

  5. jonas’

    (actually we're already LC and CFE-ing a bunch of XEPs at the moment, so *right now* I'm going to say "wait until we're done with the shortlist")

  6. flow

    larma> How do people feel about enabling the Deferred check box by default on https://xmpp.org/extensions/ +1

  7. Kev


  8. Link Mauve


  9. Link Mauve

    jonas’, yeah indeed.

  10. larma

    Why is there no registry for ad hoc command nodes?

  11. larma

    And they are also not namespaced, so doesn't that imply that node names are opaque strings?

  12. larma

    XEPs relying on ad hoc command nodes having a specified name are therefor kinda broken by design

  13. jonas’

    larma, there is a XEP which defines a bunch of ad-hoc commands with specific names

  14. larma

    133 does, but it is only best practice

  15. larma

    so they are not well defined, just a suggestion

  16. jonas’

    it’s informational track, which is good enough

  17. jonas’

    it doesn’t define wire protocol, just usage of an existing protocol

  18. larma

    yeah, I guess that's fine for 133

  19. jonas’

    and they’re namespaced, just in a weird way (with URL#suffix instead of the more well-defined {URI}suffix)

  20. jonas’

    but yeah, in the Ad-Hoc XEP itself they’re opaque

  21. jonas’

    also kind of the point of ad-hoc commands to be, well, ad-hoc

  22. larma

    but there are others in experimental that define commands with a given name

  23. jonas’

    a registry would probably be good, but you know the state of the registries

  24. larma

    like 401

  25. Ge0rG

    401 is using URL#suffix as well

  26. larma

    yeah well my point is that any XEP using them would kind of risk name clashes with other names. As according to 50 it is not supposed to be a well defined name and be completely opaque (basically only used as an ID in response to the command list)

  27. larma

    according to xep 50 it would be perfectly fine to use UUIDs instead of names

  28. Ge0rG

    or unicode emoji...

  29. larma

    yeah, therefor the fact that you are using URL#suffix is worth nothing, because it is opaque and thus I could use the same name just as a selection of random chars

  30. larma

    a perfectly valid server implementation could generate random node names on every server restart

  31. jonas’

    it could, but then it would also be useless

  32. larma


  33. larma

    according to the spec, you are requesting the list of commands first and the node name is not even supposed to be displayed to users

  34. jonas’

    because automated entities will not be able to interact with the commands

  35. Ge0rG

    yaxim will rely on 0401 having that exact node name for invitation generation to work

  36. larma

    jonas’, automated entities can still automate with other entities. If they don't want to rely on the command listing before they would kind of have to agree on a set of commands out of band before

  37. jonas’

    like in XEP-0133?

  38. larma

    it's just a suggestion

  39. larma

    and frankly I believe nobody relies on it client side

  40. larma

    you can just do command listing before displaying administration commands

  41. larma

    And the randomly-picking-new-name-server would still work perfectly fine with everyone doing that

  42. jonas’

    a lot of things would work perfectly fine for some use-cases

  43. jonas’

    that’s a pointless statement to make

  44. jonas’

    you can ignore a lot of SHOULDs before you run into troubles

  45. larma

    My point is, I read XEP-0050 as it was considered to happen that way

  46. jonas’

    xep-0050 maybe, but xep-0401 most definitely not

  47. jonas’

    pubsub node names are also opaque

  48. jonas’

    but people would start to complain if you put OMEMO keys in a randomly named node

  49. larma

    then again my point is that xep-0401 is abusing another xep out of it's intended usecases

  50. jonas’

    (or avatars for that matter)

  51. jonas’

    same situation really

  52. larma

    So issue with use of 0050 is fine because we already have issues with use of 0060?

  53. jonas’

    no, because it’s not an issue

  54. jonas’

    if one specification tells clients to not assign any meaning to a value and another specification inherits on that and says "oh, in this case, you can assume that the thing you want has name X", then that’s perfectly valid

  55. Ge0rG

    a new abuse case by 0401?

  56. jonas’

    that’s the whole point of not assigning any meaning to a string in the base spec

  57. larma

    if it doesn't have any meaning in the base spec, how can another spec imply any meaning in it?

  58. jonas’

    easy. you write it in the text.

  59. larma

    https://xmpp.org/registrar/nodes.html < pubsub nodes are supposed to be registered at least

  60. jonas’

    that’s working well: Last Updated: 2004-10-11

  61. jonas’

    and yes, ad-hoc should also have a registry, I’m agreeing on that one

  62. larma

    well the only node that is errornously not registered is 0084 user avatar

  63. jonas’

    and all the nodes from '133

  64. jonas’

    ah, you’re with PubSub, not with Ad-Hoc, sorry

  65. jonas’

    but don’t they share the same namespace?

  66. larma


  67. jonas’

    ad-hoc and pubsub and disco

  68. larma

    what do you mean by sharing namespace

  69. Zash

    They all use nodes

  70. jonas’


  71. larma

    ad hoc node names are not the same as service disco node names

  72. jonas’

    sharing the namespace: undefined things happen if you have two things with the same name

  73. Zash

    From XEP-0030

  74. jonas’

    larma, good then

  75. jonas’

    we just need a separate registry

  76. jonas’

    and a document like the FORM_TYPE thing which defines that it shall henceforth be usedy

  77. jonas’

    and a document like the FORM_TYPE thing which defines that it shall henceforth be used

  78. larma

    that would work, so who is going to file the PR against 0050?

  79. larma

    (btw, this stems from flows suggestion to use ad hoc commands on the mailing list)

  80. jonas’

    haven’t read up on today’s stuff yet

  81. jonas’

    larma, the more interesting question is: who is going to fix the registries?

  82. jonas’

    there’s zero point in adding a registry if we lack the tooling to maintain it

  83. larma

    what do you mean with tooling? it's not like we advance tons of XEPs to Draft such that we really need tooling around it

  84. jonas’

    larma, there is no way to get changes to the registries on the website at the moment

  85. jonas’

    and by no way, I mean that you’d have to have iteam manually upload html files, which is Not Gonna Happen

  86. larma

    ok, that's bad indeed

  87. jonas’


  88. larma

    best case, the XMPP Registrar Considerations sections in XEPs would be machine readable and we would automatically generate the registry list from XEPs (plus additional predefined things where needed).

  89. jonas’

    that’s already mostly machine readable (with soem heuristics)

  90. jonas’

    but it wouldn’t catch cases like '84 which simply miss a submission to a registry

  91. jonas’

    so we’d also need tooling to detect such cases

  92. jonas’

    but that’s a completly different construction site

  93. jonas’

    the main issue is that we can’t get the existing registries updated (they have a repository, I think xsf/registrar or so, but as mentionied earlier, no way to bring stuff to the website from there)

  94. larma

    really? We use humans to verify the XEPs anyway because they advance to draft

  95. jonas’

    even if the "tooling" is a ToDo list

  96. jonas’

    because nobody is going to remember that there’s a registry for '30 nodes

  97. jonas’

    or '50 nodes

  98. jonas’

    it needs to be written down somewhere and people need to be aware that it exists and need to use it

  99. jonas’

    even better if it’s in code

  100. larma

    I am certain there is a way to update the website, we just need to poke the right people so that that part can be automated

  101. jonas’

    larma, guess what

  102. jonas’

    I’ve been doing that for the past six months

  103. jonas’

    since one of my PRs got rejected with "that should be in a registry"

  104. larma

    so, who is responsible then? board?

  105. jonas’

    does it matter?

  106. jonas’

    iteam doesn’t have the resources to do something about it

  107. jonas’

    I haven’t brought it up with board officially, but I don’t think that’d be much use either

  108. jonas’

    though maybe we should get board to pay MattJ to bring our infrastructure up-to-date

  109. jonas’

    I heard we have some funds over

  110. vanitasvitae

    Kev, as an author, could you comment on https://mail.jabber.org/pipermail/standards/2020-February/037092.html ? 🙂

  111. larma

    jonas’, I am a bit confused here: we do have an iteam, but they are not able to duplicate the automation that is already in place for xeps to the registry?

  112. jonas’

    larma, yes, because something changed at docker hub

  113. jonas’

    it would now require to grant docker hub privileges we don’t want to grant them

  114. jonas’

    we can’t add another repository

  115. jonas’

    so we have to use a different way to build the docker image with the static files

  116. larma

    so how about we put the registry in the xeps repo as they will be updated only at the same times anyway?

  117. larma


  118. jonas’

    doesn’t help, we still need to set up a another repository on the docker hub side of things

  119. jonas’

    (and connect that repository to github, which is the crucial step)

  120. jonas’

    and even then, I’d not at all be happy with this "solution"

  121. larma

    I don't use docker (for good reasons apparently) so I can hardly help there

  122. jonas’

    docker hub and docker are only tangentially related

  123. larma

    but they are

  124. jonas’

    as much as I don’t like the container hype, that’s got nothing to do with it

  125. jonas’

    docker hub is simply a crap CI infrastructure.

  126. jonas’

    the web UI is also crap

  127. jonas’

    (and who knows, the change may also be on the github permission model side of things, I don’t know)

  128. larma

    and it happens to be the main/default repo for docker

  129. jonas’


  130. jonas’

    the image hosting is fine

  131. jonas’

    just the automated building in *their* cloud is crappy

  132. jonas’

    (I have no idea how they pay for the insane amounts of bandwidth this thing must eat either way)

  133. pep.

    "jonas’> but it wouldn’t catch cases like '84 which simply miss a submission to a registry", while it's still not perfect, isn't protoxep -> experimental (and other subsequent state change) supposed to help a bit(?)

  134. pep.

    Ah larma suggested that already

  135. pep.

    "jonas’> though maybe we should get board to pay MattJ to bring our infrastructure up-to-date" I'd be happy to do this, if he agrees. Or to find someone else

  136. jonas’

    pep., '84 was changed in Draft, wasn’t it?

  137. jonas’

    no wait, I’m confused

  138. jonas’

    but '48 would be just the same actually.

  139. pep.

    yes human error is always a factor. It's never too late to fix it :) (once we get the registry back)

  140. Kev

    pep.: I *think* that paying MattJ would be potentially problematic because of renumeration and Board (I'd have to remind myself of our bylaws).

  141. jonas’

    Kev: what if membership votes on that instead of just board?

  142. Kev

    Someone would need to check the rules about Board members receiving remuneration whichever way it comes about, I think.

  143. Kev

    Section 4.3 Compensation. Directors shall not receive any compensation for acting as such, but Directors shall be entitled to reasonable compensation for services rendered as an employee of the Corporation. The Corporation shall be entitled to purchase officers’ and directors’ liability insurance without violating these Bylaws.

  144. Kev

    There we go then.

  145. pep.

    Kev: I was thinking about this indeed

  146. pep.

    I'm happy if it's somebody else then

  147. Ge0rG

    I'd also like to see iteam gain more resources, and if paying MattJ will give that, I'm all in

  148. Kev

    A couple of years ago we had an almost-offer of sponsorship in exchange for people helping the iteam with various tasks, but sadly it didn't come to anything.

  149. MattJ

    Just to be clear, is the quoted text from the bylaws saying it would be ok, or not ok?

  150. MattJ

    I read it as "ok"

  151. jonas’

    me too

  152. pep.

    Yeah, you can't be paid because you,re a director but you can if you actually work in/for the organization

  153. pep.

    I'd like to have a clue about finances before though

  154. Kev

    I read it as the XSF is able to employ a Director in order to pay them for work they wouldn't do as a Director.

  155. jonas’


  156. jonas’

    iteam isn’t director’s work, is it?

  157. moparisthebest

    if it is, many a director is shirking their responsibility :D