XSF Discussion - 2017-12-07

  1. ralphm has joined
  2. moparisthebest has joined
  3. moparisthebest has joined
  4. efrit has left
  5. marc has left
  6. zinid has left
  7. lskdjf has joined
  8. Ge0rG has left
  9. Ge0rG has left
  10. Ge0rG has left
  11. jjrh has left
  12. jjrh has left
  13. 0000 has joined
  14. Ge0rG has left
  15. Ge0rG has left
  16. Ge0rG has left
  17. Guus has left
  18. Guus has joined
  19. tux has left
  20. tux has joined
  21. uc has joined
  22. jjrh has left
  23. jjrh has left
  24. Tobias has joined
  25. Lance has joined
  26. Lance has left
  27. Tobias has joined
  28. Ge0rG has left
  29. arc has left
  30. arc has joined
  31. arc has left
  32. arc has joined
  33. arc has left
  34. arc has joined
  35. zinid has joined
  36. zinid has left
  37. ralphm has left
  38. arc has left
  39. ralphm has joined
  40. arc has joined
  41. zinid has joined
  42. zinid has left
  43. uc has joined
  44. @Alacer has left
  45. @Alacer has joined
  46. efrit has joined
  47. Syndace has left
  48. Syndace has joined
  49. @Alacer has left
  50. @Alacer has joined
  51. zinid has joined
  52. zinid has left
  53. efrit has left
  54. zinid has joined
  55. zinid has left
  56. la|r|ma has joined
  57. la|r|ma has joined
  58. Ge0rG has left
  59. uc has joined
  60. mimi89999 has joined
  61. mimi89999 has left
  62. mimi89999 has joined
  63. uc has joined
  64. arc has left
  65. arc has joined
  66. arc has left
  67. arc has joined
  68. zinid has joined
  69. @Alacer has left
  70. @Alacer has joined
  71. lskdjf has joined
  72. @Alacer has left
  73. @Alacer has joined
  74. arc has left
  75. arc has joined
  76. ralphm has left
  77. jjrh has left
  78. ralphm has joined
  79. ralphm has joined
  80. 0000 has left
  81. zinid has left
  82. moparisthebest has joined
  83. jjrh has left
  84. valo has left
  85. valo has joined
  86. @Alacer has left
  87. @Alacer has joined
  88. daniel has left
  89. daniel has joined
  90. ralphm has joined
  91. sonny has left
  92. sonny has joined
  93. sonny has joined
  94. sonny has joined
  95. @Alacer has left
  96. @Alacer has joined
  97. marc has joined
  98. 0000 has joined
  99. ralphm has joined
  100. Kev jonasw: I said previous that the motivation xep1 gave for reissuing LCs is for outgoing Council. I came up with some motivations of my own in response to your mail. I don't think that was inconsistent :)
  101. jonasw Kev, as I said (at least in one of my drafts), I think that is fine.
  102. jonasw I’m still not entirely sure how your original argument actually applies, but it doesn’t matter now, since I find your current argument fully convincing.
  103. Kev The point I'm making is that it wasn't my original argument, it's the one in xep1 and at that time I didn't bother coming up with any of my own (until you mail asked to)
  104. Kev I think my current arguments are stronger than the one xep1 makes, but I would.
  105. jonasw oh, I didn’t realise that the argument is literally from XEP1
  106. jonasw I was sure that I read something along the lines of (from you) "I think the original reasoning back then was ..."
  107. Kev "The motivation in xep1 is ..."
  108. jonasw damn
  109. jonasw sorry
  110. jonasw I didn’t have my coffee yet
  111. daniel has left
  112. jonasw (I can always make that excuse, I never drink coffee)
  113. jonasw but I also didn’t have my water yet, which is probably worse
  114. Kev But I would be amazed if anyone not on Council does the level of review that Council should do.
  115. SouL jonasw, same here haha
  116. Kev (Indeed, the questions that the Editors ask them to during LC don't come close)
  117. ralphm has joined
  118. jonasw I found your review of the compliance suite very thorough by the way, that’s way beyond what I as a developer would be doing.
  119. Kev That's roughly the point I'm making - I would expect, for a compliance suite review buy Council, them to have gone through everything in the suite and checked if it's sensible, checked if anything not in the list needs to be, and checked that the list is consistent. For non-compliance suites I'd expect Council to do much more review than that - for non trivial XEPs I expect Council are probably spending an hour+ per advancing XEP to review properly. I really wouldn't expect non-Council to be putting that sort of work in.
  120. Ge0rG Kev: can't we solve the bookmarks issue by requiring servers to transparently synchronize both storage formats?
  121. jonasw Ge0rG, that’s an interesting idea
  122. Kev Ge0rG: I think 'requiring' might be hard here, but we could add a server feature to 48 that does that, I think, yes. And I think we could do so without bumping namespaces or worrying about it being Draft, due to it being a new server-only feature for a XEP that previously wasn't server.
  123. daniel has left
  124. edhelas Bookmark need to be changed, first have atomic bookmarks
  125. jonasw if it’s announced by a feature, I don’t see any reason not to, draft or not, previously server side or not
  126. Ge0rG edhelas: no need to go nuclear!
  127. edhelas eheh
  128. edhelas no but we have PEP, and multi-items tags now
  129. jonasw edhelas, in spec, yes
  130. edhelas I'd like, in 2017, to be able to solve a bookmark in a PEP-Pubsub item
  131. jonasw in deployment mmmm
  132. jonasw edhelas, I have bad news for you.
  133. Kev Bookmarks are atomic at the moment, no?
  134. edhelas no they aren't
  135. jonasw Kev, but not very fine grained
  136. Kev Pretty sure they are. It's a single payload.
  137. edhelas you just save the whole list in an item, so you have race condition issues
  138. Kev Race condition issues doesn't make it non-atomic :)
  139. jonasw Kev, you know about the issues though, don’t you?
  140. edhelas I'd love to have a bookmark XEP that works like this one https://xmpp.org/extensions/xep-0330.html#usecases
  141. jonasw aioxmpp has a weird read-modify-write loop up to three times or until convergence, whicever happens first
  142. Kev edhelas: In the sense of one bookmark per item?
  143. edhelas Kev Yes!
  144. jonasw we’re not entirly sure it ever converges even if everybody does that algorithm, but it should.
  145. Kev I think that would be fairly sensible, in a world where bookmarks weren't based on iq:private primarily, yes.
  146. daniel has left
  147. daniel has joined
  148. jonasw yah, a server would have to implement that read-modify-write loop then :)
  149. edhelas Zash what is the status of multi-items in Pubsub/PEP nodes in Prosody
  150. Ge0rG See, XMPP is all about database update synchronization.
  151. jonasw edhelas, you should first ask what the status of private and persistent pep is ....
  152. Kev I think that the publish-only-if-the-parent-state-is-right XEP would do the job too (for something not frequently changing).
  153. edhelas jonasw persistence is there in ejabberd and Prosody now afaik
  154. jonasw atomic compare-and-publish for pubsub, Kev? :)
  155. intosi jonasw: M-Link's is excellent as well ;)
  156. jonasw edhelas, is it though? I thought only with a community module.
  157. jonasw anyways, I wanted to go for errands like an hour ago. the XSF is eating my time!!k
  158. 0000 has left
  159. daniel has left
  160. Steve Kille has left
  161. Steve Kille has left
  162. Steve Kille has joined
  163. daniel has left
  164. daniel has left
  165. Martin has joined
  166. Steve Kille has left
  167. jere has left
  168. jere has joined
  169. daniel has left
  170. Martin has left
  171. daniel has left
  172. daniel has left
  173. sonny has left
  174. lskdjf has left
  175. mimi89999 has left
  176. jubalh has joined
  177. ralphm has joined
  178. daniel has left
  179. daniel has left
  180. daniel has joined
  181. goffi has joined
  182. Ge0rG has left
  183. Ge0rG has left
  184. jonasw SamWhited, what’s the status about the XEP-393 update? I’m still missing the opt-out and a formal grammar…
  185. jonasw (or opt-in, even better)
  186. lumi has joined
  187. matlag has joined
  188. Zash has left
  189. Zash has left
  190. Zash has joined
  191. ralphm has left
  192. Ge0rG has left
  193. zinid has left
  194. ralphm has joined
  195. daniel has left
  196. daniel has left
  197. zinid has left
  198. daniel has left
  199. daniel has left
  200. daniel has joined
  201. Tobias has left
  202. la|r|ma has joined
  203. arc has left
  204. arc has joined
  205. la|r|ma has left
  206. la|r|ma has joined
  207. ralphm has joined
  208. valo has left
  209. valo has joined
  210. ralphm has joined
  211. goffi has left
  212. georg has joined
  213. goffi has left
  214. Guus has left
  215. goffi has joined
  216. jere has joined
  217. stefandxm has left
  218. Ge0rG has left
  219. Guus has left
  220. la|r|ma has joined
  221. georg has left
  222. Tobias has joined
  223. goffi has left
  224. zinid has left
  225. ralphm has joined
  226. stefandxm has joined
  227. lskdjf has joined
  228. zinid has left
  229. daniel has left
  230. daniel has joined
  231. Ge0rG has left
  232. nyco has left
  233. nyco has joined
  234. sonny has joined
  235. Guus I've just added a notification to the XSF Board meeting calendar item, that's on the XSF shared agenda. Could someone please make sure that Google doesn't do something stupid like adding that notification to everyone's agenda?
  236. Guus I've set it to 11 minutes, just to make it slightly different from the default.
  237. SamWhited jonasw: I'm not sure that we're adding an opt out yet. A football grammar seems fine, if unnecessary, but it's not something I'm going to spend time doing right away
  238. jonasw menh
  239. jonasw I see absolutely no reason not to add an opt-out, to be honest.
  240. SamWhited *formal, even
  241. Kev I liked the idea of you writing a football grammar. Let me have that, please.
  242. jonasw I thought that football grammer is a nickname for some type of grammar representation :)
  243. Ge0rG Kev: do you mean a soccer grammar?
  244. SamWhited This will be a Liverpool F.C. grammar (if kev can live with that), so definitely "football"
  245. Ge0rG But they are playing soccer?
  246. SamWhited No, Atlanta United plays soccer, Liverpool plays football.
  247. Ge0rG Ah, but they are playing the same game, right?
  248. vanitasvitae has left
  249. vanitasvitae has joined
  250. SamWhited Yes, sorry, I'm fine stretching this joke out now
  251. SamWhited Done, even. I hate phones.
  252. jonasw we all do
  253. Martin has joined
  254. marc has left
  255. MattJ waves
  256. Martin *wave*
  257. Guus performs an acrobatic manouvre.
  258. ralphm bangs gavel
  259. ralphm 0. Welcome & Agenda
  260. ralphm Hi! Who do we have?
  261. Martin I’m here
  262. MattJ I'm here
  263. Guus I'm here
  264. ralphm nyco?
  265. ralphm set the topic to XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings
  266. Guus He might be attending POSS
  267. Guus (an event in Paris that he previously expressed interest in)
  268. ralphm Ah, yes.
  269. mathieui he is (or was yesterday, where I saw him)
  270. ralphm Anyone have something for the agenda?
  271. Guus I've added things to Trello last week
  272. Guus apart from those, none.
  273. MattJ I don't think I have anything to add right now
  274. ralphm Ok
  275. Martin Nothing from me
  276. ralphm Who can take minutes?
  277. Martin I’m mobile, so not really in a position to, sorry :(
  278. Guus if no-one outside board members is available, I'll do it.
  279. ralphm 1. D&O insurance
  280. Guus I've talked to Peter. His full response is in Trello.
  281. Guus basically: if board still wants to move forward with this, he will. But he estimates it'll be not cheap.
  282. ralphm Given his response, and no current (potential) officers asking for it right now, let's close this for now
  283. Guus Aren't we asking for this?
  284. Martin Do we know/remember why we started down this path in the first place?
  285. Martin (I’m happy to close it, fwiw, just curious as to why this has hung around for some long)
  286. Martin *so long
  287. Guus if it's a cheap way to help us protect from being financially pressured into doing something, I'd be in favor of getting an insurance.
  288. ralphm Guus: I'm not asking for insurance, no.
  289. Kev has left
  290. Guus Martin: it was put up by Laura, April 4, 2016.
  291. ralphm I'm also not entirely sure who this will work out with people in Europe.
  292. MattJ From what I can piece together, in 2015 there was a search for a new Treasurer, and the only applicant raised concerns about liability - I don't know if this is what triggered it
  293. ralphm Martin: well, somebody brought it up, stpeter would investigate, that was delayed a bit, everybody lost interest.
  294. Guus given that we've not been financially pressured in the past ... 18 years? ... might be a non-issue.
  295. ralphm The Foundation is not that old yet, but sure
  296. Guus I know it's dead-cheap in the Netherlands, but liability laws are vastly different here.
  297. ralphm Right. I'm not even sure if a Dutch insurance would work with a Delaware company.
  298. Guus but if I'm the only one interested, i'm happy to let this go.
  299. ralphm If you want to investigate that, that's fine of course.
  300. Guus Matt, Martin?
  301. Martin I’m happy to let it go
  302. ralphm Ok, archiving.
  303. ralphm 2. Commitments
  304. Guus I'll let Peter know.
  305. ralphm I saw that we asked and can reconfirm our Treasurer and Secretary for another year.
  306. MattJ Sorry, laggy here. I'm happy to pass on the insurance. But I think we'd need actual quotes to make a concrete decision (more than "it's expensive")
  307. Guus indeed, both Alex and Peter are happy to take on their roles another year. Do we need nyco to make it official?
  308. ralphm So I motion we appoint Alexander Gnauck as Secretary for another term.
  309. Guus +1
  310. Martin +1
  311. Martin +1
  312. Martin has left
  313. Martin has joined
  314. ralphm Done.
  315. Martin +1
  316. MattJ +1
  317. ralphm I motion we appoint Peter Saint-André as Treasurer for another term.
  318. MattJ +1
  319. Guus +1
  320. Martin +!
  321. Martin *+1
  322. ralphm Done
  323. Guus Can we have some kind of thank-you for the work they've been doing so far?
  324. ralphm I think we have to postpone appointing the Chair again.
  325. ralphm Guus: please note this in the minutes, indeed
  326. ralphm FWIW, I'm happy to continue.
  327. ralphm I just hope that nyco can attend next meeting so we can finish this.
  328. Guus At some point, it'd like to address unscheduled non-attendence.
  329. ralphm I haven't yet acted on finding a new ED, so let's keep that one.
  330. ralphm Guus: right, I did send that message to the Board list for a reason.
  331. Guus Yes, thanks for that.
  332. Guus but it did not help, sadly.
  333. ralphm Moving on
  334. ralphm 3. Items for discussion
  335. ralphm We only have a few minutes left.
  336. ralphm Given the post-meeting discussion, unless there's disagreement, I'd like to remove the SPIM item for discussion at Board level right now, until there's a more actionably proposal.
  337. MattJ wfm
  338. Guus that works for me.
  339. Martin Fine by me
  340. Guus I'd like to discuss board prio's with all present, but it wouldn't hurt for all of us to prepare by adding their own thoughts.
  341. Guus (as a commitment for the week ahead).
  342. ralphm Guus: +1
  343. MattJ +1
  344. Martin Sounds like a plan
  345. ralphm Added a card
  346. Guus potential survey is based on that discussion, I think.
  347. ralphm Agreed
  348. ralphm That leaves us with the new card on FOSDEM sponsorship.
  349. ralphm I think this is an interesting topic, that deserves a bit more than 3 minutes
  350. Guus (I'm good for another 10 minutes or so)
  351. MattJ +1. I'm in favour of it generally, but I think we need a broader discussion on financing and fundraising
  352. MattJ We're really bad at both, and I think it's something we need to improve on
  353. ralphm MattJ: can you create a card to that effect?
  354. MattJ Sure
  355. ralphm I propose we then pick that up next week
  356. ralphm also given the short time until FOSDEM
  357. ralphm 4. AOB
  358. ralphm I didn't see anything for this raised today
  359. Martin None from me
  360. ralphm 5. Time of Next
  361. Guus SCAM should get into gear for FOSDEM/SUMMIT
  362. ralphm +1W
  363. ralphm Guus: agreed
  364. ralphm The confirmation for stands has been extended
  365. Guus +1W works for me.
  366. MattJ +1W wfm
  367. Martin +1W works for me too
  368. ralphm I.e. I didn't get it yet because they are slow
  369. ralphm 6. Close
  370. ralphm Thanks all!
  371. ralphm bangs gavel
  372. Martin *wave*
  373. MattJ Thanks
  374. ralphm set the topic to XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings
  375. Ge0rG So what can we do to improve the SPIM situation?
  376. Guus Ge0rG: stop searching for silver bullets.
  377. Guus I feel that to many proposals get shot down because "that won't fix the problem"
  378. Guus (in general, not by you specifically)
  379. Guus many partial solutions will at least help. Currently, we're not making any progress.
  380. lovetox has joined
  381. Martin has left
  382. moparisthebest well mainly because there are no silver bullets
  383. moparisthebest if there was a perfect solution for spam, email people would have found it years ago, probably before xmpp became a thing
  384. Guus agreed.
  385. lovetox Just to add to the Last Call XEP-0387 discussion, because im to lazy now to post to the list
  386. moparisthebest solutions should fall neatly in 2 categories: 1. That won't help at all. 2. That might help for a little bit
  387. Ge0rG deleted around 1000 spammer accounts in the last 24h.
  388. jonasw obligatory link: https://craphound.com/spamsolutions.txt
  389. Ge0rG lovetox: don't be lazy. Not everyone is reading this MUC
  390. lovetox SamWhited, it seems you are not aware that 0048 on pubsub is not supported by prosody or ejabbered as of right now, so recommending that is a bit over optimistic
  391. jonasw lovetox, not even ejabberd? I thought ejabberd can do that
  392. lovetox only one server to my knowledge
  393. lovetox that conversations server, because holger added it
  394. lovetox i dont know if this has landed in the community version of ejabbered
  395. lovetox but i doubt it
  396. moparisthebest haha jonasw never saw that, thanks :)
  397. lovetox and even if, this still is a feature then that only one server in its newest version supports, still not something that should recommended, we strife for good interop with the compliance suite
  398. Ge0rG lovetox: that was discussed on standards@ I think. Or at least in the last council minutes
  399. lovetox no, the argument revolved around what clients actually use
  400. lovetox and yes of course all clients use private storage
  401. edhelas nope
  402. lovetox but even if not, we cannot recommend something that is not supported by servers
  403. edhelas Movim relies on private PEP node for Bookmarks, only that
  404. lovetox compliance is here so we have good interop between clients and servers
  405. Ge0rG edhelas: Movim also doesn't work on my server :(
  406. lovetox not to promote next level features
  407. edhelas Ge0rG Prosody ?
  408. jonasw lovetox, remember that people wanted to have MIX in there
  409. Ge0rG lovetox: https://github.com/xsf/xeps/pull/554
  410. Ge0rG edhelas: yeah
  411. edhelas Ge0rG soon :)
  412. jonasw lovetox, I think the actual debate is whether we want the compliance suites to be something which describes what we want to have soon or what is now
  413. jonasw I think SamWhited wants them to be a description of what we want to have.
  414. lovetox in my opinion it should reflect something that is good right now
  415. SamWhited I don't actually understand that discussion; both of them support bookmarks in PEP just fine. Do you mean the persistence thing?
  416. lovetox not what we hope will happen sometimes in the future
  417. edhelas ping Zash
  418. lovetox SamWhited, they dont, they are not supporting 223
  419. lovetox this means all bookmarks are open world readable
  420. lovetox which is not something that we want
  421. lovetox maybe the xep doesnt require it strictly but it should
  422. Zash ENOCTX
  423. lovetox i dont know the wording anymore
  424. lovetox and also this is the reason why nobody really wants to implement this
  425. Ge0rG Zash: bookmarks in PEP
  426. lovetox if gajim gets bookmarks over pep, we test if the server supports 223 fully, if not, we purge the pep node
  427. lovetox and transfer bookmarks to private storage
  428. Zash Not yet
  429. jonasw lovetox, <3
  430. jonasw good job :)
  431. jonasw SamWhited, if you count "bookmarks in PEP work until the next server reboot" as "working", I think we might have a problem.
  432. Zash We've got persistence but access control isn't configurable yet
  433. jonasw SamWhited, if you count "bookmarks in PEP work until the next server reboot, then they’re gone" as "working", I think we might have a problem.
  434. jonasw SamWhited, if you count "bookmarks in PEP work until the next server reboot and are also world-readable, then they’re gone" as "working", I think we might have a problem.
  435. SamWhited fair enough
  436. edhelas Zash access_control is the last missing thing to move Bookmarks to PEP in Prosody ?
  437. lovetox persistence is one thing, support of access_model = whiteliste, the real important one
  438. SamWhited Either way, servers more or less support them and I think we want to encourage that support to be better and document what servers need to give a good experience, not just document what everything is already doing
  439. edhelas SamWhited +1
  440. SamWhited I was pretty sure they already supported private nodes though, but I guess not?
  441. Zash edhelas: No idea
  442. jonasw SamWhited, fair enough
  443. jonasw I think the main mis-understanding is then whether the suites should document the current real deployment or the future. there seems to be disagreement on that.
  444. lovetox SamWhited, private nodes are supported sometimes
  445. lovetox but often whats missing is the <publish-options> feature
  446. jonasw SamWhited, maybe add a paragraph to this in the introduction, making this absolutely clear (even though I think that the introduction -- which I haven’t read until now, admittedly -- makes it quite clear already that the suites are meant to advance, not do describe)
  447. lovetox that lets the client discover this whithout pulling the whole node config
  448. lovetox pulling node config in turn is also not supported by all server
  449. zinid lovetox, it's missing because there are problems with xdata definition
  450. Kev has left
  451. Ge0rG dwd: which MUA are you using? The plaintext quoting it generates doesn't make it possible to distinguish what you wrote from what you are responding to.
  452. jonasw TIL how to force kmail to show a multipart/alternative message as html even though it contains a text/plain part.
  453. jonasw I find it ironic that the HTML message contains *foo* by the way.
  454. stefandxm has left
  455. stefandxm has joined
  456. ralphm has left
  457. ralphm has joined
  458. ralphm has left
  459. lskdjf has left
  460. tux has joined
  461. stefandxm has left
  462. jonasw SamWhited, XEP-0001 has a minimum of 14 days. I hate that.
  463. SamWhited It has had 14 days of LC already, after that it's up to the editor
  464. SamWhited Or at least, that's how I've been treating it. First one is 2 weeks, after that I've done 1 week LCs for lots of things
  465. jonasw hm, sure, but a re-issuance after council switch?
  466. jonasw I’m seeing this in light of Kevins argument
  467. jonasw which I found much more convincing than the argument in XEP-0001 by the way
  468. jubalh has left
  469. SamWhited I still don't see what the council switch has to do with anything; they'll still have plenty of time to review it.
  470. ralphm has joined
  471. zinid has left
  472. efrit has joined
  473. ralphm has left
  474. ralphm has joined
  475. Holger has left
  476. moparisthebest I just want to know what kind of crappy council member would not comment on a last call on the list and only in the meeting...
  477. moparisthebest I'm not sure I care about their input in that case
  478. ralphm has joined
  479. Kev I think the compliance suites documenting what you need to be a sensible server/client in the current climate, with an eye to the future, is sensible.
  480. lskdjf has joined
  481. Kev So if you currently need to implement X in order to interop with large amounts of the network, we can probably put it in on that basis. Similarly if something isn't well deployed but is stable and the clear direction, we can put it in for that reason.
  482. Kev MIX is a direction, but not stable, so I think putting that in would be wrong.
  483. Kev But '49 is widely needed for interop, so I think we list that.
  484. Zash Maybe the compliance suites should be split into two documents. One that's an implementation report, documenting what most implementations do now. Other is more like a vision statement, describing what we want XMPP to be like in the near(?) future.
  485. Kev I think a vision statement might be a sensible thing, but I don't think it needs to be dated like the compliance suites, which are snapshots of what we expect people to implement at that time.
  486. Zash Kev: It would be tho, it'd be "what we think the future should look like, as of $today"
  487. Kev Yes, but we can keep that updated, there's no particular value in stamping it and calling it done.
  488. Zash Maybe numbered semi-immutable documents aren't optimal for that purpose
  489. arc has left
  490. arc has joined
  491. Zash But it'd be cool to have something of a history of what we thought the future would look like
  492. arc has left
  493. Zash Useful for comparing later, to see which, if any, goals we got anywhere with
  494. Kev I think we'd probably have that just through the attic and the changelog.
  495. Zash I suppose
  496. Zash Could be a blog entry, the exact form is probably not that important
  497. Zash Having a vision is good tho.
  498. Kev Anyway, that is very much not a hill for me to die on - but I think a single living direction document would do just fine.
  499. Zash As is knowing the current state of things
  500. Kev I do think it's worth stamping a date on the compliance suites, which are meant to be "What do I need to implement right now" sort of things.
  501. Zash Which is sorta inbetween.
  502. Zash The IETF used to have implementation reports of some kind IIRC
  503. arc has joined
  504. zinid has left
  505. efrit has left
  506. fippo zash: that didn't work
  507. jubalh has joined
  508. Syndace has joined
  509. Syndace has joined
  510. sonny has left
  511. sonny has joined
  512. nyco has left
  513. zinid has left
  514. jubalh has left
  515. nyco has joined
  516. ralphm has joined
  517. jjrh has left
  518. zinid has left
  519. Ge0rG has left
  520. stefandxm has joined
  521. zinid has left
  522. waqas has joined
  523. Holger > it seems you are not aware that 0048 on pubsub is not supported by prosody or ejabbered lovetox: You mean because of the use of publish-options?
  524. Holger I think strictly speaking the use of pubsub#persist_items in the 0048 example isn't 0060-compatible, because 0060 says that publish options MUST be registered or rejected by the server, and this one isn't.
  525. Holger ... isn't registered.
  526. ralphm has left
  527. uc has left
  528. daniel Holger: i have it on my todo list to register that publish option
  529. Holger daniel: Ok. FWIW I think it would make sense to just specify that arbitrary node config options can be specified as publish options and that they will always be handled as preconditions.
  530. jjrh has left
  531. jubalh has joined
  532. daniel i agree
  533. daniel it's probably impossible to get that through council
  534. daniel my last change to xep60 took me a 6 month to push through
  535. Holger Though the result would be equivalent to registering each and every node config option as a publish option to be handled as precondition.
  536. uc has joined
  537. Ge0rG has joined
  538. jjrh has left
  539. stefandxm has left
  540. Ge0rG has left
  541. daniel if I change the wording to something like 'any unregistered publish-option must be treated as a precondtion to the node configuartion option of the same name or reject if neither a registered publish option nor a registered node configuartion exists" the already existing entry in the publish-options registry is obsolete
  542. daniel and should probably be deleted in order to not confuse people with an already very confusing XEP
  543. arc has left
  544. arc has joined
  545. ralphm has joined
  546. arc has left
  547. arc has joined
  548. jonasw daniel, FWIW, I think your idea is sensible, and in case of doubt this could always be made a feature (#publish-options-config-precondition) or something
  549. daniel at some point the xsf will need an archaeologist to dig up why certain decisions to certain xeps where made in the past
  550. jonasw I wish those things would be documented properly.
  551. jubalh has left
  552. daniel has left
  553. Ge0rG Every XEP should contain a strong rationale for surprising decisions.
  554. nyco has left
  555. daniel Holger, jonasw: if you word it that way you are essentially kissing 'per item overwrite' goodby
  556. daniel which i'm not necessarly opposed to
  557. jonasw daniel, how?
  558. nyco has joined
  559. daniel well if you say that any publish options that shares the same name with a node config is a precondtion; how would you create a per item override that shares the same name
  560. Zash Would have been easier if it the three kinds of things weren't in the same form
  561. daniel i guess you can still register that with a different name
  562. jonasw what is a per-item override?
  563. daniel Zash yes
  564. daniel jonasw, read the XEP we are talking about
  565. jonasw I have, but it’s been a while :/
  566. daniel jonasw, i don't really know myself :-)
  567. Zash jonasw: What it sounds like.
  568. Zash jonasw: Node configuration overrides per item.
  569. daniel 7.1.5 Publishing Options <- just read that
  570. jonasw Zash, at first I thought "per item override" is something abou treplacing existing items, but that didn’t make sense
  571. jonasw is it setting options per item?
  572. jonasw ahh
  573. jonasw okay
  574. jonasw that sounds ill-defined as heck
  575. Zash And unused afaik
  576. daniel no shit
  577. jonasw I personally don’t have a problem with burning that :)
  578. daniel per item override or the entire xep?
  579. jonasw not that I would matter :)
  580. Zash Per-item access control is a desirable feature tho
  581. jonasw Zash, is it?
  582. jonasw hm, maybe for the social network things
  583. jonasw meh
  584. Ge0rG has left
  585. daniel the path of least resistance is to register persist-items as a precondition and move on with our lives
  586. zinid has left
  587. daniel has left
  588. Ge0rG has left
  589. Guus has left
  590. Holger > Holger, jonasw: if you word it that way you are essentially kissing 'per item overwrite' goodby Sounds good to me :-)
  591. Steve Kille has left
  592. Holger > the path of least resistance is to register persist-items as a precondition and move on with our lives Yup, works for me as well.
  593. jubalh has joined
  594. Ge0rG has joined
  595. vanitasvitae has left
  596. vanitasvitae has joined
  597. Guus has left
  598. Steve Kille has joined
  599. nyco has left
  600. daniel has left
  601. stefandxm has joined
  602. nyco has joined
  603. ralphm has joined
  604. jubalh has left
  605. Ge0rG has joined
  606. sonny has left
  607. sonny has joined
  608. sonny has left
  609. sonny has joined
  610. Ge0rG has joined
  611. Ge0rG has left
  612. sonny has joined
  613. sonny has joined
  614. daniel has left
  615. sonny has left
  616. sonny has joined
  617. sonny has left
  618. sonny has joined
  619. Guus has left
  620. sonny has left
  621. sonny has joined
  622. @Alacer has left
  623. waqas has left
  624. sonny has left
  625. sonny has joined
  626. sonny has left
  627. @Alacer has joined
  628. Ge0rG has joined
  629. sonny has joined
  630. Guus has left
  631. daniel created both https://github.com/xsf/xeps/pull/556 https://github.com/xsf/xeps/pull/555
  632. daniel feedback on the wording in 556 welcome
  633. daniel has left
  634. debacle has joined
  635. debacle has left
  636. debacle has joined
  637. Guus has left
  638. Holger has left
  639. arc has left
  640. arc has joined
  641. uc has joined
  642. uc has joined
  643. Ge0rG has joined
  644. valo has left
  645. valo has joined
  646. @Alacer has left
  647. @Alacer has joined
  648. ralphm has joined
  649. ralphm has joined
  650. moparisthebest has joined
  651. sonny has left
  652. sonny has joined
  653. daniel has left
  654. zinid has left
  655. Ge0rG has left
  656. daniel has left
  657. sonny has left
  658. arc has left
  659. arc has joined
  660. zinid has left
  661. sonny has joined
  662. zinid has left
  663. debacle has left
  664. arc has left
  665. arc has joined
  666. daniel has left
  667. daniel has joined
  668. ralphm has joined
  669. arc has left
  670. arc has joined
  671. stefandxm has left
  672. Tobias has left
  673. jubalh has joined
  674. lumi has left
  675. daniel has left
  676. sonny has left
  677. sonny has joined
  678. ralphm has joined
  679. jonasw has left
  680. jubalh has left
  681. nyco has left
  682. nyco has joined
  683. ralphm has left
  684. stefandxm has joined
  685. Tobias has joined
  686. ralphm has joined
  687. stefandxm has left
  688. lskdjf has left
  689. daniel has left
  690. pep. has left
  691. ralphm has joined
  692. daniel has left
  693. stefandxm has joined
  694. ralphm has joined
  695. ralphm has left
  696. daniel has left
  697. daniel has left
  698. jonasw has left
  699. daniel has left
  700. daniel has left
  701. jubalh has joined
  702. daniel has left
  703. lskdjf has left
  704. ralphm has joined
  705. moparisthebest has joined
  706. daniel has left
  707. zinid has joined
  708. goffi has joined
  709. Guus has left
  710. jubalh has joined
  711. marc has left
  712. marc has left
  713. jubalh has left
  714. zinid has left
  715. arc has left
  716. arc has joined
  717. Zash has left
  718. jubalh has joined
  719. jjrh has left
  720. jjrh has left
  721. SamWhited has left
  722. jjrh has left
  723. jubalh has left
  724. lskdjf has left
  725. tux has left
  726. arc has left
  727. arc has joined
  728. arc has left
  729. arc has joined