XMPP Council - 2017-11-08

  1. jonasw

    I’d like to add "Revisit BMH in the context of Styling" on the Councils agenda for today, but I don’t want to abuse my editor powers to do so, so I’ll just drop this here.

  2. daniel

    when (and by whom) was this vetod upon? I can't find the minutes for that

  3. jonasw

    Link Mauve

  4. jonasw


  5. jonasw

    and SamWhited

  6. jonasw

    but I don’t see rationales

  7. Zash

    Does that mean it was actually accepted?

  8. Ge0rG

    No, -1 is a veto

  9. Zash

    I'm trying to figure out if a rationale is required :)

  10. Ge0rG

    I'd be surprised if not.

  11. Kev

    It is required that anyone vetoing provides a rationale, but a rationale isn't required to veto :)

  12. Kev

    I believe.

  13. jonasw

    I am confused, Kev.

  14. Zash

    I can barely parse that sentence. I blame the coffee.

  15. Ge0rG

    Me neither. And I've got enough coffee to rule out that source of confusion.

  16. Zash

    The word "veto" isn't in XEP 1

  17. Zash

    "object" it says

  18. Ge0rG

    "confusion" can also result if you remove a substring of "coffeine infusion"

  19. jcbrand

    Ge0rG: unfortunately in English it's caffeine

  20. Ge0rG

    "confusion" can also result if you remove a substring of "coffee/? infusion"

  21. Zash

    > If objections are raised by the Approving Body on the Standards list or in its meeting, the XEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Approving Body member(s) regarding how to proceed.

  22. Ge0rG


  23. jcbrand


  24. Ge0rG


  25. Zash


  26. jcbrand

    yes please

  27. Ge0rG

    LMC with regex fail

  28. jcbrand

    Coffee contains caffeine. Kaffee beinhalted Koffein (funny mirroring there)

  29. jonasw


  30. jonasw

    Kev, can you clarify your statement?

  31. Kev

    Anyone vetoing a protoXEP needs to provide a rationale, but that doesn't mean that failing to do so magically accepts the XEP.

  32. jonasw

    Kev, that makes more sense, thanks.

  33. Ge0rG

    So SamWhited is currently in violation of XEP-0001...

  34. jonasw

    (so is Link Mauve, I think, at least on the list record I can’t easily find a rationale)

  35. Ge0rG

    Damn, so I've violated 0001 as well.

  36. Ge0rG

    jonasw: <Link Mauve> I’ve already read it yesterday evening, and I’m very much -1 on it due to the concept of waiving any format support, forcing implementations to support multiple formats and making it impossible for a message to carry more than one (think MUC for example).

  37. jonasw

    Ge0rG, that’s not on-list unfortunately, but good to have

  38. Ge0rG

    jonasw: it's in the logs.

  39. Link Mauve

    Hi, it’s time.

  40. daniel

    I'm here

  41. Link Mauve

    Ping Tobias, SamWhited, dwd.

  42. Tobias


  43. Tobias

    Link Mauve, you want to run the meeting?

  44. Link Mauve

    I can do that yeah. :)

  45. SamWhited

    oops, I am still confused and thought it was in an hour. I also am here though.

  46. dwd


  47. Tobias

    go ahead :)

  48. Link Mauve

    So 1) roll call.

  49. Link Mauve

    Everyone’s here.

  50. Tobias


  51. Link Mauve

    2) any minute taker?

  52. jcbrand

    I'm available

  53. dwd


  54. Tobias

    great, thanks

  55. SamWhited

    Tobias: grooming Link Mauve for command I see!

  56. Tobias

    SamWhited, :)

  57. Link Mauve

    3) Styling it seems.

  58. Link Mauve

    So, we have two proposals.

  59. Link Mauve

    Which is great!

  60. Tobias


  61. dwd

    And also, which is great?

  62. Link Mauve

    And https://xmpp.org/extensions/inbox/markup.html

  63. Tobias

    trello just mentions one of them

  64. Link Mauve


  65. Link Mauve

    jonasw sent the second one yesterday, maybe we forgot to add it.

  66. dwd

    This is the next meeting for both, so we should properly consider them now.

  67. Link Mauve

    It has had a proper announce email anyway.

  68. Tobias

    Link Mauve, but we probably want to vote on each individually, not?

  69. Link Mauve

    With these proposals, I’m finally happy with deprecating XHTML-IM, it seems jonasw took into account every criticism I’ve seen on the mailing list in all threads that have been talking about it recently.

  70. Link Mauve

    Tobias, sure, but we will vote on them next week.

  71. Tobias


  72. dwd

    Link Mauve, I don't follow - vote on what next week?

  73. SamWhited

    Don't we normally vote in the first meeting after a submission (or on list, of course)?

  74. Link Mauve

    (IIRC we have two weeks to vote on accepting a ProtoXEP, I can start the vote right away if you prefer.)

  75. dwd

    Link Mauve, Two weeks to vote, starting at the next meeting.

  76. dwd

    This being the next meeting.

  77. Link Mauve


  78. Link Mauve

    So let’s start.

  79. Link Mauve

    4) Vote on styling.html

  80. dwd


  81. daniel


  82. Link Mauve

    On list.

  83. SamWhited

    +1, naturally

  84. Tobias


  85. Link Mauve


  86. Link Mauve

    5) Vote on markup.html

  87. Link Mauve


  88. dwd

    SamWhited, You say naturally but XEP authors have voted against their own XEPs in Council before, you know.

  89. Tobias

    on list, haven't read that one yet

  90. daniel


  91. SamWhited

    dwd: I'd love to hear the story there

  92. SamWhited

    On list.

  93. dwd

    I'm +1 on this too. I don't think I want both, ultimately, and would prefer the other, but I'm not going to die on this hill if I can avoid it.

  94. Link Mauve

    The other one has seen a lot of criticism, before and after the proposal (it basically ignored most of the arguments against this approach), this one has only the downside of OTR and such not playing well with it; arguably OTR already has its own styling mechanism (it carries HTML).

  95. Tobias

    yeah. I think we shouldn't let restrict us by ancient OTR

  96. dwd

    Link Mauve, It is possible to take notice of arguments without agreeing with them, you know.

  97. SamWhited

    Alternative take: most of the critisism was addressed and the responses were ignored, but maybe this isn't the time and the place to be throwing statements like that around.

  98. Link Mauve

    dwd, of course, but it ignored all of the arguments against Markdown not to name it.

  99. Link Mauve

    Anyway, let’s move on.

  100. Link Mauve

    6) 0146 obsoletion.

  101. Link Mauve

    This has happened since last week, so I just archived the card.

  102. SamWhited

    Sorry for the delay on that

  103. dwd

    Link Mauve, No, I'm not comfortable moving on when you're accusing others of *ignoring* arguments raised.

  104. Link Mauve

    Sorry, 5) again.

  105. dwd

    Link Mauve, That's a very different accusation then asserting that the author has chosen not to agree with, or address, the arguments in the spec.

  106. SamWhited

    dwd, Link Mauve: this is the second time something like this has been brought up recently. I certainly don't think I ignored the arguments, just disagree and addressed why I disagreed, but since obviously multiple people feel that I ignored them I can try to address it on the list again if you want.

  107. jonasw

    dwd, I think if arguments are heard, they should be in a rationale in the XEP, which Styling may or may not have done.

  108. Link Mauve

    dwd, reading both the XEP, the mailing list, and xsf@, I haven’t seen most arguments addressed.

  109. SamWhited

    However, it would be more helpful if I had a list of specific things that you feel were ignored and then I'd be happy to address them (either in the XEP or on list)

  110. jonasw

    (I added a sectino "Design Considerations" to my XEP-0392, which I think is a good way to do that)

  111. Link Mauve

    I think both XEPs should contain a strong rationale about why they are designed that way.

  112. Link Mauve

    SamWhited, I can make such a list, I’ll add that to my TODO list.

  113. Link Mauve

    There were already somewhat-summaries on the mailing list, I’ll use these.

  114. Kev

    jonasw: I think addressing every on-list discussion in a Rationale section's a jolly bad idea, FWIW.

  115. dwd

    Link Mauve, FWIW, I do not wish to set any kind of precedence that every argument raised against a XEP has to be documented in the XEP.

  116. Kev

    Yes, this would be horrendous.

  117. Kev

    Else I want every XEP to document that the protocol isn't pink enough :)

  118. dwd

    Link Mauve, And having raised this argument, but those rules you'd have to document it in every XEP.

  119. jonasw

    sure, but if arguments are brought up multiple times and are well reasoned, I don’t see why not.

  120. jonasw

    I’m fine if people say my arguments aren’t well reasoned, I’d like to know why though :-)

  121. daniel

    message styling actually addressed a lot of critisms. for example we agreed on leaving the keywords in. get rid of the disco feature and so on

  122. Link Mauve

    dwd, indeed, that sounds like a bad idea, but it would be useful to have a short list of alternative approaches and why they weren’t taken.

  123. Link Mauve

    daniel, oh? Did it change since I last read it? I remember it letting the receiving client do whatever it wanted with the rendering.

  124. SamWhited

    I made promises to change it, I didn't want to merge until it was accepted

  125. jonasw

    Link Mauve, the ProtoXEP wasn’t updated, but people agreed to change it

  126. Kev

    Which is the right thing to do, incidentally.

  127. SamWhited

    (unless of course one of those changes is blocking acceptance)

  128. Link Mauve


  129. Kev

    We shouldn't be mandating rendering :)

  130. Link Mauve

    Which confirms my “on list” vote for 4). :)

  131. Kev

    FWIW, I would recommend that if one of these two XEPs are temporarily blocked, both should be :)

  132. Kev

    Because they seem to be a pair of competing proposals that should be considered together.

  133. Link Mauve

    Sounds fair, they both are as of now.

  134. jonasw

    Kev, I personally am not seeing it that way (anymore).

  135. Kev

    (Although this is counter to my desire to get stuff published ASAP so it's under XSFness, so ... yeah)

  136. Kev

    jonasw: You might be in the minority :)

  137. jonasw

    I think both can serve a very useful but distinct purpose each. And I think that we need BMH back.

  138. jonasw

    but I guess that discussion has to wait until next week if not everyone has caught up on the list yet

  139. jonasw

    I proposed to add reconsidering BMH to the agenda for today, not sure if that was seen?

  140. daniel

    so wait just to be clear and that we don't end up dead locking here. Link Mauve you want SamWhited to make those changes before you +1?

  141. Link Mauve

    I would be totally happy with revisiting my vote on BMH with compelling arguments, fyi.

  142. daniel

    because if SamWhited waites until this is approved this will dead lock

  143. Kev

    If already-promised changes are the only thing blocking, I think just taking it on Sam's word that he'll update would be fair. Personally.

  144. Link Mauve

    daniel, no, I haven’t fully caught up with the mailing list, I’m only based on my first reading of his XEP.

  145. Link Mauve

    Of course I wouldn’t block anything due to changes not having been pushed yet.

  146. jcbrand

    Just to be clear concerning the minutes, BMH was a previously proposed protoXEP that wasn't accepted right?

  147. daniel

    jcbrand, yes

  148. Kev


  149. jcbrand


  150. Link Mauve

    Yes, Flow’s one, about annotating which markup the body is formatted with.

  151. daniel


  152. SamWhited

    Can we hold off on revisiting that one until next week since it just got brought up?

  153. SamWhited

    I haven't had a chance to think about how that would interact with either of the new proposals

  154. Tobias

    sounds sensible

  155. dwd

    (I think, having been rejected, that it would need resubmitting for IPR purposes).

  156. Link Mauve

    Of course, your ProtoXEP changes how it could interact with the ecosystem.

  157. Link Mauve

    (That’s a detail, I’m sure Flow would be happy to do so. :))

  158. jonasw

    SamWhited, to be clear, I’d argue that Styling should get a BMH hint-namespace-thing

  159. daniel

    fwiw i don't think we need bmh for the opt-in approach to message styling that jonasw proposed

  160. Link Mauve

    I haven’t read that part yet, so I’ll abstain for now.

  161. jonasw

    I agree with daniel, but I see merit in the general idea of BMH, following the argument Flow gave when proposing it

  162. jonasw

    but moving this to next week until everybody has had time to consider all the XEPs seems very reasonable to me (not that I’d have any say in that)

  163. Kev

    I think what we actually need is an opt-out, but I need to have time to reply sensibly, and this is team appraisals week.

  164. SamWhited

    I think I agree with what Kev said, but I'm not 100% sure yet about the idea of hints in the styling xep.

  165. daniel

    yeah maybe opt-out is more sensible

  166. Kev

    I think what you want is <this-was-pasted/> for lots of thinsg.

  167. daniel

    i can live with both though

  168. Kev

    And that applies both to styling and to emoticons.

  169. dwd

    Kev, Auto-```?

  170. Link Mauve

    Kev, oh yes, sounds great.

  171. jonasw

    I still think we shouldn’t impose this on clients which don’t want that.

  172. dwd

    jonasw, That would be *terrible*.

  173. SamWhited

    Is this something people feel they need to make decisions on voting right now? If not, can we discuss specific details after the meeting? I want to make sure we get to everything before I need to leave for standup

  174. Link Mauve

    It still breaks existing simple clients, such as bots.

  175. Kev

    Usually when people disagree with me it's because they're clearly idiots, but I think in this discussion there are reasonable arguments on multiple sides.

  176. SamWhited

    Kev: I disagree.

  177. SamWhited

    (sorry, couldn't resist)

  178. Link Mauve

    SamWhited, we can discuss on list/in xsf@.

  179. Kev

    SamWhited: That would be one of the other cases.

  180. Kev


  181. Link Mauve

    So, 7) AOB?

  182. dwd

    Link Mauve, You don't want to obsolete '146 anymore?

  183. Link Mauve

    dwd, it’s obsolete already.

  184. Link Mauve

    6) was super quick. :)

  185. dwd

    Oh, misread.

  186. dwd

    No AOB from me then.

  187. Tobias

    next meeting?

  188. Link Mauve

    8) Date of next.

  189. Link Mauve


  190. SamWhited


  191. Tobias


  192. dwd

    WFM2. How many more meetings do we have? Two?

  193. Link Mauve

    Two yes.

  194. Link Mauve bangs gravel.

  195. Link Mauve

    Thanks everyone!

  196. Link Mauve

    Btw, thanks dwd for sending chat states, it really helps to know who is going to speak next.

  197. Link Mauve

    I wish every other council member would do the same.

  198. Tobias

    thanks Link Mauve for running the meeting, thanks jcbrand for the minutes

  199. Tobias

    Link Mauve, my client doesn't support that

  200. SamWhited

    Whew, we survived the styling meeting :) thanks all!

  201. Kev

    SamWhited: Are you *sure*?

  202. dwd

    Link Mauve, Well, here's the thing. Gajim sends them, but doesn't render them.

  203. Link Mauve

    Tobias, I know, you should push for that then, it’s extremely useful during a meeting.

  204. moparisthebest

    so far, I'm still waiting for the xmpp fork of 2017 due to styling

  205. Kev

    Link Mauve: No-one's going to push back on it.

  206. SamWhited

    Mcabber doesn't support anything… but it does do Vim style keybindings, which is really all I want in a client.

  207. dwd

    moparisthebest, You'll *never* be able to read messages again.

  208. Kev

    I've been saying I'd like this for ages, we've just not done it yet.

  209. Link Mauve

    dwd, ah yeah, I provided the patch to send them, I don’t know if any other contributor wants to display them yet.

  210. Link Mauve

    Kev, maybe I could contribute that then. :)

  211. dwd

    Kev, Our new client does, but I'm not using it yet (it's a little simplistic). Probably good enough for MUC meetings, though.

  212. Link Mauve

    As of today I’m now unemployed, I should have more time to fix the world!

  213. Kev

    Link Mauve: If you want to send in a patch for send/render CSI in MUCs, it would be gratefully received (subject to normal patch things).

  214. Link Mauve

    (Of course.)

  215. SamWhited

    Link Mauve: Unemployed, or Funemployed?

  216. jonasw

    (where’s the difference?)

  217. Link Mauve

    SamWhited, heh, doing things for myself, with myself as the drive, and myself as the client. :)

  218. SamWhited

    Nice, I'm jealous

  219. moparisthebest

    dwd, hmm gajim colored your whole message to me red and bolded the whole thing, hence, I have no idea what your intention was

  220. daniel

    i should write a gajim plugin that always randomizes the color in the xhtml variant of the message

  221. Ge0rG

    daniel: randomizes the color of each letter in the message.

  222. Link Mauve

    /load rainbow

  223. daniel

    its called syntax highlighting

  224. daniel

    nouns red, verbs blue, adjectives green and so on

  225. jonasw

    daniel, looking forward to a piece of software which gets this right!

  226. dwd

    jonasw, Stanford released some OSS code to do that in Java a while back.

  227. SamWhited

    An extension to replace all messages with the results of <messagebody> | cowsay | lolcat

  228. jonasw

    aww, lolcat doesn’t install

  229. Link Mauve

    __ _ / / (_) | _| | (_) | \_\

  230. Link Mauve

    Hey, just like Yaxim and Conversations display single emoji bigger, poezio could do so with figlet!

  231. jonasw

    figlet fails at utf8.

  232. Link Mauve

    I know. :(

  233. SamWhited


  234. SamWhited

    I can see that working well for all messages in Gajim.

  235. jonasw

    SamWhited, | figlet!

  236. SamWhited

    cowsay and figlet don't play well together

  237. jonasw

    they do

  238. jonasw

    also, that’s kindof the point

  239. SamWhited

    not on my machine; maybe there are options

  240. jonasw

    it looks weird for sure, but it produces sensible output

  241. jonasw

    ah ok, it breaks with long messages

  242. Ge0rG

    Link Mauve: take the Google NoTo Emoji font and render its SVG into the flickering avatar square

  243. SamWhited

    Would anyone be against me making a few slight changes to the styling XEP that don't actually affect anything before it actually gets published? I figured I might as well go ahead and commit some simple editorial changes (typos, definitions, etc.) that I was going to make assuming its accepted (since they're already done, I was only holding off on the larger changes because I didn't want to waste time if it didn't get accepted)

  244. jonasw

    SamWhited, editorial changes etc. seem fine to me

  245. SamWhited

    yah, me too, I just want to make sure the people voting don't have any objection

  246. Kev

    SamWhited: Was it accepted?

  247. SamWhited

    Kev: one remaining vote on list

  248. Kev

    If it's not accepted, there's no issue updating the protoXEP. If it's accepted, you don't need Council approval to make changes to an Experimental XEP of which you're the author.

  249. SamWhited

    good point, I guess I could make them anyways.

  250. Kev

    So while *technically* you should publish the version that was approved, I don't think it's going to hurt much.

  251. jonasw

    FWIW, I’ve been holding back editorial changes etc. until after approval too

  252. daniel

    Yeah just update it

  253. moparisthebest

    I haven't heard a single person argue it should be kept as-is so

  254. SamWhited

    I ended up pushing some of the simple non-editorial changes too: https://github.com/xsf/xeps/pull/537

  255. SamWhited

    Still more to do, but that was all the simple stuff that didn't require a lot of work or that I already had done, plus I tried to clear up a few things.