XSF Discussion - 2021-06-11

  1. Alex

    emus, I only verify whether we have a quorum or not accorfing to our bylaws.

  2. Kev

    Someone checks that people don’t miss enough votes to be automatically ejected too, I guess?

  3. Alex


  4. emus

    I think it could be a helpful infornation to see how this is developing

  5. Kev

    I am *so* tempted to submit a cookie recipe XEP now.

  6. jonas’

    Kev, I’m gonna submit another one and we can have them compete in Experimental!

  7. Kev

    I’m actually sympathetic to the argument that XEPs are bad places to store organisational/procedural stuff, because it means devs et al. looking for ‘real’ XEPs have their view diluted, but … it’s what we have.

  8. jonas’

    that’s what you can filter the list for…

  9. Kev

    I wonder how hard it would be to filter procedural XEPs out of the /extensions/ list by default. Presumably not very.

  10. jonas’

    yep, should be easy

  11. Zash

    XEP-0001 started it!

  12. Kev

    I don’t think we actually have a filter on type, do we?

  13. Kev

    I realise if you understand exactly what you’re doing, removing ‘Active’ is similar, but … that’s not the target audience here.

  14. jonas’

    well you can filter by Active ... but yes

  15. jonas’

    I’m sure it can be extended nontheless

  16. Zash

    The RFC series also have procedural documents, no?

  17. Kev

    RFCs are significantly different.

  18. Kev

    Because no-one looks at the RFC list to see what they need to know to implement The Internet.

  19. Zash hides all-the-rfcs.epub

  20. MattJ

    Arguably that's a bad way of implementing XMPP too :)

  21. Kev

    Arguably they’re all bad ways of implementing XMPP :)

  22. Zash

    https://xmpp.org/extensions/ > Good places for developers to start are the compliance suites, as well as the technology overview pages. With a link to a recent compliance suite seems acceptable to me

  23. Kev

    I think filtering out Procedural by default would be fairly sane, low effort, and unlikely to be harmful.

  24. Kev

    I’m not suggesting we do any more than that, and I’m not going to cry if we don’t even do that.

  25. jonas’

    not sure what to make of the Code of Ethics vs. Conduct argument on members@. Is it just wordplay?

  26. jonas’

    (the "in person events" thing is strawy anyway, there have been enough instances where a CoC was useful at in person events, too)

  27. Zash


  28. Ge0rG

    Kev: surprisingly, we already have cookie mentions in seven XEPs, so there is prior art

  29. emus

    Kev: Can you explain again what you meant with that xep thought?

  30. emus

    or is it about the CoC?

  31. Ge0rG

    emus: I think it was a reference to https://mail.jabber.org/pipermail/standards/2021-June/038347.html

  32. Kev

    Which one?

  33. Kev

    The cookies comment was just because of the mail that said “We’ll end up with XEPs about cookies” or similar, so I was being silly.

  34. Kev

    The other was suggesting that we have checkboxes on /extensions/ for XEP types as well as statuses, and hiding Procedural (and possibly humorous) by default.

  35. Kev

    The basis for that being that most people going to the extensions page are probably looking for protocol.

  36. emus

    ok, yes

  37. emus


  38. Zash

    Group by type or something

  39. Kev

    Sam’s comment about Editors got me wondering. If the Editors were able to work out what their optimal tooling would be to make life easier, could the XSF pay someone to produce it?

  40. Kev

    Would the Editors want that, if it was possible?

  41. Sam casually mentions that he is freelancing now.

  42. Sam

    (and no longer a member whom it would be questionable to pay)

  43. Sam

    Jokes aside, I can't decide if this is the problem or not. In the past it's been that we've gone to make minor changes and then people want 50 other changes and it balloons and we never come to an agreement and now no one has the time to make changes. If we could fix the agreement part though we could pay our way around the "time to make big changes" part.

  44. ralphm

    Is it no longer questionable because you started freelancing, or because you are no longer a member of the XSF? :-D

  45. ralphm

    Or even, because you changed in some other way.

  46. Kev

    I’m glad Ralph sent that mail, because I was going to otherwise. Most important part of the CoC discussion 😂

  47. ralphm

    Thank you

  48. Ge0rG

    zimpy.im when?

  49. Zash

    .chat is the new hip

  50. ralphm


  51. Ge0rG


  52. ralphm

    Ge0rG: let me know when you have something to put up

  53. Ge0rG

    ralphm: we need some marketing budget to push for a nice new rebrand

  54. Sam

    ahhh, yes, I see. I hate this, but thank you for clarifying :)

  55. MattJ

    Ge0rG, who will be the target audience of this rebrand?

  56. Ge0rG

    MattJ: everybody!

  57. MattJ


  58. Ge0rG

    Everybody who's still using "Jabber" to mean "federated chat network based on xmpp"

  59. MattJ

    So 30+ geeks in Germany and Russia?

  60. Ge0rG

    Yes, those.

  61. ralphm

    Ge0rG: I even made a logo back wehn

  62. ralphm


  63. Ge0rG

    The developers and operators of the federated network should stand behind the re-branding. Or apply for the Jabber™ permission.

  64. mdosch

    > So 30+ geeks in Germany and Russia? Not sure whether referencing to the age or user count…

  65. MattJ

    mdosch, you get to choose :)

  66. Ge0rG

    mdosch: why not both?

  67. Daniel

    Zoomers don't use xmpp

  68. Kev

    Fun fact: Our IPR policy says we’ll only publish standards-track XEPs :)

  69. dwd

    It does?

  70. dwd

    Oh, huh. No, not quite.

  71. dwd

    It's says that an XMPP Extension is (for the purposes of the IPR policy) a standards-track XEP.

  72. dwd

    So, hmmm, technically you're exempt if you sneak a patent into a procedural XEP, for example, though whether that's practically a problem I really don't know.

  73. Kev

    Ah, but don’t you have to submit it in order for it to be published? And you can only submit ST XEPs.

  74. ralphm

    I'd say that an XMPP extension, indeed can only be on the standards track (or historical, I suppose).

  75. ralphm

    The expansion of "XEP" as we have now is confusing.

  76. Kev

    ralphm: That would mean that non-ST XEPs aren’t subject to the IPR policy.

  77. ralphm

    Well, yes, that's bad, too

  78. Kev

    XEP1, incidentally, says that all XEPs are XMPP Extension Protocols.

  79. Kev

    (Or, rather, that they’re synonymous)

  80. Kev

    I think there are probably better oceans to boil than the XEP duality, but slipping through the IPR is probably worth trying to solve.

  81. ralphm

    However, the preamble clearly means to cover all of the series and also each XEP published says it applies

  82. Kev

    I’d be inclined to just s/a standards-track/an/ in the IPR policy at that point, and call it done.

  83. ralphm

    But yeah, confusing. I'd not be against changing back to Enhancement Proposal, but then I'm unsure of what the X should stand for exactly (XMPP?, XSF?)

  84. Kev

    When talking about ST XEPs, I think extension protocol is the better name, FWIW. It’s just slightly unfortunate (but not enough to care about, for me at least) for Procedurals.

  85. ralphm

    I think the reasoning was that procedures are protocols, too, which I have to agree on

  86. ralphm

    Whether it is an extension, though...

  87. Kev

    I do not believe the current name is wrong.

  88. ralphm

    Not wrong, confusing

  89. Kev

    I think only slightly, really. I suspect most people who aren’t us simply don’t care what it stands for. I suspect most people implementing RFCs don’t know what RFC stands for.

  90. ralphm

    True. But given the comments on the ML, some people believe(d) that XEPs should only be about XMPP extension protocols.

  91. Kev

    I suspect that wasn’t just down to Extension vs Enhancement, though.