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


  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


  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


  276. Seve

    Hi MattJ

  277. MattJ


  278. Guus


  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


  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


  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


  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


  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


  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


  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


  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


  430. Seve


  431. Guus


  432. MattJ


  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


  438. Guus

    excellent. Let's move on. 🙂

  439. MattJ


  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


  445. Seve

    Ok then

  446. Seve

    4. AOB?

  447. MattJ

    None here

  448. Guus


  449. Seve

    5. Date of Next

  450. Seve

    Next week, same time? :)

  451. Guus


  452. MattJ


  453. Seve

    6. Close

  454. Guus


  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’


  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


  503. Guus

    What's the minimum requirement?

  504. Zash

    2048 presumably

  505. Zash


  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’


  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


  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


  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


  586. Guus

    Openfire does not like <set xmlns="http://jabber.org/protocol/rsm"/>

  587. jonas’


  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’


  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.


  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


  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