XSF Discussion - 2017-02-22

  1. mancho has left

  2. tim@boese-ban.de has joined

  3. Zash has left

  4. daurnimator has left

  5. suzyo has left

  6. Kev has left

  7. vurpo has left

  8. vurpo has joined

  9. mancho has left

  10. Lance has left

  11. Kev has left

  12. blipp has left

  13. blipp has joined

  14. waqas has left

  15. vurpo has left

  16. Lance has joined

  17. daurnimator has left

  18. efrit has joined

  19. Lance has left

  20. Alex has joined

  21. Tobias has joined

  22. Tobias has joined

  23. xnyhps has left

  24. xnyhps has joined

  25. vurpo has left

  26. Kev has left

  27. SamWhited has joined

  28. waqas has joined

  29. Alex has left

  30. daurnimator waves goodbye

  31. daurnimator has left

  32. Steve Kille has joined

  33. daurnimator has left

  34. jere has joined

  35. efrit has joined

  36. efrit has joined

  37. efrit has left

  38. efrit has joined

  39. SamWhited has joined

  40. kalkin has left

  41. daniel has left

  42. kalkin has joined

  43. daniel has joined

  44. Kev has left

  45. efrit has left

  46. efrit has joined

  47. kaboom has left

  48. vurpo has left

  49. vurpo has joined

  50. efrit has joined

  51. Kev has left

  52. mancho has joined

  53. Kev has left

  54. Kev has left

  55. Zash has joined

  56. Guus has left

  57. Guus has left

  58. peter has left

  59. vurpo has left

  60. vurpo has joined

  61. Guus has left

  62. Steve Kille has left

  63. Flow has joined

  64. Guus has left

  65. Guus has left

  66. goffi has joined

  67. Guus has joined

  68. Flow has left

  69. goffi has left

  70. goffi has joined

  71. Guus has left

  72. Guus has joined

  73. Steve Kille has left

  74. Kev has left

  75. xyz has joined

  76. waqas has left

  77. vurpo has left

  78. vurpo has joined

  79. suzyo has left

  80. winfried has left

  81. winfried has joined

  82. xnyhps has left

  83. suzyo has joined

  84. SamWhited has left

  85. Ge0rG

    looks like today is the last day of the 0280 LC. Time to open some more PRs

  86. vurpo has left

  87. vurpo has joined

  88. uc has left

  89. vurpo has left

  90. vurpo has joined

  91. uc has joined

  92. Guus has left

  93. xnyhps has left

  94. Guus has joined

  95. Kev has left

  96. uc has left

  97. uc has joined

  98. xnyhps has left

  99. kalkin has left

  100. kalkin has joined

  101. vurpo has left

  102. vurpo has joined

  103. Kev has left

  104. xnyhps has left

  105. devnull has joined

  106. sezuan has left

  107. Ge0rG

    Could somebody have a quick view if https://github.com/ge0rg/xeps/commit/0ff5f4f30baca8a1cf5cc9fe5af55bbffb7d879c provides a clearer language? Original: https://xmpp.org/extensions/xep-0280.html#which-messages New: https://op-co.de/tmp/xep-0280.html#which-messages

  108. Ge0rG

    please :)

  109. Piotr Nosek has joined

  110. xnyhps has left

  111. devnull has left

  112. Yagiza has joined

  113. Valerian has joined

  114. vurpo has left

  115. vurpo has joined

  116. jcbrand has joined

  117. devnull has joined

  118. Kev has left

  119. jubalh has joined

  120. kalkin has left

  121. xnyhps has left

  122. Yagiza has left

  123. Yagiza has joined

  124. Martin has joined

  125. moparisthebest has joined

  126. kalkin has joined

  127. Ge0rG

    Any native speakers, please?

  128. blipp has left

  129. ralphm has left

  130. devnull

    Ge0rG: overall, I'd say I like the new wording better. It's clearer, and the specific meaning of the RFC-CAPITAL words is better IMO.

  131. devnull

    Only thing I'm thinking of is the third sentence. The original says (correct me if I'm wrong) a message of type="error" that is in reply to a message that itself was eligible for carbons, should be carbon-copied as well. To me it implies that other messages of type "error" that /aren't necessarily/ in reply to a message that was eligible for carbons don't have to be carbon-copied.

  132. devnull

    But in the revised form, it says that messages in reply to another message eligible for carbons are the __only__ messages of type "error" that may be carbon-copied.

  133. devnull

    I know it's a little bit nit-picky, but in my eyes the two sentences don't mean quite the same thing.

  134. Ge0rG

    devnull: you are right. I have implied the last rule here

  135. devnull

    That being said I don't really know the spec itself, so it might not matter anyway. I'm not sure.

  136. Ge0rG

    devnull: CCing an error only makes sense if the error-causing message was CCed as well

  137. Ge0rG

    devnull: from original: "A <message/> is not eligible for carbons delivery if it does not meet any of these criteria." - if this rule is applied, I can make the 'if' an 'iff'

  138. devnull

    Right. It's a little stronger of a statement.

  139. Ge0rG

    I'm all in favor of bold statements.

  140. kalkin has left

  141. xnyhps has left

  142. Kev has left

  143. suzyo has left

  144. suzyo has joined

  145. winfried has left

  146. suzyo has left

  147. suzyo has joined

  148. kalkin has joined

  149. nicolas.verite has joined

  150. nicolas.verite has left

  151. vurpo has left

  152. vurpo has joined

  153. Flow has joined

  154. mimi89999 has left

  155. dwd

    SHOULD is really MUST except for odd cases. I thought the consensus was that Carbons' choice of what to archive was deliberately loosely defined. This is a major change.

  156. dwd


  157. dwd

    I'm still asleep.

  158. Kev has left

  159. uc has left

  160. uc has joined

  161. Kev

    Carbon's choice to let implementations choose what's copied was a deliberate change to get through the previous LC, yes.

  162. Kev

    I think the proposed change makes things less clear, rather than more clear.

  163. devnull

    But I thought that was the exact time to use SHOULD/MAY--when there's a degree of choice between implementations.

  164. Kev

    SHOULD doesn't mean there's a choice.

  165. Kev

    It means there may be rare times where it's appropriate not to, but you can expect things to break unless you do it.

  166. Sonny has left

  167. Sonny has left

  168. Sonny has joined

  169. Sonny has left

  170. kalkin has left

  171. Ge0rG

    Kev: my gripe is with the "A <message/> is eligible for carbons delivery if it is of type X and condition Z" wording. Do you happen to have a more concise suggestion?

  172. Ge0rG

    I'm really not a fan of all the MAY or MAY NOT in that spec.

  173. devnull

    "a <message /> SHOULD be delivered with carbon copies if it is..." ?

  174. Kev

    There shouldn't be any MAY NOT, because that's not 2119ish.

  175. Ge0rG

    I can downcase the SHOULD/SHOULD NOT in the diff to make it less formally required, then the MAY/SHOULD from above should apply

  176. uc has left

  177. uc has joined

  178. Kev

    Ge0rG: You could extract the 'is eligible if' out to the top of the list with something like 'If following these rules, a message is eligible for carbons delivery if any of the following are true:' or such, I guess.

  179. Ge0rG

    devnull: that would achieve the exact opposite of my goal ;)

  180. Ge0rG

    Kev: thanks, I like that.

  181. Ge0rG

    Now I've started a rewrite of the MUC rules based on the SHOULD/NOT wording, but I might be able to manage that.

  182. Ge0rG

    Kev: should I make it an 'iff' while I'm at it?

  183. Kev

    I'm not sure it adds much, given they're optional rules anyway.

  184. Ge0rG

    I really need to read up on why they have been made optional.

  185. Kev

    Short version: We couldn't agree on MUST rules.

  186. Ge0rG

    isn't that exactly what a standards committee is for?

  187. Kev

    If we make them mandatory, I want them done 'properly' for future use in a mamsync-ish world, while (at least) Dave is firmly opposed to any changes that would make current implementations of the spec not compliant.

  188. jere has joined

  189. jere has left

  190. jere has joined

  191. jonasw

    Kev: your stance sounds very reasonable

  192. Guus has left

  193. jonasw

    it’s experimental, there should be nothing wrong with implementations suddenly being incompliant.

  194. Ge0rG

    Kev: mamsync and MIX

  195. Kev

    The counter argument is that it's de-facto Draft just by the number and state of implementations.

  196. dwd

    Ge0rG, A standards committee can either agree on a set of rules, or note that there isn't a single set of rules.

  197. Kev

    I don't agree with the argument, but it has legs.

  198. Ge0rG

    Kev: the <private/> -> <no-copy/> change mandates for a version bump

  199. jonasw

    Kev: the discussion(s) during the LC of 280 show that it’s not a draft yet for reasons.

  200. Ge0rG

    if we are bumping anyway, we can as well do it properly this time.

  201. dwd

    Ge0rG, I actually wouldn't complain about that. What I didn't want to see was a bump for some small case.

  202. dwd

    Ge0rG, While versioning does mean we're stable against incompatible changes in XEPs, we do have a problem in allowing the old (and often well-deployed) versions of XEPs to be easily found, though. I can think of a few XEPs where the old version has similar deployment to the current.

  203. dwd

    Ge0rG, And as an SDO, part of our job is to reflect reality as well as dictate what that reality ought to be.

  204. Ge0rG

    dwd: how is it bad to have an old version be easy to find (as long as it is explicitly marked as old)?

  205. kalkin has joined

  206. jonasw

    (I think dwd means the problem is the other way round – it’s hard to find versions of XEPs which are old but well deployed)

  207. Ge0rG

    dwd, Kev: do I have your blessing to move forward with defining 'SHOULD' rules based on current practice and what I have gathered so far for a new version-bumped 0280?

  208. efrit has joined

  209. dwd

    Ge0rG, No. You need consensus from standards@, not permission from an Editor and a Council member.

  210. Ge0rG

    dwd: I'm approaching you as two of the Elders Of XMPP, not in any formal function

  211. jonasw

    preparing a PR may help to have a focused discussion on standards@ though, imo

  212. Kev

    Ge0rG: I think it would be interesting to see what such a spec would look like, at least. Other than getting me to stop yelling about not liking stuff, my opinion's not worth much though.

  213. Kev

    That is, I don't think you need anyone's blessing to write the patch. (Getting it merged is another matter...)

  214. Ge0rG

    Kev: incorporated your wording idea, https://github.com/ge0rg/xeps/commit/f0e432c15ee3b811a4065abc4baa158ba5fae0c9 / https://op-co.de/tmp/xep-0280.html#which-messages

  215. dwd

    Ge0rG, If you can build a case to break compatibility, and the majority of those implementing or planning to find it compelling, then please do so.

  216. Guus has left

  217. Ge0rG

    the MUC and the is-not sentence are removed as the same meaning is covered by the "if and only if". A separate diff will be presented for MUC cases

  218. Guus

    -xep workgroup queues

  219. Bunneh

    Guus: XEP-0142: Workgroup Queues is (Deferred, 2005-05-09) See: https://xmpp.org/extensions/xep-0142.html

  220. Ge0rG

    dwd: "break compatibility" would mean "require implementations to run two versions for some time"

  221. Ge0rG

    The previous debates about 0280 on standards@ have shown that consensus is impossible to reach. I'm attempting the "MIX mode" here, by trying to write down what is the most elegant solution in my eyes.

  222. nicolas.verite has joined

  223. dwd

    Ge0rG, You're welcome to suggest a specific solution, of course. But you do need to obtain consensus.

  224. kalkin has left

  225. Ge0rG

    dwd: if I fail to obtain consensus, 0280 will return to 'Experimental' and do yet another round?

  226. dwd

    Ge0rG, I think we *had* consensus over the current loose case.

  227. Ge0rG

    dwd: last year's LC failed due to lacking consensus in the private/no-copy debate, IIRC

  228. vurpo has left

  229. vurpo has joined

  230. nicolas.verite has left

  231. kalkin has joined

  232. Ge0rG

    How would consensus be achieved? No opposing voices on standards@? A majority vote in members / board / council?

  233. dwd

    Ge0rG, Same as the IETF, I've always assumed. In practise, that's a majority of the Council believing there is consensus.

  234. MattJ


  235. MattJ

    Ge0rG, for reference: https://www.zash.se/carbons.html

  236. MattJ

    (and don't think that's a complete list)

  237. mancho has left

  238. Ge0rG

    I can't imagine that an experimental xep becomes carved in stone because it is widely implemented. At least the server implementors could provide both versions in parallel to make the upgrade path easier without breaking anything

  239. Ge0rG

    I've added more controversy to https://op-co.de/tmp/xep-0280.html#which-messages in the form of new MUC rules.

  240. Tobias

    Ge0rG, indeed...i mean that's what we have namespace versions for

  241. dwd has left

  242. dwd has joined

  243. Tobias

    if we wouldn't want to change anything becase *implementations*, then we might as well disregard any namespace versioning

  244. Tobias

    if we wouldn't want to change anything because *implementations*, then we might as well disregard any namespace versioning

  245. jonasw


  246. dwd

    Tobias, Sure, but if a spec has lots of implementations and yet is in Experimental, one has to wonder if our standards process has failed.

  247. Kev

    Or just it's something that needs solving sufficiently badly that people want to implement regardless. That doesn't mean it's the *right* solution.

  248. jonasw

    Kev: +1

  249. Tobias

    dwd, sure...nevertheless it shouldn't stop changes to carbons under an incremented namespace

  250. dwd

    So you're saying the process has failed, but we don't yet know why?

  251. Kev

    No, it means the process is working.

  252. Kev

    The point of experimental XEPs is to get implementation experience, no?

  253. Kev

    The process is only failing if we then say "Oh, people have taken part in this experiment, so we can't make changes".

  254. Tobias

    jingle file transfer is at its 5th namespace i think...swift doesn't work with all of them, it could with some work with more versions than it currently does

  255. Ge0rG

    And to improve based on that experience

  256. suzyo has left

  257. Tobias

    *namespace version

  258. dwd

    Kev, Either Carbons works well enough for widespread deployment (which it clearly does), and its status doesn't reflect that because our process is broken, or else we haven't managed to produce anything better, in which case our process is broken.

  259. suzyo has joined

  260. Kev

    Right. But the reason we haven't accepted (rather than produced, as there were solid suggestions IIRC) that 'anything better' is people clinging to "there are implementations, so we can't change things".

  261. Kev

    Which *is* a failure of our process, as I said above.

  262. Tobias

    dwd, what's the issue with allowing changes to carbons under an incremented namespace version?

  263. nicolas.verite has joined

  264. nicolas.verite has left

  265. Kev

    Incidentally, I *do* think that the wooly wording makes it 'good enough' (although I don't remember the nocopy implications and whether that should block it).

  266. goffi has left

  267. Ge0rG

    Kev: no-copy was suggested as a reusable replacement for the <private/> element that is only defined and used in 0280.

  268. Ge0rG

    then there was a long debate about the merits of MUST-NOT-when-private and SHOULD-NOT-when-nocopy

  269. dwd

    Kev, As for implementation experience, that's not what Experimental is for. It's for discussion. Draft on the other hand means "appropriate for further field experience", and one can argue the market has decided on that.

  270. Ge0rG

    and now it looks like at least the author and some other people agree to remove <private> and to use <no-copy> instead. And IMO this is a privacy-affecting and breaking change, so it requires a bump

  271. dwd

    Ge0rG, Please do work on building consensus. And note Zash's list of implementors; I'll be especially interested in seeing if those people want to update.

  272. Kev

    dwd: I am confident that was not the original point of Experimental. Maybe we've changed over the years so it's now what we say it's for.

  273. dwd

    Kev, I look forward to your proposed changes to XEP-0001. :-)

  274. Ge0rG

    dwd: I'm pretty sure I will fail to gain consensus in the sense that all implementors agree to follow the bump.

  275. dwd

    Ge0rG, Consensus, not unanimity.

  276. Kev

    dwd: That'd be the xep1 that says it wants people to implement Experimental XEPs?

  277. Tobias

    Ge0rG, doesn't have to be all, the majority of the actively maintained would be enough

  278. Kev has left

  279. dwd

    Kev, "While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product" ?

  280. Ge0rG

    dwd: I had the pleasure to coordinate a CVE with a dozen of client-only implementors in the context of Carbons, recently. It was a multi-week process which involved just a single-line change in the code.

  281. Tobias

    it's probably also the one that says Experimental XEPs can be expected to receive major changes

  282. Kev

    dwd: Sounds like it's encouraging implementation to me.

  283. Holger

    Ge0rG: So you have contact data of most relevant people! :-)

  284. Kev

    Certainly not saying what you originally said, which was that Experimental XEPs weren't for implementation.

  285. Ge0rG

    Holger: would you implement a bumped carbons that fixes MUC-PMs in ejabberd?

  286. dwd

    Kev, Sure. But not in the way Draft does: "the specification will be basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible."

  287. Kev


  288. Ge0rG

    So from 0001, it is legitimate and expected to make breaking changes in both 'experimental' and 'draft'. Thus I would not consider "gaining consensus from implementors" a requirement for moving an XEP forward.

  289. Kev

    I don't think "There are different stages of implementation" is the same as "Experimental XEPs are for discussion not implementing", which was with what I took issue.

  290. Steve Kille has joined

  291. dwd

    Kev, OK, I'll accept that.

  292. Yagiza has left

  293. Tobias

    Ge0rG, also Experimental changes don't have to go though council, while Draft changes have to go though council

  294. Ge0rG

    BTW, while we are at "breaking changes". My Carbons improvments depend on an addition of an element into XEP-0045, which is "Draft", but has no namespace version.

  295. dwd

    Kev, Nevertheless, I'd still argue that Carbons is de-facto Draft given the state of implementation.

  296. kalkin has left

  297. Ge0rG

    / s/depend on/would be even better with/

  298. Holger

    Ge0rG: I think ejabberd's 0280 code complies to your new text, and if it doesn't it will be fixed, yes.

  299. Kev

    Kev 9:59 ? :)

  300. Kev

    Oh, nice copy/paste.

  301. Ge0rG

    Holger: what about private/no-copy?

  302. Kev

    Kev 9:59 The counter argument is that it's de-facto Draft just by the number and state of implementations. :)

  303. Holger

    Ge0rG: I'd continue to honor both. Or does it help anyone to ignore <private/>?

  304. Tobias

    the state of the implementations was nicely reflected by the CVE, not?

  305. Kev


  306. Ge0rG

    Holger: honoring both is perfectly fine, my point is rather: you should indicate that you honor no-copy by advertising the new namespace

  307. Holger

    Ge0rG: I mean I understand why you'd want to remove if from the spec for cosmetic reasons.

  308. dwd

    Tobias, In as much as there were a lot of them, in production software, then yes.

  309. Holger

    Ge0rG: Sure.

  310. Holger

    Ge0rG: ejabberd already advertises support for :1 and :2, we can easily add :3 to the list :-)

  311. Ge0rG

    Holger: could you kindly review https://github.com/ge0rg/xeps/commit/5881e42fe7e56adb13ab29c46e1d88b903fdf07b and https://op-co.de/tmp/xep-0280.html#which-messages for readability and potential logic issues.

  312. dwd

    Ge0rG, BTW, I have no clue why you'd equate breaking changes with no need for consensus.

  313. Ge0rG

    dwd: I'm not sure how you draw the conclusion that I do that

  314. dwd

    [11:04:21] ‎Ge0rG‎: So from 0001, it is legitimate and expected to make breaking changes in both 'experimental' and 'draft'. Thus I would not consider "gaining consensus from implementors" a requirement for moving an XEP forward.

  315. Kev

    I also think that's outright wrong, and that it's not expected to make changes to a Draft XEP, but that the option is there if needed.

  316. Kev

    *breaking changes

  317. dwd

    Kev, The following sentence in XEP-0001 agrees with you: "Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable."

  318. Holger

    Ge0rG: "Clients SHOULD ignore carbon-copies of MUC-PMs related to a MUC they are not joined to." Are outgoing clients expected to add <x/> tags to PMs as well, or how would other clients detect outgoing PMs?

  319. Ge0rG

    dwd: 0001 allows to make breaking changes in 'experimental' and 'draft'. Therefore I do not consider the statement "client implementors can block breaking changes to such an XEP by denying consensus" as a valid excuse.

  320. Ge0rG

    Holger: yes, that would require changing 0045.

  321. kaboom has joined

  322. Ge0rG

    Holger: a client could also disco#info the bare-JID of course.

  323. Ge0rG

    Holger: and a carbons-enabled server that knows about the MUCciness of the MUC could inject an <x/> into the carbon

  324. Ge0rG

    Holger: maybe I should put all of these into a separate section?

  325. Holger

    I wouldn't like the idea of requiring clients to do a disco#info.

  326. Ge0rG

    Holger: me neither

  327. Holger

    Ge0rG: Aren't those details a bit out of scope?

  328. Ge0rG

    Holger: they are in-scope for both 0045 and 0280.

  329. Ge0rG

    Holger: unless we want a new XEP that only covers MUC-Carbons

  330. Holger

    I'd add the <x/> tagging to 0045 so that we can avoid cluttering 0280 with a list of possible strategies.

  331. Guus has left

  332. Ge0rG

    Holger: that is exactly what I plan to do. But it will be even harder to get consensus for that.

  333. Ge0rG

    Holger: so "add <x/> tagging everywhere" --> 0045. "use <x/> tag for carbon-filtering" --> 0280

  334. uc has left

  335. Holger

    That would be my solution, yes. The downside is that the filtering then depends on modern 0045 implementations, but in my book that outweighs the ugliness of disco#info / MUC presence tracking.

  336. Ge0rG

    Holger: and a server still could inject <x/> tags into messages it knows are from/to a MUC.

  337. Holger


  338. Ge0rG

    I'm not going to propose _that_ into the XEP ;)

  339. Holger

    Yes that's unnecessary.

  340. winfried has left

  341. winfried has joined

  342. kaboom has left

  343. Ge0rG

    Are there other corner cases with carbons? Transports? MIX? anything I forgot about?

  344. kalkin has joined

  345. goffi has left

  346. Holger

    I think direct MUC invitations (XEP-0249) are not carbon-copied although that might be desirable?

  347. Steve Kille has left

  348. Ge0rG

    Holger: which rule do they fail at?

  349. Holger

    Ge0rG: type=normal messages are only copied if they have a body.

  350. Holger

    0249 explicitly forbids a body, IIRC.

  351. Yagiza has left

  352. Flow

    do we need a <copy/> xep334 hint?

  353. Flow

    do we want one?

  354. xnyhps has left

  355. Holger

    I think we do (and I suggested that before).

  356. vurpo has left

  357. Holger

    Ge0rG: Then again, if the receiving client bookmarks the room on invitation, the other clients will follow. As everyone (*cough*) is using PEP bookmarks these days, this will be instantaneous ...

  358. Ge0rG

    Holger: yes. Right. But even then, what if you are not on your primary client right now?

  359. Ge0rG

    Holger: I'll change the invitation wording to include both directed and mediated

  360. Yagiza has joined

  361. xnyhps has left

  362. vurpo has joined

  363. Holger

    So servers will have to search for <x xmlns='jabber:x:conference'/> ...

  364. Guus has left

  365. nicolas.verite has joined

  366. nicolas.verite has left

  367. nicolas.verite has joined

  368. nyco has left

  369. edhelas has joined

  370. Ge0rG

    Holger: some MUCs also send a captcha request per normal message from bare JID prior to allowing you to join.

  371. Ge0rG

    But I'm sure it's fine to deliver that to any subset of the user's client, as long as it includes the one joining

  372. Holger

    I mean generally there's two options, either we teach 0280 about each such special case, or we teach the XEPs that define the stanzas in question to mark them appropriately (using 0334 hints or whatever).

  373. Ge0rG


  374. Ge0rG

    Holger: MUC-PM should only be reflected to MSN sharing clients. How can you teach that?

  375. Ge0rG

    'sent' ones, that is

  376. nicolas.verite has left

  377. Holger

    MUC PMs should die, but it seems they don't, no matter how often I repeat it!

  378. Holger

    They're special and I think it makes a lot of sense to mark them as such, regardless of 0280.

  379. Holger

    But apart from those, I'd try to avoid adding all sorts of weird rules to 0280 and rather have the sending entity mark stanzas appropriately.

  380. Ge0rG

    Holger: you can't just kill them, they are useful

  381. Tobias

    Holger, indeed...need to add some code to Swift that it will uses the real JID if it's known

  382. Holger

    I mean this is really about addressing an account vs. addressing an individual client. If I did XMPP from scratch I'd carbon-copy everything sent to the bare JID and nothing sent to a full JID.

  383. nicolas.verite has joined

  384. Ge0rG

    Currently, I'm getting something between zero and two copies to my clients, and sometimes I even can't respond.

  385. Holger

    We're not doing if from scratch so I'd go for hints instead, whereever it makes sense.

  386. Valerian has left

  387. Holger

    Ge0rG: My usual rant is that MUC PMs are only useful to the very small circle of active XMPP community members, i.e. to us. Nobody else uses anonymous rooms. But I figure we are not a negligible part of our target audience :-)

  388. nicolas.verite has left

  389. nicolas.verite has joined

  390. Ge0rG

    Holger: no, MUC-PMs are useful to people who use clients that don't auto-fallback to the participant's real JIDs

  391. Holger

    All clients would do that if they weren't all written for geeks.

  392. Steve Kille has joined

  393. Ge0rG

    Holger: 0045 is a pretty horrible specification. You can't argue that implementations of it are broken because they are geek-focused

  394. Holger

    I'm only arguing against "MUC PMs are useful".

  395. MattJ has left

  396. nicolas.verite has left

  397. Holger

    We're reimplementing them in MIX because we're still geek-focused.

  398. Ge0rG

    Holger: IMHO, proxy-JIDs in MIX are another, much more severe, side-effect of the geek-focusedness

  399. Valerian has joined

  400. dwd has left

  401. Ge0rG

    Holger: it doesn't take very much to fix MUC-PMs though.

  402. Holger

    Well same thing in my book. Anonymous rooms.

  403. Holger

    Anyway I'm aware that I'm quite lonely with my view, and I don't want to spam this room by repeating myself.

  404. Ge0rG

    Holger: and there is MUC-light for non-anon easy chatrooms

  405. Holger

    Yes, and MUC/Sub. Everyone does his thing because there's a strong demand and we don't get done with MIX.

  406. nicolas.verite has joined

  407. Holger

    > it doesn't take very much to fix MUC-PMs though. I'm all for your 0280 updates.

  408. Holger

    + PM tagging.

  409. Ge0rG

    Yay! \o/

  410. Ge0rG

    Why is &xep0249; creating both a note and a hyperlink?

  411. edhelas has left

  412. Tobias

    so if you print the document you got still all the useful information

  413. dwd has left

  414. MattJ has joined

  415. nicolas.verite has left

  416. Ge0rG

    updated https://op-co.de/tmp/xep-0280.html#which-messages - must return to work now

  417. nicolas.verite has joined

  418. Kev has left

  419. Steve Kille has left

  420. xnyhps has left

  421. xnyhps has left

  422. MattJ has left

  423. xnyhps has left

  424. tim@boese-ban.de has joined

  425. MattJ has joined

  426. uc has joined

  427. kaboom has joined

  428. mancho has left

  429. suzyo has left

  430. suzyo has joined

  431. jere has left

  432. jere has joined

  433. mancho has left

  434. Kev has left

  435. nicolas.verite has left

  436. Zash has left

  437. tim@boese-ban.de has joined

  438. vurpo has left

  439. vurpo has joined

  440. waqas has joined

  441. suzyo has left

  442. suzyo has joined

  443. Valerian has left

  444. Valerian has joined

  445. Piotr Nosek has left

  446. Valerian has left

  447. Valerian has joined

  448. Valerian has left

  449. Valerian has joined

  450. Kev has left

  451. Kev has left

  452. daniel has left

  453. daniel has joined

  454. jubalh has left

  455. Sonny has left

  456. jere has joined

  457. Tobias has left

  458. mancho has joined

  459. mancho has left

  460. mancho has joined

  461. Mancho has joined

  462. Mancho has left

  463. mancho has joined

  464. mancho has left

  465. mancho has joined

  466. efrit has joined

  467. mancho has left

  468. Mancho has joined

  469. Mancho has left

  470. Mancho has joined

  471. jere has joined

  472. Yagiza has left

  473. mancho has joined

  474. Yagiza has joined

  475. Flow has joined

  476. winfried has left

  477. jonasw has left

  478. mancho has left

  479. nicolas.verite has joined

  480. vurpo has left

  481. Steve Kille has joined

  482. vurpo has joined

  483. Mancho has left

  484. Mancho has left

  485. ralphm has joined

  486. Valerian has left

  487. Valerian has joined

  488. Mancho has left

  489. jcbrand has left

  490. Mancho has left

  491. nicolas.verite has left

  492. Kev has left

  493. Ge0rG

    Phew, just made it with #434 before the LC ends.

  494. Bunneh

    Ge0rG: XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section #434 https://github.com/xsf/xeps/pull/434

  495. vurpo has left

  496. vurpo has joined

  497. sezuan has left

  498. lloydwatkin has joined

  499. dwd

    Ge0rG, Raise it on the mailing list, please.

  500. Ge0rG

    dwd: sure thing

  501. Valerian has left

  502. Ge0rG

    dwd: raised.

  503. Steve Kille has left

  504. Guus has left

  505. ralphm has left

  506. jubalh has left

  507. jere has left

  508. jere has joined

  509. Guus has left

  510. Guus has joined

  511. vurpo has left

  512. vurpo has joined

  513. pep. has left

  514. xnyhps has left

  515. ralphm

    Hey all, I won't be able to attend today's Board meeting.

  516. Ge0rG

    ralphm: you won't miss anything, last week's board meeting is still ongoing :D

  517. Mancho has left

  518. jcbrand has joined

  519. jubalh has left

  520. ralphm has left

  521. vurpo has left

  522. vurpo has joined

  523. Valerian has joined

  524. nyco

    Ge0rG, :-p

  525. nyco

    the longest one ever

  526. Zash

    I've noticed that many topics consists of an |-separated list.

  527. Zash

    Some of the items are often key-values

  528. dwd

    Zash, I did argue that Subject ought to be dropped in MIX because it's never used as a subject; just as a set of URLs and a description.

  529. Zash

    dwd: So it could be derived from name, description, other named fields in disco

  530. jubalh has left

  531. Zash

    And you could supposedly generate a legacy topic for MUC compat (if you have that) from that as well

  532. Zash

    Maybe the actual topic should go back into each message?

  533. Zash

    Sane real time threaded UI would be .. interesting

  534. bra has left

  535. kaboom has left

  536. jonasw


  537. Lance has joined

  538. Martin

    Who's here for the board, then, excusing ralphm?

  539. nyco


  540. Sonny has joined

  541. Sonny has joined

  542. Steve Kille has joined

  543. Martin

    Think that might be a bit *too* quiet…

  544. nyco


  545. Martin

    MattJ: Are you around?

  546. dwd

    3/5 for quorum, BTW.

  547. kalkin has left

  548. Martin

    Thought as much

  549. Sonny has joined

  550. nyco

    so... :'(

  551. MattJ


  552. Martin

    Yeah…not looking like much of a goer really :(

  553. nyco


  554. Martin

    Oh! Signs of life.

  555. MattJ

    Sorry, another meeting overran

  556. Martin


  557. Sonny has left

  558. Martin

    Right, the Trello board looks a bit out of date. Going by the last minutes, they seem a little out of sync too, anyone got an insight into where the most current items for discussion are?

  559. vurpo has left

  560. vurpo has joined

  561. kalkin has joined

  562. Martin

    …or shall we scrub down the Trello board and start with whatever's most pressing?

  563. MattJ


  564. nyco

    there was the Summit, then GSoC, now we have space

  565. nyco


  566. Martin

    So, GSoC, still an open card on Trello

  567. nyco

    we have submitted, well Kevin has

  568. Martin

    Do we know when we're likely to hear back?

  569. Kev

    27th, IIRC

  570. MattJ

    (thanks Kev)

  571. Martin

    Thanks Kev

  572. Zash has joined

  573. nyco


  574. Martin

    OK, I've added the 27th to the Trello card

  575. Martin

    In the spirit of continuing the spring clean of the Trello board: D&0 quote, still in play?

  576. Martin

    (Board is here: https://trello.com/b/Dn6IQOu0/board-meetings )

  577. MattJ

    I guess that's a question for Peter?

  578. Martin

    Yup, his name's against it, so I'll leave it where it is for this week

  579. Sonny has joined

  580. Martin

    Moving on…Marketing project, has Arc's name against it, assuming we should leave that where it is too…?

  581. MattJ

    Guess so

  582. Martin


  583. nyco

    isn't it related to FOSDEM? in which case can be closed?

  584. Martin

    Maybe. Could also be related to the SCAM team from last week - continuing support for the marketing activity

  585. Martin

    But I guess we could archive it and create a new one for SCAM support

  586. MattJ

    According to Trello it was moved into "Commitments for the week ahead" Oct 19, 2016

  587. Martin

    That's quite a long week...

  588. Martin

    OK, I'll archive it

  589. MattJ

    So I guess we're missing, or I am at least, background on this

  590. Martin

    Yeah, me too, I'll add something to the items for discussion for next week's meeting

  591. Steve Kille has left

  592. Kev has left

  593. Martin

    OK, so, what's next...

  594. goffi has left

  595. Martin

    Recruitment of editor team members…I vaguely recall us trying to address this right at the start of the year

  596. Martin

    OK, leaving that parked for now, and we're running low on time. Board priorities for 2017. An impressive entry from nyco

  597. Kev has left

  598. MattJ

    I think new members need to come from the pool of folk already active in the community. Given the work that Sam and others have put into improving the editor team process, there is hopefully a lower barrier to entry now

  599. Kev

    The quote was for indemnity insurance for directors, so we can have a treasurer again, wasn't it?

  600. nyco

    since the board has been elected, indeed we have no goal

  601. nyco

    to me that is the most important item

  602. bra has joined

  603. nyco

    moar promotion? moar surveys? moar software? moar... what?

  604. MattJ

    nyco, your list is great. As a wishlist...

  605. nyco

    but it's partial

  606. MattJ

    It's already long :)

  607. nyco

    it is just me listening to a fraction of the community

  608. MattJ

    The main thing that needs to happen is converting it to action items

  609. nyco

    partial, in the sense that it is not neutral

  610. MattJ

    Ideally small things we can tackle, prioritized

  611. nyco

    MattJ, before actions, agreeing

  612. nyco

    yeah, and spit, get people to commit

  613. nyco

    no, no, not spit, but split!

  614. nyco


  615. MattJ

    We perhaps don't need/want to spend usual board meeting time on that, but we could find some separate time to brainstorm

  616. nyco

    agree, more interactive, and must deliver something, not just meet for the sake of meeting

  617. nyco

    it makes you think?

  618. MattJ

    I agree that everything listed would be great to have

  619. Sonny has left

  620. MattJ

    But what are the things the board can do about it?

  621. nyco


  622. nyco

    get people to commit

  623. nyco

    check on the delivery?

  624. nyco

    in other words: do something

  625. MattJ

    That's my point... what is 'something'? :)

  626. nyco

    what we will prioritise, like in priorities

  627. MattJ

    Ok, first item on that list: "Make clients look and behave like the most modern and popular chat/voice clients on the market"

  628. nyco

    let's agree on what's most important, in one, two, or three items

  629. MattJ

    How are we going to do that?

  630. jonasw

    UX sections in the XEPs? :)

  631. nyco

    one action

  632. nyco

    remove old ones from our lists

  633. nyco

    maybe through financing?

  634. nyco

    like crowfunding?

  635. MattJ

    Crowdfunding for what exactly? Where would we spend the money?

  636. nyco

    like bounties?

  637. MattJ

    Assume we already have money (because we do)

  638. MattJ

    Money isn't the issue. What do we do with it?

  639. nyco

    I'm returning all the questions to you MattJ: what is your view?

  640. MattJ


  641. nyco

    Money is one issue, it was raised at Summit

  642. nyco

    but that's only one example

  643. MattJ

    I wasn't at the summit, but I fail to see it as an issue

  644. MattJ

    Either in the amount we have, or our ability to raise more if we need (whether that's crowdfunding, sponsorship or whatever)

  645. nyco

    make clients... modern... my contrib is my market analysis, for which the outcome is "the three generations of IM"

  646. nyco

    if we want to follow that logic, then we have to deliver on full text search in archive, chatbots and chatapps, integrations, etc.

  647. nyco

    that may that the shape of XEPs, of software

  648. nyco

    MattJ, some have money issue, it is an information

  649. nyco

    so let's put money aside?

  650. MattJ

    I'm saying "we" as the XSF, to be clear

  651. nyco

    how would you "make clients modern"?

  652. nyco

    "we" can spend some, call for donations, whatever

  653. bjc has joined

  654. nyco

    but make client modern is only one of the so many items

  655. nyco

    there is more

  656. nyco

    so what are this board's priorities for this term?

  657. MattJ

    I'm personally not a client developer. However my opinion is that client developers need more UX guidelines.

  658. nyco

    sure, I agree

  659. MattJ

    But someone has to make those guidelines

  660. uc has left

  661. Kev

    I am a client developer. I'm not sure I agree.

  662. MattJ

    Great :)

  663. uc has joined

  664. nyco

    correct, that's why I say set the prios and get people to commit

  665. Kev

    But I'm certainly I don't want the same people responsible for protocol specs giving UX advice :)

  666. nyco

    Kev, you're oooold!

  667. MattJ

    Kev, as a client developer, do you agree with the overall goal/priority of "modernizing clients"?

  668. Kev

    nyco: Maybe, but that's not to say I don't think clients need better UX. I'm just not sold on them all needing the same advice.

  669. nyco


  670. daniel

    I'm a client developer. I dont need guidelines. I mean having some would be kinda nice I guess. But it's far from being a top priority

  671. ralphm has left

  672. nyco

    taht's your opinion

  673. Kev

    MattJ: I think 'modernising XMPP' is a very high priority of mine at the moment, through my software and the spec work we do.

  674. jubalh has joined

  675. nyco

    a lot of client devs are... just... dev... without any UX knowledge

  676. MattJ

    Given that daniel and Kev both produced some very nice clients, I think their opinions have weight

  677. Ge0rG

    daniel: you are a client developer who should WRITE the guidelines. Things like "DND presence from one of the user's clients overrides all other clients' presence"

  678. nyco

    so some need guidelines, maybe not advices

  679. Kev

    I think responsibility for that is shared between implementors, spec writers, Council and Board, so I'd be happy to see anyone doing sensible things.

  680. Steve Kille has joined

  681. xnyhps has left

  682. Kev

    But my idea of 'sensible things' might not be the same as others.

  683. jonasw

    daniel: +1 to Ge0rG

  684. Kev

    I'd be very keen to hear Board ideas on what they think they can do to modernise XMPP.

  685. nyco

    MattJ, I have done pretty modern clients as well, many of them, so I have weight, as experience with working with iOS/Android/web devs AND UX designers

  686. Ge0rG

    maybe we can have an Easy XMPP WG? or less-formal-group

  687. nyco

    Ge0rG, +1

  688. nyco

    so, board prios

  689. daniel

    If someone wants to take action how about supporting JC in creating inverse. That's a single page (slack like if you will) version of converse

  690. daniel

    Jc agreed to do it if he gets the funding

  691. nyco

    it is not only "modern clients", there are plenty more stuff that needs discussion

  692. nyco

    what can the board do?

  693. daniel

    The xsf could support a funding campaign

  694. Kev

    daniel: Well, sure, but if people are paying JC for work on inverse, I'd like people to pay us for work on Swift please ;)

  695. nyco


  696. Martin

    Quite, that begins to impinge on neutrality

  697. MattJ

    daniel, now that's the kind of sensible action item I'd like to see more of :)

  698. Ge0rG

    I'd like to put a shameless plug of https://wiki.xmpp.org/web/Usability/Glossary - we need to get our terminology straight before we can fix usability

  699. nyco

    Ge0rG, +1

  700. MattJ

    I'm an advocate of XSF neutrality, but the line has to be drawn somewhere

  701. daniel

    It even has like an actual price tag

  702. nyco

    promotion is certainly a huge prio

  703. nyco

    not sure if highest

  704. Kev

    If the XSF had so much money that they could pay a UX person to look at whatever clients people wanted looked at, and give advice, I'd be all for that, FWIW.

  705. nyco

    Kev, +1

  706. MattJ

    If we can't promote or sponsor good XMPP projects, I think that's somewhat sad

  707. vurpo has left

  708. vurpo has joined

  709. Martin

    MattJ: I agree, and it keeps coming up. Perhaps a board action should be to revisit what the position is on neutrality

  710. daniel

    I think we can generally agree on that a good web client is missing in the xmpp world

  711. MattJ


  712. nyco

    Martin, we had that discussion at Summit

  713. Kev

    daniel: I think so, but which of the people working on such things should get funding? :)

  714. daniel

    I mean I'm not saying it's the xsfs job to do that

  715. nyco

    so, we are still the BOARD PRIORITIES, right? ;-)

  716. Kev

    Maybe the XSF could directly pay for some liberally licensed generally useful things?

  717. daniel

    But someone wanted an actual action item. There is one

  718. Martin

    nyco: Discussions are discussions, not a decision. There's clearly still a grey area here around neutrality.

  719. nyco


  720. Kev

    Make toolboxes of things that are useful for projects. Rather than supporting a particular one directly, help them all.

  721. MattJ

    Kev, I think that would be an obvious requirement, yes (re. licensing)

  722. nyco

    but as a board, we haven't set our term's priorities

  723. Kev

    MattJ: My point was 'generally useful' vs. 'funding a particular codebase'.

  724. MattJ

    nyco, if you ask most people at the moment, we should be tackling spam instead of UX :)

  725. nyco

    MattJ, that.

  726. SamWhited

    I also would argue that spam is a higher priority. I've started getting 3 or 4 messages a day the last few days.

  727. SamWhited

    No matter how good the UX is otherwise, that would probably rather kill it.

  728. vurpo has left

  729. vurpo has joined

  730. nyco

    so, we should have a dedicated meeting on board priorities? or a big consultation? or a survey?

  731. nyco

    then we select our top thre prios, for example

  732. Kev

    Board has done a survey in some past years.

  733. Martin

    So, board-wise, we've run over, and we need to figure out how best to collate and then rank everything that's just been discussed, and others that haven't been. Polling the membership could be useful...?

  734. nyco

    and then we set goals and expectations, we put actions, and commit

  735. Kev

    I'm not sure it's directly led to action the membership wanted, but it might be a start.

  736. nyco

    some tasks can be paid...

  737. Martin

    Feels more transparent to poll the membership, and derive goals from there, rather than just super-charging anecdote

  738. xyz has left

  739. Zash has joined

  740. MattJ

    I'm fine with surveying the membership, but I don't think there will be prizes for guessing the results

  741. nyco

    at least we will have numbers

  742. Kev

    The non-client devs all say "UX", while the client devs say "resources are the problem, not UX advice"? :)

  743. nyco

    my delivery is some kind of ad-hoc survey... without weight at all: how can you trust me?

  744. MattJ

    I think let's call the official meeting over for today, but the discussion is good :)

  745. nyco

    Kev, that's a major problem to understand

  746. daniel

    Kev: that's what the poll at the summit said I think

  747. nyco

    daniel, poll? what poll?

  748. Kev

    I think if Board can find a way to fund some research into combating spim (not just coming up with specs for reporting it, but proactively detecting it), that would be probably the Board's biggest contribution in recent years.

  749. nicolas.verite has joined

  750. Kev


  751. Martin

    Yeah, board meeting is over I think, +1w for the next

  752. nicolas.verite has left

  753. daniel

    nyco: what do client developers want

  754. MattJ

    Martin, wfm

  755. Kev

    (And doesn't touch on neutrality :))

  756. Kev

    In fact (yes, I know meeting's over), I would really like Board to find something they can do in this space to advance the state of spim detection.

  757. Kev

    I know some research does exist on this.

  758. Ge0rG

    daniel: I want the XSF to buy me a yacht.

  759. Kev

    I think I have some very very smart contacts at Uni who might find this an interesting area, with funding, in fact.

  760. daniel

    I somehow can't imagine the pidgin developer sitting at home thinking 'I would really love to implement carbon copies right now. If I only had some ux guidelines'

  761. kaboom has joined

  762. nicolas.verite has joined

  763. nyco


  764. nyco

    well, not exactly, you put it like UX = UI

  765. Ge0rG

    the UX of Carbons is a tough beast.

  766. nyco

    UX can explain the "why"

  767. nicolas.verite has left

  768. Martin has left

  769. nyco

    Ge0rG, right

  770. Alex has joined

  771. nyco


  772. Arc has joined

  773. nyco

    perfect example

  774. nyco


  775. nyco

    Why do it? It cancels the fuss with the priorities for the same login on multiple devices. I keep very helpful. May assist in the development of assistance would be read chudnenko :) visit us in the conference will discuss all =)

  776. jubalh has left

  777. daniel

    nyco: a perfect example for what?

  778. nyco

    of misunderstanding

  779. nyco

    something that explain the value of an evolved user experience

  780. nyco

    clearly the guys of Psi+ want to stay in the ICQ era

  781. Steve Kille has left

  782. vurpo has left

  783. nyco

    all the priorities usage have changed, the world has changed, and continues to change, faster and faster

  784. Ge0rG

    nyco: we don't need to make _all_ XMPP clients _modern_. But we should give candy to the ones that are.

  785. nyco

    we talk

  786. MattJ

    nyco, I use a console client, and you won't take it away from me

  787. nyco

    about multi-device now, same stuff in real time in all devices (Carbons, MAM)

  788. daniel

    nyco: I don't see where the psi+ developer said that they want to be more like icq?

  789. Arc

    I love you guys. Seriously.. it puts a smile on my face whenever I open this chat

  790. vurpo has joined

  791. Arc


  792. nyco

    oh a board member who is veeery late! ;-)

  793. Arc

    yea my phone died, im not getting alerts

  794. Arc

    im hoping the new battery arriving today fixes it.

  795. Yagiza has left

  796. Arc

    beautifully, it shit the bed while helping me navigate through London to have open source beer at a bar basically located in an alley with some gnome developers. that was fun.

  797. MattJ

    Ok, my considered proposal is this: that we (the XSF) provide a process through which XMPP software developers can submit proposals for funding projects

  798. Kev

    MattJ: Please consider my comment on spim, too, that was very very serious.

  799. Kev

    But I think what you say sounds sensible too.

  800. MattJ

    Details can be hashed out, we could even put proposals to a full membership vote if we feel that's the fairest option

  801. MattJ

    Sure, but any pointers on that?

  802. Ge0rG

    does the XSF have sufficient money to establish such a funding process?

  803. MattJ

    I'm not aware of any research into combatting spim, but it sounds like you might be?

  804. Zash

    what sayeth?

  805. Ge0rG

    MattJ: 1. solve spim. 2. profit!

  806. Arc

    MattJ: I think before we do that, we should get involved in something like Outreachy

  807. nyco

    I suggest not only one prio

  808. Guus has left

  809. Guus has joined

  810. Kev

    MattJ: I'm sure I came across some before, ages ago, but if there's serious interest in the XSF funding such a thing, I think I might have some contacts I could at least ping and discuss.

  811. Kev

    If Board wanted me to.

  812. vurpo has left

  813. vurpo has joined

  814. Arc


  815. MattJ

    nyco, this would become a vehicle through which to turn your wishlist from that card into reality. We can use the priorities when deciding what to fund/not fund, and we can encourage software developers to apply, etc.

  816. nyco

    not only funding, maybe it is not only a prio

  817. nyco

    apparently spim is

  818. nyco

    "make clients more modern" may not even go through funding

  819. Zash

    Make things more better!

  820. MattJ

    nyco, "make clients more modern" is not a fundable project

  821. Ge0rG

    we could pay the spim senders to stop spimming.

  822. nyco

    MattJ, it could be

  823. nyco

    MattJ, fund inverse, swift, conversations...

  824. MattJ

    Well I'm not going to advocate funding it :)

  825. Kev has left

  826. Kev has left

  827. Zash

    Ge0rG: I'll send you an invoice for not sending you spim then.

  828. MattJ

    nyco, you're missing the *actionable* part

  829. Kev has joined

  830. MattJ

    There seems to be a disconnect between "make the clients more modern" and someone actually having to write code

  831. Ge0rG

    Zash: to the XSF

  832. nyco

    MattJ, it's not only about code

  833. MattJ

    If you want to put together a proposal for someone professional to review the UX of one or more clients, that would be great

  834. Ge0rG

    MattJ: that void must be filled with: a) help the developers understand UX problems b) provide UX guidelines c) do the coding

  835. Ge0rG

    professional UX review should be somewhere between b and c

  836. nyco

    Ge0rG, oh no, no, no, UX is much wider than that

  837. MattJ

    Kev, ok, I'll kick it into the next board meeting's topics

  838. Kev


  839. Kev

    Board may have other ideas on how to help with Spim, but this seems like a discussion point.

  840. nyco

    Kev, agree with anti-spim initiative being one of the top prios... not the only one though!

  841. Kev

    Sure :)

  842. Ge0rG

    nyco: we can't solve all UX problems. we need to learn crawling before we can grow wings.

  843. nyco

    Ge0rG, there are lots of shortcuts

  844. MattJ

    Arc, is Outreachy similar to GSoC? or would individual projects apply?

  845. Ge0rG

    nyco: like jumping from a skyscraper?

  846. MattJ

    Arc, I think programs like that are worth it in their own right, and not a substitute for funding developers who are already intimately familiar with XMPP

  847. MattJ

    i.e. these would be on parallel tracks

  848. suzyo has left

  849. Arc

    MattJ: I agree that developers should be funded, but I don't think its the XSF's role to do that. Outreachy, perhaps.

  850. Arc

    I'm concerned by the XSF's lack of diversity

  851. Kev has left

  852. MattJ

    Then likewise, come up with some action items

  853. nicolas.verite has joined

  854. Arc

    MattJ: I'm not 100% certain how projects get into Outreachy, but I know who to talk to about that. Its more formal than GSoC in some ways (they're actually considered employees/interns), but more human in others

  855. MattJ

    employees/interns of Outreachy?

  856. Arc

    well Outreachy is one way to address it. Its only available to minorities; women, LGBT, and in the USA racial minorities (black, hispanic, etc). That allows it to get grants

  857. Arc

    MattJ: yes. because they really want to help those minorities not only get work experience but also a formal work history

  858. Arc

    a vast majority of Outreachy interns are women.

  859. MattJ

    That works better, because most projects (possibly including the XSF) would not be set up for handling employees

  860. Arc

    well, yes. we could of course. we have an EIN. but yea i dont think we're prepared to do the rest

  861. Arc

    I'm currently establishing an employer an the process is pretty deep

  862. Zash has left

  863. MattJ

    SamWhited, any insight into what happened with the PR I submitted? git was acting weird (which IMHO is fairly normal for git)

  864. MattJ

    I'm just curious what went wrong

  865. Alex has left

  866. SamWhited

    Git was fine, you just included commits from the previous 0.6 version that weren't actually used in master (eg. You based your branch on an old branch)

  867. Arc

    btw what do we have these days IRT modern XMPP client C libraries?

  868. MattJ

    Oh, you squashed the commits when you merged my previous PR?

  869. Mancho has left

  870. SamWhited


  871. nicolas.verite has left

  872. nicolas.verite has joined

  873. MattJ


  874. MattJ goes to the corner

  875. SamWhited

    Master is always canonical in our repo

  876. SamWhited

    Or the source of truth, or whatever

  877. SamWhited

    It's not a big deal, I just rebased your new branch too

  878. MattJ

    In any repo I have say over, the whole repo is a source of truth, but I know that's not the way many git users, or github, feel

  879. Ge0rG

    MattJ: your DVCS is inferior! stop arguing! :D

  880. MattJ

    I'll be more careful next time

  881. nicolas.verite has left

  882. SamWhited

    Actually, even if the while repo was the source of truth, you must have based it on an old commit

  883. nicolas.verite has joined

  884. SamWhited

    Because the conflict was the two <initials>

  885. MattJ

    Before I pushed git was acting weird, asking me to merge stuff that didn't make sense

  886. Ge0rG

    hg does that to me all the time. And then there is this crazy text editor with three different window-things

  887. nicolas.verite has left

  888. winfried has left

  889. goffi has left

  890. MattJ

    I'm convinced that some people just have a mental model suited to git, and some hg, and that's that

  891. goffi has left

  892. Arc

    you like hg too?

  893. waqas

    Some people like emacs. Some like vim. Then there is the rest of the planet.

  894. Lance has left

  895. Tobias

    who doesn't like hg, it just has superior usability

  896. Arc


  897. SamWhited

    I disagree; I know how to use both, and I think HG is much less usable.

  898. Ge0rG

    Tobias: hg has horrible usability. It is mockig me every time I try to use it.

  899. Ge0rG


  900. Zash


  901. Tobias

    i mostly use git through a GUI so I don't things up, which was quite easy to do a couple years ago

  902. waqas

    Yeah, CLIs have terrible usability for git

  903. waqas

    Or hg

  904. Zash

    MattJ: So they rewrote/rebased commits you published?

  905. MattJ

    Zash, yes. It's a checkbox in the Github UI iirc

  906. SamWhited

    I don't recall if I did or not, but I probably did

  907. Tobias

    waqas, sure..but even at CLI level i find hg more usable than git, but hey...either can interoperate with both repos, so hey

  908. Zash

    The data model is basically the same too

  909. Ge0rG

    my pet peeve with hg is "hg pull" which tells me it knows what I want but it won't do it and go RTFM

  910. Zash

    Ge0rG: Didn't you say fetch?

  911. Ge0rG

    Zash: ah, yes. it was 'fetch'

  912. Ge0rG

    It's been a long day, and my train is arriving in 10 minutes. Good night everyone :)

  913. vurpo has left

  914. vurpo has joined

  915. Zash

    `hg fetch` is some deprecated plugin that sounds like it does what `git pull` does.

  916. Arc

    again, anyone know of a modern XMPP client library for C?

  917. Zash

    But there's `hg pull --{update,merge,rebase}`

  918. Tobias

    libstrophe, but it's probably not modern

  919. Ge0rG

    C is not modern.

  920. Zash

    Define modern

  921. Alex has joined

  922. Arc

    it has a maintainer, work has been done on it in the last 12 months, supports session management and MAM

  923. Arc

    the list on xmpp.org includes mostly dead projects

  924. Ge0rG

    Didn't we define a process to kill dead projects from the list?

  925. Arc

    i didnt make it to this week's meeting, but last i knew we asked Council for 2017 guidelines

  926. Arc

    hmm, maybe I'll go for Rust this time. I'm starting a new commercial project, has to be portable.

  927. dwd has left

  928. Ge0rG

    But the 2017 guidelines are not going to solve the dead projects problem

  929. dwd has left

  930. jubalh has joined

  931. Arc

    Ge0rG: my proposal was to have projects re-apply, and ask them for modern compliance information

  932. Arc

    so we need the 2017 guidelines to start that process

  933. Tobias

    wasn't the consensus to just have them reapply yearly, but accept any XMPP, regardless of compliance?

  934. Arc

    Tobias: yes, but compliance information is important to ask and report still.

  935. Ge0rG

    Arc: can't we just have the projects reapply?

  936. Arc

    nobody said they wouldn't be listed if they didn't comply.

  937. Zash

    inactive projects could be sorted lower and lower down

  938. Ge0rG

    Arc: but now the process is blocked until a new set of guidelines is defined

  939. kaboom has left

  940. Arc

    Ge0rG: it can't be that hard for council...

  941. Arc

    2016 guidelines, whats new?

  942. SamWhited

    I love Rust, but beware: I think it's still 3 years out or so from having enough library/community/infrastructure support to be usable for complex commercial products. YMMV

  943. kalkin has left

  944. Ge0rG

    Arc: 2016 guidelines are neither finished nor implementable

  945. kalkin has joined

  946. Ge0rG

    Can we please just start a dead projects grace period now?

  947. Arc

    im not opposed to that

  948. Ge0rG

    Somebody needs to post to jdev then.

  949. vurpo has left

  950. Alex has left

  951. Ge0rG

    We are still in the eternal board meeting btw

  952. sezuan has left

  953. MattJ

    How many?

  954. Tobias

    MattJ, how many what?

  955. MattJ

    Open meetings

  956. Arc

    did the board meeting not happen this week?

  957. Arc

    I saw some trello cards got managed

  958. Arc

    SamWhited: well, its portable now. I understand what you're saying

  959. nicolas.verite has joined

  960. kalkin has left

  961. Arc

    LoudMouth is dead. My fork of it needs to pivot, it was going more glib/gobject but that lacks portability, and the asm.js for gobject stuff is effectively dead

  962. nicolas.verite has left

  963. SamWhited

    I thought gobject/glib was supposed to be super portable these days? (I'm curious, because I don't actually know, someone just told me this recently)

  964. Arc

    i could ease back into coding for the next week by refactoring into Rust

  965. Arc

    SamWhited: its not portable to asm.js/webasm nor to mobile. i wish it was. it was suppose to be.

  966. Mancho has left

  967. jonasw has left

  968. SamWhited

    ah, right

  969. Arc

    I've invested a lot of energy into Vala, but the Gnome foundation at this point is pivoting away from that and to Rust.

  970. Arc

    that's why I grabbed a beer with the gnome guys in London

  971. SamWhited

    I never did understand the point of Vala

  972. Arc

    back when I started Maja looked very promising

  973. nicolas.verite has joined

  974. Arc

    Vala was intended to be a GObject-native language. and it is, it works great. But its tied to GObject/Gnome.

  975. SamWhited

    yah, having such a domain specific language felt pointless to me; no matter how nice it was.

  976. Arc

    like much of Gnome it lacks the developer interest to really shine. even basic things like llvm support are still years off

  977. Arc

    i just browsed around, Rust seems to lack a decent xmpp client library.

  978. Arc

    I could spend about a week to refactor all of lightmelody into rust

  979. SamWhited

    Link Mauve sent me one recently; I haven't looked at it to see if it's "decent" or not yet though.

  980. SamWhited

    Can't remember where it is right now

  981. Link Mauve


  982. nicolas.verite has left

  983. Arc

    Can I use it yet? No, there's still a lot of work that needs to be done before this could be used for anything.

  984. Arc


  985. Link Mauve

    It’s very much wip, you may want to talk to lumi in jdev@ about it.

  986. Arc

    so, yea I'll be spending the next week refactoring lightmelody.

  987. jcbrand has left

  988. Link Mauve

    He started it right after FOSDEM.

  989. Arc

    no its ok. this kinda needs to happen anyway

  990. nicolas.verite has joined

  991. Link Mauve

    Arc, your website seems down.

  992. Arc

    doing a rust refactoring is more about me than anything. i need something to keep from being bored right now, and im still on doctor ordered break until the end of the month. refactoring and learning rust should be low impact

  993. Arc

    Link Mauve: what website

  994. xyz has joined

  995. Link Mauve


  996. Arc

    oh there's no website there, just a landing page

  997. Arc

    also it looks like the old server is down. i should actually do the migration today instead

  998. Arc

    as soon as the new battery arrives from amazon this afternoon i'll call in and get it rebooted

  999. Arc

    Link Mauve: lightmelody vs loudmouth.. goal is to be 100% api compatible with loudmouth 1.4, but shedding all the old dependencies. so eg it uses gio instead of gnet. it also adds OAuth2 auth (gsoc student project last year) and a few other key features

  1000. Arc

    loudmouth is usable, just bitrotten. too many outdated dependencies.

  1001. Arc

    there's a lot of software that still uses loudmouth, including some surprising ones like random games on Steam

  1002. Link Mauve

    That sounds useful!

  1003. nicolas.verite has left

  1004. Arc

    there's an up-side; if i port it to Rust, we can solve the one API variance to loudmouth 1.4 which is the LM_Message_Type which overlaps with gobject's builtin "type" method of lm.message

  1005. Arc

    it can still expose the same C API.

  1006. Arc

    that way it could ALSO offer a Rust API.

  1007. Steve Kille has joined

  1008. Kev has joined

  1009. winfried has left

  1010. nicolas.verite has joined

  1011. suzyo has joined

  1012. Kev has left

  1013. kalkin has joined

  1014. jere has joined

  1015. uc has left

  1016. kaboom has joined

  1017. jubalh has left

  1018. Zash has joined

  1019. dwd has left

  1020. Tobias

    somebody with pelican knowledge here?

  1021. dwd has left

  1022. goffi has joined

  1023. xyz has left

  1024. Steve Kille has left

  1025. Tobias has left

  1026. kalkin has left

  1027. dwd has left

  1028. kalkin has joined

  1029. dwd has left

  1030. mathieui

    I use it

  1031. Valerian has left

  1032. Valerian has joined

  1033. mathieui

    not sure if that counts as knowledge

  1034. Guus

    in the land of the blind, the one-eyed man is king.

  1035. Tobias

    regarding our client/library/server lists, I wonder how you'd handle data tables in dedicated files and filter them at build time

  1036. Tobias has joined

  1037. jcbrand has joined

  1038. Zash has joined

  1039. mathieui

    Tobias, probably a special anchor that gets replaced through sed… I don’t think rST supports inclusion of other file

  1040. mathieui

    there’s a PR to add some markdown syntax for this

  1041. Tobias

    yeah..we already use SED to insert the XEP list

  1042. Tobias

    makes you wonder why use pelican at all :)

  1043. Zash

    pandoc all the things

  1044. peter has joined

  1045. Lance has joined

  1046. Steve Kille has joined

  1047. Kev has joined

  1048. mathieui

    better use xslt for everything

  1049. Zash

    pandoc -t json | jq . | pandoc -t whateveryouwant

  1050. vurpo has left

  1051. Tobias

    yeah..back to the beginning with XSLT + Server side includes

  1052. Tobias


  1053. Tobias

    the happy world

  1054. Valerian has left

  1055. suzyo has left

  1056. Valerian has joined

  1057. suzyo has joined

  1058. kaboom has left

  1059. Kev has left

  1060. Kev has joined

  1061. nicolas.verite has left

  1062. jcbrand has left

  1063. Valerian has left

  1064. Steve Kille has left

  1065. Valerian has joined

  1066. Lance has left

  1067. uc has joined

  1068. goffi has left

  1069. Vinilox has left

  1070. uc has left

  1071. Lance has left

  1072. Kev has left

  1073. Valerian has left

  1074. Steve Kille has joined

  1075. uc has joined

  1076. uc has left

  1077. moparisthebest has joined

  1078. Valerian has joined

  1079. Alex has joined

  1080. Lance has left

  1081. kaboom has joined

  1082. Steve Kille has left

  1083. Lance has left

  1084. Melvin has joined

  1085. uc has joined

  1086. sezuan has left

  1087. Valerian has left

  1088. Alex has left

  1089. uc has left

  1090. Alex has joined

  1091. peter has left

  1092. nicolas.verite has joined

  1093. Kev has joined

  1094. uc has joined

  1095. Guus has left

  1096. Valerian has joined

  1097. Valerian has left

  1098. uc has left

  1099. Piotr Nosek has joined

  1100. Alex has left

  1101. Zash has joined

  1102. Kev has left

  1103. suzyo has left

  1104. suzyo has joined

  1105. blipp has joined

  1106. Melvin has left

  1107. blipp has joined

  1108. daniel has left

  1109. Steve Kille has joined

  1110. uc has joined

  1111. vurpo has left

  1112. vurpo has left

  1113. uc has left

  1114. vurpo has joined

  1115. suzyo has left

  1116. suzyo has joined

  1117. uc has joined

  1118. mimi89999 has left

  1119. Kev has left

  1120. mimi89999 has joined

  1121. bjc has left

  1122. bjc has joined

  1123. uc has left

  1124. tim@boese-ban.de has joined

  1125. uc has joined

  1126. suzyo has left

  1127. efrit has left

  1128. efrit has joined

  1129. daniel has left

  1130. efrit has joined

  1131. efrit has joined