XMPP Council - 2019-07-24

  1. Tobias has joined
  2. Syndace has left
  3. Zash has joined
  4. Lance has left
  5. lnj has joined
  6. Remko has joined
  7. Syndace has joined
  8. debacle has joined
  9. lnj has left
  10. Holger has left
  11. lnj has joined
  12. dragonspirit810 has joined
  13. Holger has joined
  14. dragonspirit810 has left
  15. dwd Afternoon folks. Been a bit busy, but I'll knock out an agenda now - Ge0rG - I've spotted a couple of messages about Compliance 2020? Anyone else got anything?
  16. Ge0rG dwd: those messages are redundant to each other. I've got no further topics to add
  17. dwd <reaction>👍</reaction>
  18. Ge0rG 🙈🙉🙊
  19. dwd 🤣
  20. Link Mauve Let’s do the entire meeting only with emoji!
  21. dwd Anyway. I don't see anything new to vote on, just your chat on Compliance Suites.
  22. dwd Link Mauve, From https://www.economist.com/books-and-arts/2019/07/18/the-internet-is-changing-language-less-than-curmudgeons-fear - "They are not a language (try telling a complex story in emoji to someone who doesn’t know it already)."
  23. Ge0rG oh snap, I forgot an AOB
  24. Ge0rG dwd: it's from the Reactions / References discussion on-list: generalize "this message belongs to past message X" into a small self-contained XEP, change LMC, Reactions, References etc.
  25. Link Mauve +1 to that!
  26. Ge0rG namespace-bump everything!
  27. dwd Link Mauve, To what?
  28. Link Mauve dwd, +1ing Ge0rG’s AOB.
  29. Link Mauve Maybe a bit early. ^^
  30. Ge0rG Link Mauve: now it's too late to pull back
  31. jonas’ .
  32. dwd Finally managed an agenda.
  33. Ge0rG No worries, we've got some more 20mins
  34. peter has joined
  35. Ge0rG rings a bell
  36. dwd You rang?
  37. dwd 1) Roll Call
  38. jonas’ is here
  39. Kev I'm semi here.
  40. Ge0rG ,o/
  41. dwd Link Mauve, ?
  42. dwd 2) Agenda Bashing
  43. dwd Apologies for the very late one, but I think we just have two items of AOB to discuss.
  44. dwd Does anyone have anything else?
  45. Link Mauve Yes, I’m here. o/
  46. jonas’ not from me
  47. Link Mauve None from me either.
  48. Kev I need to catch up on a Lot of votes.
  49. Kev Well, most probably expired. Sorry I've been mostly absent recently, there's been a lot of Stuff.
  50. dwd 3) Items for a vote
  51. dwd AFAICT, we have nothing.
  52. dwd 4) Outstanding Votes
  53. dwd Kev, you have a couple expiring today; #797 and #796, plus two expiring next week.
  54. dwd FWIW, I'm pending on the last two proto XEPs, and unlikely to veto either, but haven't had a proper chance to look yet.
  55. dwd Everyone else seems to be up to date.
  56. Ge0rG There was list discussion for both.
  57. dwd Indeed, I've not properly digested all that yet.
  58. dwd 5) Next Meeting
  59. dwd Next week is fine for me (31st), but I'll be away sunning myself the week after.
  60. Kev I should actually be here next week.
  61. Ge0rG +1W WFM
  62. dwd \o/
  63. jonas’ +1w wfm
  64. dwd 6) AOB
  65. dwd We have two items, both fropm Ge0rG:
  66. dwd a) Road to Compliance Suites 2020 [Georg]
  67. dwd Ge0rG, Take it away.
  68. dwd (As in, start the discussion)
  69. Ge0rG When 2019 was published, we had a heated discussion regarding how to do 2020. Should it still be a XEP? A different kind of XEP? Something completely different?
  70. Ge0rG There were great ideas, but they'd require moderate to significant changes to our process and tooling.
  71. pep. (https://mail.jabber.org/pipermail/standards/2019-April/036074.html for context)
  72. dwd pep., Thanks.
  73. Ge0rG Nobody has stepped up so far to make these changes happen, therefore I propose to either a) ask for a volunteer to do so, or b) ask Ge0rG to fork CS2019 into CS2020 and to go on with the old process
  74. dwd I suggest (b).
  75. Ge0rG > Kev would like to schedule another discussion on this topic for the start of June, if only to determine it has failed.
  76. Ge0rG Luckily, it's around the start of June now.
  77. dwd Heh.
  78. Ge0rG I like the idea of living documents, but not with version numbers.
  79. Ge0rG And living documents with year numbers is sufficiently close to what our current process & tooling gives.
  80. dwd I like many things, but the enemy of the published compliance suite is the dream of the perfect one.
  81. Ge0rG Which is why I'd suggest to use August as a time window for somebody to step up and make that dream happen
  82. Ge0rG And after that I'd be glad to fork 2019 for 2020, and add a "Future" section
  83. Kev I think the enemy of the published compliance suite is actually the way we currently publish compliance suites.
  84. Ge0rG Kev: I hear you volunteer to create new process and tooling?
  85. Ge0rG ..until end of August.
  86. Kev Does it *need* new process and tooling?
  87. dwd Nobody ever does much in August, in the best years, though, and I have a feeling that once we hit September, and start the run-up to Council elections, etc, we'll never get anything out before 2020.
  88. dwd Hence, if Ge0rG is willing to crack on and do it, I'm firmly in favour of that.
  89. jonas’ I don’t have a strong opinion either way.
  90. Ge0rG Kev: do we have process for "living documents"? Our process for RFCs sucks, and the XEP process is not well-designed for living documents
  91. Ge0rG I don't want to manually keep track of changes in the History section.
  92. Kev Could we maybe schedule a higher bandwidth (short) discussion at some point using $UnpleasantVideoSolution with whoever feels strongly about this?
  93. Kev (soon)
  94. Kev And work out what the minimum needed to make the change is?
  95. Ge0rG Kev: process-wise, we'd have to figure out a proposal and present it to Board.
  96. Kev I know I'm fairly outspoken on this, but I believe our current compliance suites, and especially the noise they generate every year trying to get them published is actually harmful.
  97. Ge0rG I'm not sure that noise propagates outside of the core XMPP community.
  98. Kev Ge0rG: I don't think we need Board to sign off on a process unless it's overlapping with something we already have.
  99. Lance has joined
  100. Kev No, I think the noise it generates and the distraction for Council is the harmful bit.
  101. Kev If we want a formal process enshrined somewhere, yes it needs Board.
  102. Kev But I don't think that's a given.
  103. Ge0rG Kev: besides of burning out CS maintainers, I haven't percepted that as a huge problem.
  104. dwd I think any new process for publishing a Thing is going to add a lot of overhead to whatever we do.
  105. Ge0rG I don't object to scheduling a video conference for this, anyway.
  106. Ge0rG Formally, we'll have to bring it up before Board.
  107. Kev Not if we just want a page on the website, potentially.
  108. Kev But I think doing this over not-text might be a better way to iterate.
  109. Ge0rG Kev: we could have that today, with the tables extracted from latest-CS-XEP
  110. Kev It is an option.
  111. dwd OK. Is this going to be Council, or shall I open it up to other stakeholders?
  112. dwd I mean, the video call.
  113. Kev dwd: I suggest the minimum possible group to try to understand the issues.
  114. Kev e.g., Kev, Dave, Ge0rG would be fine.
  115. dwd Kev, Does that mean I don't have to come? *hopeful face emoji*
  116. Kev Not if you don't care about this.
  117. Kev Or don't care to care until later.
  118. dwd Kev, I'll come along and play chair. You don't think it's worth having any other client or server devs involved?
  119. Kev "Involved" makes it sound like excluding them from having input, which isn't my intention.
  120. Ge0rG it's about process, not about what XEPs to put into CS
  121. Kev But I think a very small number of people understanding the problem would be sane. Two, Three, Four people. That sort of number.
  122. dwd OK. I'll arrange something.
  123. Ge0rG 👍
  124. Kev Ta.
  125. dwd b) "This message belongs to past message X" [Georg]
  126. dwd Ge0rG, Yours again.
  127. Ge0rG https://mail.jabber.org/pipermail/standards/2019-July/036285.html section 1.
  128. jonas’ general agreement from my side
  129. Kev I think we should have a single consistent and archive-understandable way of doing this.
  130. Link Mauve Ge0rG, big +1 from me too.
  131. jonas’ and it’s not References.
  132. dwd I think thats good design as well.
  133. Kev My preference would be to do it with 372, even if that means stripping 372 back or something.
  134. jonas’ references may be able to re-use that, but References is more specific than that
  135. Ge0rG I'm currently very short on time, so I can't step up to write that proto-XEP. But it would essentially just provide a way to DAG messages to some root, and allow servers to emit the full DAG on request of any of the messages from it
  136. Kev jonas’: I think the reverse, no? References is more general than that.
  137. jonas’ Kev, depends
  138. Ge0rG Kev: stripping 0372 to "this message belongs to that message" is actually an option I've thought about
  139. dwd DAG? So you can reference a reference?
  140. Ge0rG dwd: you can LMC an LMC as well ;)
  141. jonas’ Kev, references wants to select a range of the body, which I consider more specific, but then again, that could be seen as more generic ;)
  142. jonas’ it’s not useful for non-body stuff in any case
  143. Link Mauve dwd, in general yes, you may want to react to someone attaching a message to another for instance.
  144. Kev jonas’: No, it allows selecting part of a body, it doesn't require that (or the concept doesn't).
  145. Ge0rG the only thing that References doesn't define is references to other messages.
  146. jonas’ Kev, if we can re-do References addressing the feedback I gave last year or so on-list, I’m game
  147. Kev Or, well, it says "If you have a URI, you put it here", but we don't have IDs for messages that are actually usable.
  148. Ge0rG and we don't have a message ID URI scheme.
  149. Kev That is the easier problem to solve, I suspect.
  150. Ge0rG I'd rather rename 0372 to something else ("Message Content Annotations"?), and make a new "Message References" XEP that's sole purpose is to reference messages.
  151. dwd Indeed - take <stanza-id/>, and do `xmpp:${from}?msg=${id}`
  152. Link Mauve Ge0rG, we’ll need such a way to reference a message, whether it is encoded as a URI or not shouldn’t affect it in any way.
  153. Kev Link Mauve: Doesn't affect *this*, but I think there are advantages to being able to URI-encod.
  154. Kev Link Mauve: Doesn't affect *this*, but I think there are advantages to being able to URI-encode.
  155. Link Mauve Same.
  156. Ge0rG Using URIs will become a major distraction because then developers end up wondering how to accept those URIs from the outside.
  157. Ge0rG And then security issues and maybe other problems.
  158. Ge0rG I'd like to avoid opening up that can of worms.
  159. Ge0rG which is why I think `<reference id="X" />` with something like https://xmpp.org/extensions/inbox/reactions.html#business-id to define what X is supposed to reference.
  160. Link Mauve Ge0rG, the outside may be a future XEP which links messages, or something like that.
  161. Link Mauve It may also be quite useful to have “the outside” for clients which want to scroll to a specific message.
  162. jonas’ inside XMPP, we can always clearly define semantics, we don’t have to wrap it into URIs
  163. jonas’ inside XMPP, we can always clearly define semantics, we don’t have to wrap an ID into URIs to give an otherwise unstructured string semantics
  164. Ge0rG Link Mauve: this is another can of worms.
  165. dwd Guys, we're running out of time - might I suggest continuing this discussion on list or in another chatroom?
  166. Kev Using Discord a fair amount, which does this, I can say that I find it very useful (not very often, but not infrequently) to be able to drop a URI into a chat message as a URI.
  167. dwd Kev, Slack also.
  168. dwd But anyway.
  169. Kev I use Slack less these days, I find, but sounds plausible :)
  170. jonas’ Kev, but that doesn’t mean that "Slim References" necessarily has to use URIs internally
  171. dwd Unless anyone's any other AOB?
  172. Ge0rG I'm not saying it's bad to have message URIs, I'm saying they are the wrong mechanism for the problem at hand
  173. jonas’ no other AOB from me
  174. Kev I don't have other AOB.
  175. dwd OK - go continue this on a list and encourage others to join in.
  176. dwd 7) Ite, Meeting Est.
  177. jonas’ thanks dwd
  178. Link Mauve Thanks. :)
  179. Ge0rG tnx dwd
  180. pep. "dwd> I'll be away sunning myself the week after.", you haven't had enough sun already these past few weeks? :P
  181. Kev Thanks all.
  182. dwd pep., Luckily, I live in Wales, so it's been raining the entire time.
  183. pep. lucky you
  184. Kev It's been 30ish here.
  185. jonas’ rain?
  186. jonas’ what’s that again?
  187. dwd My trips to London, though, have been hothothot.
  188. dwd Kev, Dropped down today, for me. Rain last night, cloudy much of today. Sunny now, though.
  189. Kev Rain last night for me, was fine this morning, been getting slowly warmer through the day, but nothing unpleasant.
  190. Kev Yesterday was unpleasant, though, and tomorrow it's meant to go back to that.
  191. Lance has left
  192. Ge0rG I suppose the unexpectedly early end of meeting means that somebody needs to write up things and go to standards@?
  193. dwd s/early/on time/ but I accept, with some shame, the "unexpectedly".
  194. Ge0rG dwd: not an attempt to blame anyone, or you, for it. It's ending at that time every week.
  195. Lance has joined
  196. lee has left
  197. lee has joined
  198. lee has left
  199. lee has joined
  200. debacle has left
  201. Lance has left
  202. Lance has joined
  203. Lance has left
  204. Lance has joined
  205. Tobias has left
  206. peter has left
  207. Remko has left
  208. Lance has left
  209. lnj has left
  210. peter has joined
  211. Lance has joined
  212. dragonspirit810 has joined
  213. dragonspirit810 has left
  214. moparisthebest has left
  215. moparisthebest has joined