XMPP Council - 2018-12-12

  1. 4

    yellow vest revolutionary council : 🏦 🗼

  2. 4

    join the revolution : giletsjaunes@muc.jeproteste.info 😡 🏃‍♀️ 👩‍👩‍👧‍👦 ✊ 🧡

  3. moparisthebest

    Aw man did they raise xsf membership tax

  4. jonas’


  5. guus.der.kinderen

    > Aw man did they raise xsf membership tax 🤣

  6. guus.der.kinderen

    Also, that avatar had a green shirt.

  7. Ge0rG

    Is it that time of the week again?

  8. jonas’

    it is!

  9. jonas’

    well, in 8 minutes

  10. Link Mauve

    And this time I’m here! Sorry again for last week.

  11. Ge0rG

    Link Mauve: you better have some beverages with you this time

  12. Link Mauve

    I have tea besides me, like always.

  13. jonas’ imagines Link Mauve with a cup of tea while protesting

  14. jonas’

    that’s too british for you

  15. jonas’

    I think?

  16. Zash

    Spent too long on that island?

  17. Link Mauve

    I had rooibos in my thermos last Saturday. ^^

  18. Link Mauve

    In addition to a bottle of water, pretty much mandatory.

  19. jonas’

    I bet that thermos is classified as weaponry.

  20. jonas’

    because hard and such

  21. Link Mauve

    Damn, if I can’t import British customs anymore… Down with the Queen^Wpresident!

  22. Ge0rG

    you May have some problems.

  23. jonas’

    oh my god.

  24. Kev

    'tis time.

  25. jonas’

    'tis time.

  26. Kev

    And we seem at first glance to not have a chair.

  27. Kev pokes Dave.

  28. Ge0rG

    Does the XSF have a furniture budget?

  29. dwd


  30. jonas’


  31. dwd

    Sorry, just dashed back from an external meeting across the city.

  32. Ge0rG

    Kev: your magic worked!

  33. dwd


  34. dwd

    1) Roll Call:

  35. jonas’

  36. Link Mauve


  37. Link Mauve

  38. Ge0rG

  39. dwd


  40. Kev

    I is still here, naturally.

  41. dwd

    Full House!

  42. dwd

    2) Items for a vote:

  43. jonas’

    (not sure if dwd is waiting for suggestions or searching in his documents)

  44. jonas’

    (we did have a ProtoXEP submission at least)

  45. dwd

    a) Proposed XMPP Extension: Simple Buttons Inbox

  46. dwd


  47. dwd

    (Searching and fighting with a MacBook. Awful things)

  48. jonas’

    soo... I’m not happy with the things quality editor wise

  49. dwd

    Tempting to veto this until the examples are funnier.

  50. dwd

    jonas’, How so?

  51. jonas’

    e.g. the "OPTIONAL." thing which is left over below the Glossary heading

  52. jonas’

    section 9 is questionable too

  53. jonas’

    and such

  54. jonas’

    but I’m not here with my editor’s hat

  55. Ge0rG

    Do we have other comparable XEPs in place?

  56. jonas’

    Ge0rG, in terms of functionality or in terms of editorial quality?

  57. Kev

    We have accepted very raw XEPs in the past, if that's the question.

  58. Ge0rG

    in terms of functionality.

  59. dwd

    We've had a number of early Experimental XEPs in similar condition over the years, I think.

  60. Kev

    Often mine. Although I'm not sure I've gone quite this far.

  61. Link Mauve

    Ge0rG, we do have 0050, it’s mentioned already.

  62. jonas’

    Ge0rG, not that I know. the closest is data forms and ad-hoc, but they don’t do quite the same thing.

  63. Ge0rG

    I wonder if embedding a data form into a message would make sense instead.

  64. Kev

    They do so dangerously close to the same thing that a new mechanism seems wrong to me.

  65. Zash

    There's precedent for dataforms in messages in eg 0045

  66. jonas’

    Kev, which?

  67. Kev

    (xep4 in messages)

  68. jonas’

    indeed, kind of

  69. Zash

    I did a draft of that but it was ugly and horrifying and let's not go that way

  70. dwd

    Do we have buttons in dataforms?

  71. Ge0rG

    I kind of fear data-forms indeed.

  72. Kev

    I appreciate forms don't quite do buttons yet, but extending them for that and i18n seems more appropriate at first glance than a new mechanism that we'll later need to extend for other form things.

  73. jonas’

    dwd, no, but they could be handled with a list-single

  74. Zash

    dwd: not really

  75. Link Mauve

    dwd, we have list-single, which is close enough.

  76. Ge0rG

    aren't actions akin to buttons?

  77. Link Mauve

    It already is represented by buttons in some clients when there are few choices.

  78. Zash

    Ge0rG: those are fixed at next/prev/cancel/complete

  79. dwd

    Well, maybe - but with ad-hoc we did actions, as Ge0rG implies, not in dataforms.

  80. jonas’

    Ge0rG, they’re a Ad-Hoc thing, not a Data Forms thing

  81. Zash

    dataforms in message: https://xmpp.org/extensions/xep-0045.html#example-79

  82. jonas’

    vanilla Ad-Hoc does not allow passing the context of the conversation in which this is happening

  83. jonas’

    which this ProtoXEP does

  84. jonas’

    and which any solution which wants to have this needs to

  85. Ge0rG

    jonas’: I don't see context in this protoXEP

  86. jonas’

    Ge0rG, @from

  87. jonas’

    you can distinguish whether a reply from a user comes via a MUC or not

  88. dwd

    Ge0rG, There's context of conversation, not of message.

  89. jonas’

    although that would probably work via MUC IQs, but maybe let’s not go there either

  90. jonas’

    having context of the message is also a possibility with the protoxep by making the values unique

  91. Zash

    Combine with <thread> or whatever?

  92. jonas’

    (e.g. append the @id of the message)

  93. dwd

    So two questions:

  94. Link Mauve

    If two people send a <button/> in two following messages with the same @value, you have no way of knowing which one was referenced.

  95. dwd

    i) Do we think that having buttons in chat messages is OK?

  96. jonas’

    Link Mauve, that’s true for a MUC.

  97. dwd

    ii) Is this method so broken we should abandon it?

  98. jonas’

    i) yes, I do think that.

  99. Ge0rG

    +1 to (i), not sure about (ii)

  100. jonas’

    I do think that we should have that in fact, because there are many good and reasonable use-cases for this. Memberbot being one of them.

  101. Link Mauve

    jonas’, for direct chats too, if your contact sends you the same set of buttons twice.

  102. Kev

    i) I think some use case involving something like this is valid (not quite answering the question)

  103. jonas’

    Link Mauve, that’s your contact’s fault.

  104. Link Mauve

    dwd, i) definitely.

  105. dwd

    jonas’, memberbot gets around the lack by using xmpp URIs to click on, which is pretty ikky.

  106. jonas’

    dwd, I agree.

  107. Kev

    ii) It doesn't seem to be actively broken, but that's not the only reason to consider rejecting, I think.

  108. Ge0rG

    maybe a client should only render the buttons in the last incoming message?

  109. dwd

    Ge0rG, Or grey them out when clicked.

  110. jonas’

    do we wanrt to open the can of worms what the "last message" is again? :)

  111. Zash

    I'd like a generic <in-reply-to id=.../> plz

  112. jonas’

    Zash, SHIM?

  113. Link Mauve

    ii) I’ve needed way more than “just a set of buttons” a few times, for instance this very poll you’re making could do with a two questions text-single form.

  114. Kev

    I'm of the opinion that this is the Wrong Way, in the absense of further persuasion.

  115. Link Mauve

    So, not sure it’s that broken, but it looks very much not usable for more than a very narrow set of usecases.

  116. Kev

    I just can't quite decide whether I should veto or not.

  117. dwd

    OK, so can I have some votes please:

  118. jonas’

    regarding (ii): - I think those types of features are only useful for bots. - I think this proposal is something to play with. - I also definitely want more extensive features than this.

  119. Kev


  120. jonas’

    I think I’m with Kev, but it’s tricky.

  121. dwd

    I think I'm +0 on this.

  122. Ge0rG

    On-list as well, for similar reasons

  123. jonas’

    formal question: can I say -1 now and decide to change it to +0 or +1 later on, until everyone has voted or the vote expires?

  124. Kev

    I'm concerned that people will jump on this, implement the simple stuff, and then immediately start extending with other form fields, and we'll rebuild xep4.

  125. jonas’

    Kev, very valid convern

  126. dwd

    jonas’, We have, historically, allowed changes to votes until the last vote comes in, yes.

  127. jonas’

    Kev, very valid concern.

  128. Kev

    jonas’: I see nothing wrong with 'on-list, -1 if I don't do so'.

  129. jonas’


  130. Link Mauve

    On list.

  131. dwd

    jonas’, Also, what Kev says.

  132. jonas’

    on-list, -1 if I don’t do that.

  133. Kev

    (But if you do end up with -1, you're obliged to provide reasons)

  134. dwd

    jonas’, Though please do vote even if it's to confirm a veto, since otherwise you're delaying the end of the vote.

  135. jonas’


  136. jonas’

    also, good point Kev.

  137. jonas’

    so changing to pure on-list now, because I can’t give a clear reason for -1 on the spot

  138. Kev

    You don't have to on the spot, on standards@ is appropriate.

  139. jonas’

    Kev, if I say "-1 if I don’t go on-list", I kinda have to though :)

  140. Ge0rG

    would this protoxep be sufficient for the "interact with a bot" use case?

  141. dwd

    Out of curiosity, of those on-list, are any of you potentially going to vote +1, or is this a choice between -1 and ±0?

  142. jonas’

    Ge0rG, not for the use-cases I have in mind.

  143. Kev

    This is a choice between -1 and -0.

  144. jonas’

    dwd, there is a slim chance of +1

  145. Ge0rG

    there is a moderate chance of +1

  146. dwd

    I ask because unless we can find three +1's, there's very little point in continuing.

  147. jonas’

    my issue with data forms is still that they don’t have a i18n story, and while others seem to think that you can always discover the right language, I don’t think that’s true.

  148. Ge0rG

    I like the simplicity of the proposal, and it might be a good self-contained things not bothered by dataforms

  149. jonas’

    so on this ground alone, I thnik that this proposal has a material advantage over plain data forms.

  150. dwd

    jonas’, I'm afraid that i18n in more a theory than a practise anyway.

  151. jonas’

    dwd, I know of implementations which send i18n’d error messages, and implementations which can deal with that to some extent.

  152. Kev

    jonas’: I think we're faced with two options - one is to 'fix' xep4 in whatever way, the other is to invent an entirely new xep4. Given xep4's ubiquity, I'm far more inclined to fix that (until it's shown it can't be fixed).

  153. jonas’

    Kev, I agree.

  154. jonas’

    although I think that XEP-0004 in itself does too many things already.

  155. jonas’

    (I don’t like the mix of forms and reports under the same element, it makes implementations weird and validation more complex than necessary.)

  156. dwd

    Kev, The other alternative is a sort of mutation of XEP-0050 for chat.

  157. Kev

    dwd: Essentially extending xep4, I think, so I'd put that under the same heading.

  158. Zash

    'submit' type form field?

  159. Zash

    Like <input type=submit> in html?

  160. jonas’

    just a list-single with a specific var would do, no?

  161. dwd

    Anyway, you're all on-list, so let's move on.

  162. dwd

    Although what to, I'm not so sure - do we have anything else to vote on?

  163. Kev

    https://xmpp.org/extensions/inbox/cs-2019.html ?

  164. jonas’

    did previous council close the votes on #716, #715? sorry, I don’t have that in my mental cache at the moment and they’re still open on github

  165. jonas’

    oh, yeah, and that

  166. dwd

    Yes, just getting to that.

  167. jonas’

    (for future reference: https://github.com/xsf/xeps/pull/716 https://github.com/xsf/xeps/pull/715 )

  168. dwd

    b) Proposed XMPP Extension: XMPP Compliance Suites 2019

  169. dwd


  170. jonas’

    +1, but I’d like a discussion on why the CS are on the Standards Track and not Informational. It doesn’t make sense to me, semantically, except that XEP-0001 specifically lists CS to be on Standards Track.

  171. Link Mauve

    +1, even though there are a few new XEPs missing from it which would be useful in 2019, but that can be fixed.

  172. dwd

    I'm +1 on this.

  173. Ge0rG

    +1 for moving to experimental

  174. Kev

    I only caught this just before Council, so I need to on-list.

  175. Kev


  176. Ge0rG

    jonas’: what's the delta to CS'18?

  177. dwd

    jonas’, Adding a delta to the document would be handy, actually.

  178. Ge0rG

    (I think it would make sense to mention new / removed XEPs in the Revision History)

  179. jonas’

    Ge0rG, that would make sense if it was the same document

  180. Kev

    It would anyway, I think.

  181. jonas’

    one sec for the "diff"

  182. Kev

    Not here necessarily, in the XEP itself.

  183. Ge0rG

    jonas’: IMHO, it would make sense to keep the whole history of CS in the newest one.

  184. Link Mauve

    As per my email from last meeting, I’d like to make a lot more noise about compliance suites, calling it XMPP 2019 and doing a lot of marketing around this, pointing fingers to Pidgin and other abandonned clients.

  185. jonas’

    Ge0rG, that’s awful

  186. jonas’

    Link Mauve, maybe sync up with Tedd Sterr on this

  187. Ge0rG

    yaxim is abandoned by that definition 😢

  188. jonas’

    Ge0rG, ok, the diff is unreadable even for me, so I’d like to do that in a quiet minute

  189. dwd

    Link Mauve, It's something to be pushed up to the Board,m actually.

  190. Link Mauve

    Ge0rG, the goal is to stop with the complaint that XMPP is bad because Pidgin is bad.

  191. Link Mauve

    dwd, indeed.

  192. Ge0rG

    jonas’: at the minimum I'd like to see what changed since the last CS in the revision history

  193. jonas’

    Ge0rG, can do, but not right now

  194. Ge0rG

    Link Mauve: I know, but as long as Pidgin is advertised by the XSF, this is moot (https://github.com/xsf/xeps/pull/715)

  195. Zash

    Is "XMPP is bad because Pidgin is bad" solvable by redefining "XMPP"? I suspect we need to crowd-fund maintanence and development of it to fix that. :|

  196. Ge0rG

    Link Mauve: I know, but as long as Pidgin is advertised by the XSF, this is moot (https://xmpp.org/software/clients.html)

  197. Zash

    Is "XMPP is bad because Pidgin is bad" solvable by redefining "XMPP"? I suspect we need to crowd-fund maintanence and development of Pidgin to fix that. :|

  198. jonas’

    bump the stream header version

  199. Link Mauve

    Ge0rG, no, we can change things even if we don’t fix all of them at once.

  200. Ge0rG

    XMPP2 for president!

  201. jonas’

    Ge0rG, so you’re -1 until the revision history is fixed?

  202. Zash

    jonas’: YES! Kill the jabber:client & jabber:server namespaces and unify! :D

  203. jonas’

    oh no, you gave your +1 already :)

  204. Ge0rG

    jonas’: I'm +1

  205. jonas’

    Zash, sounds like a plan!

  206. Link Mauve

    And the announce effect is already something to aim for, for “compliance suites” or whichever new name we’d find.

  207. Link Mauve

    (I like Rust’s “editions”.)

  208. jonas’

    dwd, I think everyone gave a vote or on-list’d?

  209. Ge0rG

    Link Mauve: we can only change things if all of us are heading in the same direction.

  210. Kev

    I would very much like to see a logical diff from the previous suite, but that won't be influencing my vote (on-list).

  211. dwd

    Folks, what the Board chooses to do with the website and the compliance suites once we finish them is out of scope for this meeting.

  212. jonas’

    (FWIW, I’d also like input from the xmpp-based social network crowd; they could probably use their own section in the CS)

  213. Ge0rG

    regarding contents, I think that 0184 belongs to IM Core

  214. Link Mauve

    I’d like cs-2019 not to supersede cs-2018 until it is set active, but other than that +1.

  215. dwd

    Link Mauve, I think that's automatically the case.

  216. jonas’

    Ge0rG, can you put this on-list or somewhere less ephemeral than this room, please?

  217. Link Mauve

    dwd, it currently is set to supersede it, even though it’ll be experimental for a while.

  218. Link Mauve

    But that’s editor’s domain.

  219. dwd

    Link Mauve, Yes, but it's an intent until it's Active, I believe.

  220. jonas’

    it will never be Active

  221. jonas’

    because it’s Standards Track

  222. jonas’

    it can only become Draft or Final (on the positive side of things)

  223. jonas’

    it can only become Draft and Final (on the positive side of things)

  224. dwd

    ANything else?

  225. dwd

    (To vote on?)

  226. jonas’

    the PRs I mentioned above

  227. dwd

    jonas’, I'll check the status of those PRs later. I cannot recall their status either.

  228. jonas’


  229. jonas’

    fine with me

  230. dwd

    3) AOB

  231. jonas’

    just a quick note that we have had a XEP-0001 modification

  232. Ge0rG

    IIRC we voted on both PRs.

  233. Link Mauve

    jonas’, the last council said they didn’t have any pending vote.

  234. jonas’

    we can now move Proposed back to Experimental

  235. jonas’

    and also that we have a bunch of stuff stuck in Last Call

  236. jonas’

    so that would be something to look on for the next meeting

  237. Kev

    I thought everything got voted on last Council.

  238. dwd

    KevI think so too.

  239. jonas’

    ok, then it’s probably my (editor’s) own oversight

  240. Kev

    At least, everything I knew needed to be.

  241. jonas’

    For reference, those are the open LCs: XEP-0357 (Push Notifications), LC ends: 2018-11-03; https://xmpp.org/extensions/xep-0357.html XEP-0359 (Unique and Stable Stanza IDs), LC ends: 2018-11-03; https://xmpp.org/extensions/xep-0359.html XEP-0280 (Message Carbons), LC ends: 2018-02-22; https://xmpp.org/extensions/xep-0280.html XEP-0363 (HTTP File Upload), LC ends: 2018-06-18; https://xmpp.org/extensions/xep-0363.html

  242. jonas’

    since they’re open, I’ll re-start them due to council switch as editor soon-ish

  243. jonas’

    just so that you get an idea already.

  244. Kev

    At least 357 and 359 aren't open, we definitely finished those last Council.

  245. jonas’

    (after double-checking that they havent been voted on already)

  246. dwd

    jonas’, I believe that XEP-0363 is awaiting edits due to feedback, but I might be wrong.

  247. Ge0rG

    I'm pretty sure we also -1ed Carbons because of XMPP-NG

  248. jonas’


  249. jonas’

    ok, I’ll shut up now and do my due diligence as editor. sorry for the noise. :)

  250. dwd

    Any Other AOB?

  251. jonas’

    not from me

  252. dwd

    4) Next Meeting

  253. jonas’

    +1w WFM

  254. dwd

    Same XMPP Time, Same XMPP Channel?

  255. Link Mauve


  256. dwd

    That's 2018-12-19 16:00 UTC.

  257. Kev

    I will try to be here. I'll be in another meeting at the same time.

  258. Kev

    So preemptive tentative apologies.

  259. dwd

    I'll be (finally!) back at home.

  260. Link Mauve

    Kev, would another time suit you better?

  261. Kev

    Not a lot.

  262. Ge0rG

    I'll be on a train most probably.

  263. Kev

    It's only next week and last week it's an issue.

  264. Ge0rG

    Unless, due to strike, I'll be on a car. Which will make typing much more challenging.

  265. jonas’

    I can do any day of the week except friday and weekend next week at that time, FWIW

  266. dwd

    Let's stick with the same time and hope Kev/Georg can make it. We hit Christmas after that anyway.

  267. Link Mauve

    Yup, at which point we can do the meeting at 35c3. :D

  268. jonas’

    (not for me)

  269. dwd

    5) Ite, Meeting Est.

  270. dwd

    Thanks all.

  271. Kev

    Thanks all.

  272. jonas’

    thanks all

  273. Ge0rG


  274. Link Mauve

    Thanks. :)

  275. Ge0rG

    Oh, I'd also like to advance XEP-0410.

  276. Link Mauve

    Ge0rG, shouldn’t you do that on standards@?

  277. Ge0rG

    probably yes

  278. jonas’

    you wanna have a Call For Experience issued?

  279. Ge0rG

    I think I do. We have working implementations in poezio and in yaxim, and the server optimization in ejabberd and prosody