XSF Discussion - 2019-08-01

  1. patrick has left
  2. zach has left
  3. zach has joined
  4. remko has joined
  5. stpeter has joined
  6. peter has joined
  7. debacle has left
  8. Douglas Terabyte has joined
  9. pdurbin has joined
  10. remko has left
  11. Wojtek has left
  12. Lance has joined
  13. peter has left
  14. pdurbin has left
  15. LNJ has left
  16. zach has left
  17. zach has joined
  18. stpeter has left
  19. remko has joined
  20. lskdjf has left
  21. waqas has left
  22. stpeter has joined
  23. peter has joined
  24. zach has left
  25. zach has joined
  26. remko has left
  27. neshtaxmpp has left
  28. neshtaxmpp has joined
  29. Chobbes has left
  30. LNJ has joined
  31. zach has left
  32. zach has joined
  33. peter has left
  34. peter has joined
  35. peter has left
  36. wurstsalat has left
  37. stpeter has left
  38. adityaborikar has left
  39. adityaborikar has joined
  40. Yagiza has joined
  41. sezuan has joined
  42. andy has joined
  43. sezuan has left
  44. zach has left
  45. zach has joined
  46. remko has joined
  47. pdurbin has joined
  48. pdurbin has left
  49. pdurbin has joined
  50. LNJ has left
  51. remko has left
  52. zach has left
  53. zach has joined
  54. Lance has left
  55. zach has left
  56. zach has joined
  57. matlag has left
  58. matlag has joined
  59. mimi89999 has left
  60. mimi89999 has joined
  61. valo has left
  62. eve has left
  63. eve has joined
  64. valo has joined
  65. pdurbin has left
  66. pdurbin has joined
  67. adityaborikar has left
  68. adityaborikar has joined
  69. lovetox has joined
  70. zach has left
  71. zach has joined
  72. karoshi has joined
  73. pdurbin has left
  74. pdurbin has joined
  75. alameyo has left
  76. alameyo has joined
  77. zach has left
  78. zach has joined
  79. wurstsalat has joined
  80. APach has left
  81. zach has left
  82. zach has joined
  83. larma has left
  84. pdurbin has left
  85. larma has joined
  86. pdurbin has joined
  87. zach has left
  88. zach has joined
  89. pdurbin has left
  90. pdurbin has joined
  91. Mikaela has joined
  92. sezuan has joined
  93. zach has left
  94. zach has joined
  95. remko has joined
  96. rion has left
  97. rion has joined
  98. zach has left
  99. zach has joined
  100. igoose has left
  101. igoose has joined
  102. remko has left
  103. Mikaela has left
  104. Mikaela has joined
  105. zach has left
  106. zach has joined
  107. Nekit has joined
  108. winfried has left
  109. pdurbin has left
  110. winfried has joined
  111. david has left
  112. david has joined
  113. david has left
  114. david has joined
  115. adityaborikar has left
  116. adityaborikar has joined
  117. APach has joined
  118. pdurbin has joined
  119. marc_ has left
  120. lorddavidiii has joined
  121. zach has left
  122. zach has joined
  123. LNJ has joined
  124. pdurbin has left
  125. pdurbin has joined
  126. marc_ has joined
  127. marc_ has left
  128. marc_ has joined
  129. marc_ has left
  130. marc_ has joined
  131. lorddavidiii has left
  132. LNJ has left
  133. zach has left
  134. zach has joined
  135. remko has joined
  136. lskdjf has joined
  137. lskdjf has left
  138. lskdjf has joined
  139. zach has left
  140. zach has joined
  141. Dele (Mobile) has joined
  142. Dele (Mobile) has left
  143. remko has left
  144. zach has left
  145. zach has joined
  146. LNJ has joined
  147. zach has left
  148. zach has joined
  149. LNJ has left
  150. LNJ has joined
  151. lovetox hm about MUC exiting a room
  152. zach has left
  153. zach has joined
  154. lovetox say im sending a join presence to the room, and before the room sends me the roster i send a unavailable presence
  155. lovetox should the server still send the roster?
  156. lovetox can i leave a room when im not fully joined?
  157. lovetox is probably the question
  158. lumi has joined
  159. eevvoor has joined
  160. Holger lovetox: You can of course send the unavailable presence before being "fully joined", but must expect traffic from the room until you got the unavailable response back.
  161. lovetox yeah i know that the server probably queues the presences before he receives my unavailable and can not remove presences from the queue in time
  162. lovetox but does ejabberd even try?
  163. debacle has joined
  164. lovetox i think about this, because when entering a room with a captcha
  165. lovetox server sends no roster until captcha is solved
  166. lovetox so it should respect my unavailable if i cancel the captcha challend
  167. Holger If I understand you correctly then the answer is no. ejabberd just receives requests and responds to them. You want it to double check whether there's another request before responding to the first one? That would seem wrong to me.
  168. lovetox so it should respect my unavailable if i cancel the captcha challenge
  169. Holger Ahh, so the story is kinda different.
  170. lovetox ejabberd does not respect unavailable within a captcha flow, also not captcha canel message
  171. lovetox instead it has a 1 minute timer
  172. lovetox that sneds a presence error when the captcha is not solved in that time
  173. lovetox but i wonder if i should care ..
  174. lovetox i dont think it causes any problems ..
  175. lumi has left
  176. Holger lovetox: Shouldn't the client abort the CAPTCHA thing as per XEP-0158, in that case?
  177. Holger > The sender's client MUST respond with a <not-acceptable/> error in any of the following cases: [...] if the sender declines the challenge
  178. lovetox i do this, but as i said above, it does not have any effect on ejabberd
  179. Holger Ah "also not captcha cancel message", overlooked that.
  180. lovetox what i would expect is, after cancel to get a presence error type=auth or something
  181. Holger Yeah that sounds wrong to me.
  182. Holger Yup.
  183. Holger Who does room CAPTCHAs anyway ;-)
  184. lovetox yeah so now i get the presence error 40 seconds later because it runs into the timeout
  185. Holger But yes maybe post an issue if you're motivated ...
  186. lovetox i dont see any problem getting it later though
  187. lovetox i dont see how that delayed error would cause any problem
  188. zach has left
  189. zach has joined
  190. lovetox its basically a nitpick at this point :)
  191. Holger Yup but I guess you're right.
  192. murabito has left
  193. murabito has joined
  194. lumi has joined
  195. igoose has left
  196. igoose has joined
  197. goffi has joined
  198. Ge0rG First I was thinking about the ugly workaround where you send a presence-unavailable _right before_ you join the MUC, to make the server realize that you acutally are joining it and not just updating your existing presence.
  199. Holger XMPP at its best.
  200. Link Mauve Holger, that’s been fixed, but some servers still don’t implement MUC 1.29. :(
  201. Link Mauve Damn, two years ago already.
  202. Ge0rG no servers implement Carbons 0.13
  203. Kev Well, in fact XEP-0045 was always written that way.
  204. Ge0rG Life is sad.
  205. Kev Just that 1.29 made it clearer.
  206. Kev Ge0rG: I have a server implementation, including the extra namespace.
  207. Ge0rG Kev: is it public?
  208. Kev No, it'll appear in a future M-Link release, it's not released yet.
  209. Holger Ge0rG: Oh I missed that. I'll add that to ejabberd.
  210. Ge0rG Kev: will that release be running on jabber.org? :D
  211. Kev Not unless Peter changes his mind :)
  212. Ge0rG Holger: would you come with pitchforks and torches if I also mandate forwarding of message errors?
  213. Ge0rG BTW, I'd like to make message errors non-ephemeral in general, so that they end up in MAM and in Carbons.
  214. Ge0rG are server developers going to kill me for that?
  215. Holger Right, I was going to mention that the rules for MAM + Carbons should be in sync for such things, otherwise I wouldn't quite see the point.
  216. eevvoor has left
  217. Ge0rG Holger: I've been asking that for years now
  218. Holger Other than that I tend to be on the "store everything" side of the fence, so I for one won't kill you. Plus you live too far away now anyway.
  219. Holger Ge0rG: I know. It's not like I objected ;-)
  220. Ge0rG > it is of type "error" and it was sent in response to a <message/> that was eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).
  221. Ge0rG Holger: this part of the new 0280 rules was heavily objected
  222. Holger Ge0rG: I mean for some things there are probably better solutions than cluttering the DB. But cluttering is better than what we have now.
  223. Ge0rG It's generally not forbidden to CC _every_ message error, and I'm not even sure it would be harmful
  224. goffi has left
  225. zach has left
  226. zach has joined
  227. zach has left
  228. zach has joined
  229. Ge0rG CCing message errors from a MUC might be interesting, though.
  230. adityaborikar has left
  231. adityaborikar has joined
  232. rion has left
  233. rion has joined
  234. eevvoor has joined
  235. Holger Indeed.
  236. adityaborikar has left
  237. marc_ has left
  238. marc_ has joined
  239. sezuan has left
  240. sezuan has joined
  241. goffi has joined
  242. goffi has left
  243. goffi has joined
  244. goffi has left
  245. goffi has joined
  246. Chobbes has joined
  247. sezuan has left
  248. sezuan has joined
  249. sezuan has left
  250. sezuan has joined
  251. goffi has left
  252. goffi has joined
  253. alameyo has left
  254. alameyo has joined
  255. eevvoor has left
  256. stpeter has joined
  257. alameyo has left
  258. Guus has left
  259. stpeter has left
  260. eve has left
  261. eve has joined
  262. Guus has joined
  263. alameyo has joined
  264. zach has left
  265. adityaborikar has joined
  266. eevvoor has joined
  267. eevvoor has left
  268. Lance has joined
  269. Chobbes has left
  270. adityaborikar has left
  271. adityaborikar has joined
  272. ralphm I'm on the road, but will try to follow the board meeting
  273. stpeter has joined
  274. Lance has left
  275. MattJ o/
  276. Seve Hi MattJ
  277. MattJ Guus?
  278. Guus here!
  279. MattJ Does someone else want to chair? I'd like to unvolunteer myself this week if that's ok
  280. Guus Seve, you want to have a go?
  281. Guus is @nyco not here?
  282. MattJ Apparently not
  283. Guus Seve?
  284. Guus reaches for the gavel....
  285. Seve Sorry :)
  286. Seve I'm fully back now
  287. Guus please act as our chair if you want to. 🙂
  288. Seve Let's go
  289. Seve Welcome
  290. MattJ <3 Seve
  291. Seve I guess it's three of us, MattJ, Guus and me
  292. goffi has left
  293. Guus with Ralph on the backburner.
  294. Seve Do you have something to add to the agenda?
  295. Guus I don't have anything to add ot the agenda.
  296. Seve 1. Minute taker Any volunteers? :)
  297. Steve Kille has joined
  298. MattJ Nothing here (not sure if Peter's financials email is a worthy topic?)
  299. MattJ I can minute
  300. Seve That's awesome, thanks MattJ !
  301. Seve Nothing to discuss from me on that topic at least
  302. Guus I don't have anything to discuss on Peters email, other than "thank you Peter for the update."
  303. Seve Indeed
  304. Guus I'd be happy to discuss it if others feel there's soemthign to be discussed.
  305. Guus I sense that's not the case though? 🙂
  306. Seve Doesn't look like. If not, we can always take it again or via email
  307. Seve 2. Commitments
  308. Seve "Follow-up on feedback & create poll for Compliance Suite Badges"
  309. Seve Being Nyco away, I guess we can skip this one for now
  310. Steve Kille has left
  311. MattJ wfm
  312. Nekit has left
  313. Seve "Review of Roadmap page" Ralph mentioned he would send an e-mail to Council, but since he is also half/half, we will have to skip this one as well, as there are no any other news on this
  314. Seve as far as I know
  315. peter has joined
  316. Guus (Did you skip the 'topics for decisions' lane on purpose?)
  317. Steve Kille has joined
  318. Steve Kille has left
  319. Seve Yes, since they were both away :)
  320. Seve Now let's move onto
  321. Seve 3. Topics for decisions
  322. Guus ah ok 🙂
  323. Seve "Vote on https://github.com/xsf/xmpp.org/pull/588" The pull request was resolved, but we wanted to discuss about the "underlaying" issue, is that right, Guus? :)
  324. Guus right
  325. Seve There were some things to clarify, if I remember correctly. Or at least MattJ and me had some doubts about what were we going to vote on.
  326. MattJ Right :)
  327. Seve Do we want to clarify this and vote on the next meeting with the rest of the Board?
  328. Guus I'd prefer to do it now.
  329. Guus we have quorum, and we're not being very effective as-is.
  330. Ge0rG the question was, who should be responsible for evaluating non-maintainer updates to the lists
  331. Ge0rG Board or Editors.
  332. Guus I think we phrased that as "Should non-maintainers be allowed to ask for a project listing renewal?"
  333. Ge0rG Guus: this is a misleading question. Everyone can ask something.
  334. Guus Ge0rG - I thnk you're asking a different question.
  335. pdurbin has left
  336. Ge0rG Guus: the relevant question is what process happens if a non-maintainer asks.
  337. MattJ No, I think Ge0rG is asking a very slightly different but actually strongly-linked question which is the most relevant one here
  338. Guus I'd like to avoid having different processes, based on who authored the PR.
  339. MattJ I'm fine with that, it doesn't necessarily mean there have to be two processes
  340. Ge0rG Guus: in that case, the relevant question is, how is the process supposed to work if *anybody* asks for renewal
  341. Ge0rG the status quo is: editors reject if a non-maintainer asks, accept if a maintainer asks.
  342. Guus that's not the status quo
  343. Ge0rG or maybe: editors escalate to Board if a non-maintainer asks, accept if a maintainer asks.
  344. peter has left
  345. Ge0rG Guus: that was the status quo I tried to establish, I obviously can't know how it is lived by the Editors.
  346. Guus I'm not an editor, yet do much (most?) of the website PR merging.
  347. Ge0rG what is the right term then?
  348. Guus There's a lack of a specific role, other than "who-ever has been granted the power to merge" by a process that, as far as I know, non-existing.
  349. waqas has joined
  350. Ge0rG "web team"?
  351. Seve If it is a matter of checking the projects being renewed or introduced, I don't mind volunteering for that.
  352. MattJ I don't know if we're entirely clear on what "checking" means, are we?
  353. MattJ which is part of the problem
  354. Guus The github team that appears to have that power is 'web', so 'web-team' works for me - although the term implies that this is a XSF workgroup, which I don't think it is
  355. Seve MattJ, exactly
  356. Guus I strongly feel that we're making to much of this.
  357. Guus I want to steer away of all of this complexity.
  358. MattJ I think we have three options: 1) accept all requests 2) accept requests based on some objective criteria we can assess 3) just decide on a case-by-case basis
  359. MattJ and I think everyone currently has different notions of what the ideal and the status quo are from this list
  360. Guus Agreed.
  361. Guus also: the definition of what is ideal is not something we'll agree upon, without much more discussion, I fear.
  362. MattJ we == Board, or we == community (Ge0rG)? :)
  363. Seve I would go for option 3, that gives us a way to keep understanding what to do :)
  364. Guus The more, the merrier 😃
  365. jubalh has joined
  366. Guus In option 3, who does the deciding?
  367. jubalh Cisco jabber = XMPP? Or were there changes ?
  368. MattJ Well, it's currently us, it seems
  369. Seve I would say Board until something is cleared out
  370. Guus (basically, the 'web-team' now does that, which effectively has the outcome of option 1)
  371. jubalh I'm getting a bugreport from a user using Cisco Jabber server. And wonder whether the server could actually be the reason
  372. waqas Do we have a well-defined purpose of the list (I'm just opening the page to see if we have something on top, but its taking forever for the server to respond)?
  373. waqas Ah, timed out with "504 Gateway Time-out"
  374. Guus jubalh mind postponing that until after the board meeting?
  375. jubalh oh so sorry
  376. MattJ jubalh, we are currently in a meeting which will end soon - maybe ask in jdev@conference.jabber.org or wait for a bit :)
  377. jubalh I'll wait
  378. Guus thanks
  379. MattJ waqas, I think we pretty much all agree that the old list was terrible by all metrics
  380. Ge0rG I'm for 2) with the objective criterion being "the PR author claims to be a maintainer of the project"
  381. MattJ So the goal we can all agree on was weeding out unmaintained software from the list
  382. Guus I'd not be to happy with board to have to decide on every change / renewal request.
  383. Seve What if we allow everybody to ask for renewal, and I contact maintainers of each project to ask for confirmation? If this helps us moving on :)
  384. Guus I'm not seeing with what the 'maintainer' requirement does for the quality of the list - other than prevent others from changing (mostly improving) it.
  385. Seve Although I would love maintainers care of it enough to appear on the list instead
  386. MattJ I'd love to just move to Link Mauve's magic DOAP project in the near future, when it's ready
  387. MattJ Which is something to consider - even manual validation may only be a short-term thing
  388. Ge0rG Guus: others "improving" the list leads to sub-par clients becoming visible
  389. Guus Ge0rG yes. Overall, it'd still be an improved list though.
  390. Ge0rG Guus: we've had pidgin, astrachat and empathy on that list
  391. Ge0rG Guus: not improved in comparison to the process that web-team isn't adhering to
  392. Guus "improved enough" for me though.
  393. Guus All other overhead is frankly not worth it, in my opinion.
  394. MattJ I propose the following: web team auto-accepts if maintainership can be verified, defers to Board if it can't
  395. Ge0rG Guus: Seve just volunteered to take over the overhead. I'd do so too.
  396. Guus I think we've sufficiently exchanged the same arguments for two weeks now though 🙂
  397. MattJ and long term, we replace it with an automatic solution
  398. Ge0rG Speaking of overhead: it _is_ a significant overhead for a user to install a sub-par client, and to only later realize that it's not working. Or even worse: not to realize it at all and blaming XMPP instead.
  399. MattJ As much as I'd like to trust in people being sensible, it only takes one person to submit a list from Wikipedia which includes obsolete clients such as Exodus and Coccinella
  400. MattJ If we accept everything without question, it's not really curating the list in the way that we need to keep it clean
  401. Seve Exactly my thoughts
  402. Chobbes has joined
  403. Guus The list will, eventually, curate itself mostly.
  404. MattJ As nice and simple as that would be
  405. MattJ My feeling is that the majority of requests will come from obvious maintainers and take no effort to verify and merge
  406. MattJ and occasionally we'll have problematic requests that warrant a little bit of discussion (but not the amount of discussion we're dedicating to this)
  407. ralphm has left
  408. MattJ I wouldn't have wanted to turn away the recent PR we had, which clearly had quite a bit of effort put into it, even though it was non-maintainer
  409. MattJ But I also don't want to automatically accept everything just because someone submitted a PR
  410. MattJ PR doesn't automatically equal improvement
  411. Guus let's vote on this already
  412. MattJ On what exactly?
  413. Guus we're continuing to exchange the same arguments
  414. Seve We need a question to vote on first :) Which I'm not sure how to define yet
  415. MattJ > I propose the following: web team auto-accepts if maintainership can be verified, defers to Board if it can't
  416. stpeter has left
  417. MattJ How is this for starters?
  418. Seve Do you agree voting on that, Guus?
  419. Seve I'm fine with it
  420. Guus 'verified' might be a bit ambiguous.
  421. Guus but I don't have an immediate alternative wording.
  422. Ge0rG as I said, in my eyes it's sufficient to ask the PR author in the PR whether they are a project maintainer.
  423. Guus but I'm fine with the gist of it.
  424. MattJ If the web team struggles with implementing this policy, we can talk - I doubt they will :)
  425. MattJ Chair, call the vote!
  426. MattJ Why did I volunteer to minute this gnarly discussion?
  427. Seve Let's vote
  428. Seve "Web team will auto-accept client renewal requests if maintainership can be verified. Otherwise, the request will be redirected to Board."
  429. MattJ +1
  430. Seve +1
  431. Guus -1
  432. MattJ :eyeroll:
  433. Ge0rG 🍿
  434. Guus "a vote of the majority of the Directors present at a meeting in which a quorum is present shall be the act of the Board of Directors."
  435. Seve That's a green light then. Vote passes.
  436. Guus I read that as 'motion passed"
  437. Seve Yes
  438. Guus excellent. Let's move on. 🙂
  439. MattJ Amen
  440. Seve Hah :)
  441. Seve Since we have used more time than usually, do you want to stop here? I may not have more time today, unfortunately.
  442. Guus If you're leaving, we loose quorum anyways
  443. Guus so, sure.
  444. MattJ sgtm
  445. Seve Ok then
  446. Seve 4. AOB?
  447. MattJ None here
  448. Guus nope
  449. Seve 5. Date of Next
  450. Seve Next week, same time? :)
  451. Guus wfm
  452. MattJ +1
  453. Seve 6. Close
  454. Guus Thanks!
  455. Seve Thank you guys for this meeting
  456. MattJ Thanks Seve, you're a star :)
  457. Seve blushes
  458. eve has left
  459. eve has joined
  460. Seve Great to see we have come to a solution on that one
  461. Guus Yes, indeed.
  462. Guus I'd love for us to find a way to have much of these discussions outside of the scope of the meetings though
  463. Guus as they're eating up much of the meeting time.
  464. Guus which I think hurts our productivity further.
  465. Guus I'm unsure what would be an improvement. More adhoc discussions over XMPP in preparation of the meeting? More mailinglist discussions?
  466. Seve Yes, been thinking about that for a long time, I would like to use meetings for making things official, rather than actually knowing what do you guys think.
  467. MattJ I agree that would be ideal
  468. MattJ The meeting however is a good way to allocate time and focus on specific issues, ensuring we are all present for a productive discussion
  469. MattJ So I'm not sure it is easily replaced by simple votes
  470. Ge0rG allocate a second slot for discussion, on Mondays
  471. Lance has joined
  472. Chobbes has left
  473. Chobbes has joined
  474. Guus has left
  475. alameyo has left
  476. alameyo has joined
  477. Guus has joined
  478. jubalh has left
  479. pdurbin has joined
  480. Chobbes has left
  481. Chobbes has joined
  482. alameyo has left
  483. Guus has left
  484. Guus has joined
  485. alameyo has joined
  486. pdurbin has left
  487. Lance has left
  488. adityaborikar has left
  489. Lance has joined
  490. sezuan has left
  491. ralphm has joined
  492. adityaborikar has joined
  493. wojtek has joined
  494. murabito has left
  495. murabito has joined
  496. debacle has left
  497. Guus jonas’: mind testing muclumbus on conference.igniterealtime.org ?
  498. jonas’ can’t
  499. jonas’ aioxmpp.errors.XMPPCancelError: {urn:ietf:params:xml:ns:xmpp-stanzas}remote-server-not-found ('Server-to-server connection failed: Connecting failed: dh key too small')
  500. jonas’ (I could’ve sworn that igniterealtime was once indexed, so that’s why it dropped off the index)
  501. jonas’ Guus, ^
  502. Guus Hmm
  503. Guus What's the minimum requirement?
  504. Zash 2048 presumably
  505. Zash https://xmpp.net/result.php?domain=conference.igniterealtime.org&type=server
  506. jonas’ 2048 sounds realistic
  507. jonas’ I generated 4096 ones for my hosts
  508. Guus On a side note: Ignite should be using default settings for encryption, as provided by Java. I generally assume that those provide a good balance between security and interoperability.
  509. jonas’ not anymore
  510. jonas’ and, no
  511. jonas’ Java is known for not dealing well with DH key sizes ;)
  512. Zash It's the other way around, things have been accepting 1024-bit DH groups for compat with Java, but no more
  513. Zash The future seems to be ECDHE-only tho
  514. jonas’ is it openssl 1.1 or debian which requires 2048 bits now?
  515. ralphm Also I would check that Java indeed has reasonable defaults. Not an assumption I would make.
  516. Guus If we don't seem this acceptable any more, then xmpp.net scoring should be adjusted.
  517. jonas’ probably
  518. Zash Guus: " Server uses Diffie-Hellman parameters of < 2048 bits. Grade capped to B. " wasn't enough? It's been there for years
  519. jonas’ Zash, maybe it should be capped to E now?
  520. Guus B is a pretty good score
  521. Zash I think this is Debian, but IIRC the browser folks are in on it
  522. Ge0rG The good thing about Java defaults is that they depend on the JRE version you are running.
  523. wojtek has left
  524. wojtek has joined
  525. Zash https://www.debian.org/releases/stable/amd64/release-notes/ch-information.html#openssl-defaults
  526. Guus Ge0rG: Indeed.
  527. Guus We do use Java 8, I think. So that might warrant an upgrade.
  528. jonas’ hm, I should load that hack Zash has about fetching security info of s2s connections on the server and let muclumbus scrape that kind of stuff. then I would lower the requirements and show nasty warning signs next to rooms which are on insecure servers :>
  529. Guus Hehehe
  530. Guus This is sooooo different from a conversation I had with a customer not to long ago
  531. Zash jonas’: https://gist.github.com/Zash/5946686 ?
  532. Guus They insisted that the password being equal to the username was safe.
  533. jonas’ Guus, oh my god.
  534. marc_ has left
  535. jonas’ Zash, probably
  536. Guus I'll see if we can switch Ignite to Java 11. I'd be interested in finding out what that does to the encryption parameters.
  537. Guus I wonder if this accounts for the issue we've had with contacting the ChatSecure push service
  538. adityaborikar has left
  539. adityaborikar has joined
  540. sezuan has joined
  541. waqas has left
  542. waqas has joined
  543. adityaborikar has left
  544. adityaborikar has joined
  545. jonas’ given the name, not impossible
  546. sezuan has left
  547. adityaborikar has left
  548. waqas has left
  549. david has left
  550. david has joined
  551. rion has left
  552. rion has joined
  553. UsL has left
  554. Guus > (I could’ve sworn that igniterealtime was once indexed, so that’s why it dropped off the index) Without Muclumbus support?
  555. Guus jonas’: ^
  556. jonas’ Guus, uuuh
  557. jonas’ you weren’t talking about scraping igniterealtime for public MUCs, but about using the client against it
  558. jonas’ yeah, I can’t do that either with those dh keys, but at least now I know what you want from me :D
  559. Guus There aren't many rooms on that particular domainto, but I wanted to test the scraping implementation that was built.
  560. murabito has left
  561. murabito has joined
  562. jonas’ right, so, scraping with muclumbus as in search.jabbercat.org does not require server support beyond XEP-0045.
  563. jonas’ the client thing is a different matter, it scrolled of of my mind’s backlog that you were about to implement that :)
  564. jonas’ I think I have an account on yax.im, maybe I can connect using that
  565. eevvoor has joined
  566. wojtek has left
  567. jubalh has joined
  568. Guus Ah, I thought muclumbus was the scraping protocol used by jabbercat
  569. Guus Oh well. 🙂
  570. jonas’ Guus, do you have a search term for me?
  571. jonas’ where I’ll find something for sure?
  572. jonas’ the reply I got (a) is empty and (b) lacks an <rsm/> element which makes my test client crash :)
  573. jonas’ Guus, ^
  574. Guus the combination of both, or either?
  575. Guus open_chat is an existing muc name
  576. Guus searching for
  577. jonas’ combination of both
  578. Guus searching for "openfire" or "smack" should give you a result
  579. Guus You'd expect an error instead?
  580. jonas’ Guus, an empty result is fine, but with <rsm/> element
  581. jonas’ searching for open brings me bad-request
  582. jonas’ (without further error code)
  583. jonas’ same for open_chat
  584. jonas’ Guus, here’s the full interaction in scs format (no, that’s not the actual password in there): https://paste.debian.net/hidden/01b30c03/
  585. Guus tx
  586. Guus Openfire does not like <set xmlns="http://jabber.org/protocol/rsm"/>
  587. jonas’ hm
  588. Guus eek, my client formatted that weirdly.
  589. jonas’ mine did not
  590. Guus Hmm... This might be a bug in Openfire
  591. Guus it expects _all_ fields.
  592. jonas’ all in rsm?
  593. jonas’ I can’t give you *that*
  594. jonas’ at most I’d give you a <max/> ;)
  595. Guus code is somewhat hard to read
  596. jonas’ but setting <max/> helps already!
  597. jonas’ I get a reply
  598. Guus it does expect a positive max value
  599. Guus and it cannot have non-specified fields...
  600. Guus seems to be pretty strict.
  601. jonas’ Guus, it doesn’t return a <max/> value
  602. Guus I think I wrote this when I was in college 🙂
  603. jonas’ interestingly, no example in XEP-0059 shows a server returning max
  604. jonas’ so why do I require that :)
  605. Guus it indeed does not re... yeah, what you said. 🙂
  606. jubalh so I assume the meeting is over? :)
  607. jonas’ Guus, I use it as break condition to figure out when the result set is done and I expect the page size used by the server to be in there...
  608. Guus jubalh yup - thanks for your patience 🙂
  609. jubalh no problems, I wasn't aware of the meeting, just joined and typed. so i realized it too late.
  610. Guus jonas` isn't 'count' more appropriate for that?
  611. jonas’ more or less
  612. Guus jubalh no worries, no harm done
  613. jonas’ fixing my code ;)
  614. Guus you're not the only one.
  615. jonas’ wee
  616. jonas’ it works
  617. Douglas Terabyte has left
  618. jonas’ when I explicitly set <max/> in my initial request, I get a proper reply
  619. jubalh I got a bugreport and I wondered whether Cisco Jabber is (still) XMPP and is also 100% compatible? bug report is this, and I thought maybe the server could be the reason https://github.com/profanity-im/profanity/issues/1165
  620. jonas’ Guus, here’s a successful exchange for reference: https://paste.debian.net/hidden/f4671816/
  621. Guus I have no firsthand knowledge, but from what i've heard, it is not.
  622. Lance has left
  623. jonas’ Guus, ^5
  624. Guus jonas’ thanks - max does not seem to be required by the XEP (even though it's in all examples, that's probably what threw many-years-younger-me off)
  625. Guus I'll see if I can make that optional in Openfire.
  626. jonas’ Guus, in my implementation, <max/> is defaulted by the thing handling the RSM-modified request
  627. jonas’ i.e. it’s a service-specific default
  628. pep. jubalh: probably not 100% compatible no
  629. Guus we have a validity check that simply insists it _must_ be present. that seems to be to strict.
  630. pep. When they report, make sure you also get debug logs with what their server sends
  631. Guus Sadly, it's in an upstream library, so updating this will take some time.
  632. jubalh pep., do you think that this bugreport could be due to that reason?
  633. pep. jubalh: ask for XML logs?
  634. jubalh will do
  635. pep. Is there an XML console in profanity or sth?
  636. jubalh there is, yes
  637. jubalh I'll ask him
  638. pep. K
  639. murabito has left
  640. murabito has joined
  641. Douglas Terabyte has joined
  642. Yagiza has left
  643. ralphm I think there is no explicit rule that says you can't send (repeated) `<presence type="subscribed"/>`, but I can see how that's annoying.
  644. ralphm A client could check against local state to prevent annoying the user.
  645. Guus ralphm that's in reply to what? (Am I missing context?)
  646. pep. Guus: not you
  647. ralphm jubalh's message above about Cisco Jabber
  648. Guus I didn't see him talk about presence subscribed though
  649. Guus or is that in https://github.com/profanity-im/profanity/issues/1165 ?
  650. Guus right, sorry.
  651. ralphm Yes
  652. Guus I've been working on an issue where occasionally, messages were not being delivered to a MUC
  653. Guus so I'm now jumping at instances where I appear to be missing messages (which is hard to detect, visually)
  654. jubalh ralphm, so if locally I already have the user tracked as subscribed I should ignore the incoming message subsribed?
  655. murabito has left
  656. murabito has joined
  657. rion has left
  658. rion has joined
  659. eevvoor has left
  660. murabito has left
  661. murabito has joined
  662. Guus how does one interpret an RSM request that defines both an 'index' element, as well as an 'after'?
  663. ralphm jubalh: I would
  664. waqas has joined
  665. jubalh so basically this means looping through roster and seeing who i have subscribed if i'm not mistaken
  666. murabito has left
  667. murabito has joined
  668. Dele (Mobile) has joined
  669. Dele (Mobile) has left
  670. ralphm Looping? I assume your client has some local state for each contact/roster item, indexed by JID
  671. jubalh right sorry
  672. jubalh got it :)
  673. ralphm No worries
  674. zach has joined
  675. waqas has left
  676. waqas has joined
  677. murabito has left
  678. murabito has joined
  679. Dele (Mobile) has joined
  680. Dele (Mobile) has left
  681. Dele (Mobile) has joined
  682. Dele (Mobile) has left
  683. murabito has left
  684. murabito has joined
  685. jubalh has left
  686. jubalh has joined
  687. Lance has joined
  688. murabito has left
  689. murabito has joined
  690. goffi has joined
  691. peter has joined
  692. zach has left
  693. zach has joined
  694. stpeter has joined
  695. Link Mauve “15:59:32 MattJ> I'd love to just move to Link Mauve's magic DOAP project in the near future, when it's ready”, I’d say it’s ready for project maintainers to start using, and for the XSF to start accepting; we don’t have all of the tooling yet, or not as integrated as I’d like, but that can come with time.
  696. Link Mauve I could update #594 to not include any tooling, and instead let authors progressively fill their DOAP entry upon renewal.
  697. jubalh has left
  698. Douglas Terabyte has left
  699. andy has left
  700. edhelas has left
  701. edhelas has joined
  702. zach has left
  703. zach has joined
  704. debacle has joined
  705. andy has joined
  706. sezuan has joined
  707. Lance has left
  708. wurstsalat has left
  709. peter has left
  710. wurstsalat has joined
  711. Lance has joined
  712. jubalh has joined
  713. stpeter has left
  714. flow Guus, what's the motivation for allowing both <after/> and <before/> in tinder's RSM implementation? I think it is right now underspecified what this exactly means, as <after/> is used to page forward, and <before/> is used to page backwards, and hence should be avoided until this is clarified
  715. Zash That is indeed highly ambigous.
  716. andy has left
  717. Guus flow: it's currently not allowed, although I'm playing with code that could allow it. I was actually looking for feedback.
  718. lovetox what was this again for?
  719. lovetox paging backwards but the page is also reversed
  720. lovetox i guess
  721. Zash Prosody with SQL backend does allow it but I'd call it undefined behavior.
  722. flow I tend to believe that RSM should just disallow using <after/> and <before/> together
  723. lovetox it makes not much sense
  724. lovetox though were is the harm flow?
  725. lovetox though where is the harm flow?
  726. Zash Actually I think Prosodys MAM code will allow it always, but some backends will ignore one of them and good luck figuring out which.
  727. lovetox its not mentioned in the XEP, nobody reading the XEP would ever get the idea that this is even possible
  728. lovetox there is no way you can discover that the server supports that "hack"
  729. lovetox so i dont see any client actually using that
  730. flow lovetox, ambigouty and implementation dependent behavior is always harmful to an protocol
  731. Nekit has joined
  732. lovetox but its nowhere documented that this is even possible, and as you say undefined
  733. flow it is also not specified that it is impossible
  734. lovetox so its basically a feature some dev knows and can play with
  735. flow sometimes it is better to be explict
  736. lovetox sorry, its also not defined what happens if add <after> twice
  737. lovetox or if i add a element thats not even mentioned in the XEP
  738. flow that, at least, is disallowed by the schema
  739. Zash Schema validators hate it!
  740. Zash Something something this weird trick
  741. lovetox does it not follow that everything not mentioned in the XEP is *not defined*
  742. flow adding optional extensions is a common pattern for most elements in xmpp, I don't think you can compare it using existing elements in an unspecified way
  743. flow …compare it *with*
  744. Zash In the case of Prosodys SQL backend, `after` and `before` gets turned into SQL like `WHERE id > after AND id < before` altho after page size limits it'll behave like only 'before' was there.
  745. lovetox great Zash, only a madman would use this though
  746. lovetox or someone writing clients that only operate with prosody
  747. Zash Mostly because internal details like that the presence of `before` means it sorts the results backwards.
  748. Zash (and then it flips them around before returning as MAM results)
  749. Guus It'd be good to explicitly define expected behaviour or restrictions in the XEP.
  750. Zash I think other storage backends will simply ignore `after` if `before` is present
  751. Guus Changes in behaviour caused by an invisible implementation detail seems undesirable.
  752. Zash Having both `after` and `before` is UB, so what you gonna do?
  753. zach has left
  754. zach has joined
  755. Zash We could explictly forbid it since it makes no sense
  756. lovetox you talk like this happens per accident
  757. Zash As in, return some error stanza
  758. Guus Sounds good
  759. Zash It happens because the query and the data flow through two layers with slightly different API and semantics.
  760. jubalh has left
  761. Zash Well. Three layers if you count SQL.
  762. jcbrand has left
  763. sezuan has left
  764. goffi has left
  765. jubalh has joined
  766. Lance has left
  767. marc_ has joined
  768. Dele (Mobile) has joined
  769. zach has left
  770. zach has joined
  771. Chobbes has left
  772. Lance has joined
  773. jubalh has left
  774. goffi has joined
  775. goffi has left
  776. andrey.g has left
  777. marc_ has left
  778. Neustradamus Java works with 4096 DH key: https://bugs.openjdk.java.net/browse/JDK-8172869
  779. zach has left
  780. zach has joined
  781. Neustradamus Kev: Have you planned to upgrade M-Link to last version on the new server?
  782. Chobbes has joined
  783. waqas has left
  784. waqas has joined
  785. patrick has joined
  786. xnamed has joined
  787. Dele (Mobile) has left
  788. waqas has left
  789. Chobbes has left
  790. lovetox has left
  791. LNJ has left
  792. LNJ has joined
  793. karoshi has left
  794. Chobbes has joined
  795. Chobbes has left
  796. Chobbes has joined
  797. zach has left
  798. zach has joined
  799. andrey.g has joined
  800. Mikaela has left
  801. Douglas Terabyte has joined
  802. Lance has left