XSF Discussion - 2019-03-07

  1. alameyo has joined
  2. larma has left
  3. larma has joined
  4. efrit has left
  5. Zash has left
  6. dwd has joined
  7. moparisthebest has left
  8. moparisthebest has joined
  9. Zash has joined
  10. dwd has left
  11. dwd has joined
  12. UsL has left
  13. UsL has joined
  14. dwd has left
  15. dwd has joined
  16. dwd has left
  17. !xsf_Martin has left
  18. dwd has joined
  19. alameyo has left
  20. dwd has left
  21. ThibG has left
  22. alameyo has joined
  23. dwd has joined
  24. dwd has left
  25. dwd has joined
  26. dwd has left
  27. tux has left
  28. tux has joined
  29. dwd has joined
  30. dwd has left
  31. dwd has joined
  32. lorddavidiii has left
  33. lorddavidiii has joined
  34. lorddavidiii has left
  35. lorddavidiii has joined
  36. dwd has left
  37. Zash has left
  38. larma has left
  39. j.r has left
  40. j.r has joined
  41. debacle has left
  42. dwd has joined
  43. waqas has joined
  44. lskdjf has left
  45. neshtaxmpp has left
  46. neshtaxmpp has joined
  47. dwd has left
  48. dwd has joined
  49. dwd has left
  50. dwd has joined
  51. ThibG has joined
  52. contrapunctus flow: I agree, XEP names are easier to remember than numbers
  53. alacer has left
  54. oli has left
  55. contrapunctus (Funny that this has to be argued with with people who advocate JIDs over phone numbers 😉)
  56. contrapunctus (Funny that this has to be argued with with people who advocate JIDs over phone numbers, for the same reasons 😉)
  57. dwd has left
  58. dwd has joined
  59. dwd has left
  60. dwd has joined
  61. Maranda has left
  62. Maranda has joined
  63. lorddavidiii has left
  64. lorddavidiii has joined
  65. dwd has left
  66. dwd has joined
  67. dwd has left
  68. dwd has joined
  69. alacer has joined
  70. Nekit has joined
  71. pep. wurstsalat: it is already?
  72. alacer has left
  73. dwd has left
  74. dwd has joined
  75. dwd has left
  76. waqas has left
  77. Maranda has left
  78. Maranda has joined
  79. dwd has joined
  80. rion has joined
  81. dwd has left
  82. dwd has joined
  83. dwd has left
  84. dwd has joined
  85. dwd has left
  86. dwd has joined
  87. 404.city has joined
  88. 404.city has left
  89. oli has joined
  90. dwd has left
  91. vaulor has joined
  92. arc has left
  93. arc has joined
  94. mark has joined
  95. dwd has joined
  96. blabla has left
  97. blabla has joined
  98. j.r has left
  99. j.r has joined
  100. dwd has left
  101. dwd has joined
  102. dwd has left
  103. wurstsalat has left
  104. Nekit has left
  105. Nekit has joined
  106. oli has left
  107. oli has joined
  108. lnj has joined
  109. arc has left
  110. arc has joined
  111. dwd has joined
  112. goffi has joined
  113. Maranda has left
  114. Maranda has joined
  115. Zash has joined
  116. andy has joined
  117. karoshi has joined
  118. dwd has left
  119. dwd has joined
  120. dwd has left
  121. oli has left
  122. oli has joined
  123. Steve Kille has left
  124. dwd has joined
  125. ThibG has left
  126. ThibG has joined
  127. lnj has left
  128. Steve Kille has joined
  129. Maranda has left
  130. Maranda has joined
  131. Kev has joined
  132. ThibG has left
  133. ThibG has joined
  134. Ge0rG Wow, the bikeshedding has started! :D
  135. pep. I hope so
  136. dwd has left
  137. dwd has joined
  138. pep. I'm getting fed up with the "let's use <body/> for non-supporting clients". Also the non-spec'd bits of 0066 that say body = oob is the kind of crap that makes it impossible to comment on a picture when sending it.
  139. oli has left
  140. pep. Re non-supporting clients, Conversations doesn't display part/joins, which removes context and makes the conversation hard to understand for some. Should I advertize the fact that I joined a room in <body/>?
  141. pep. As well as when I part
  142. pep. (I mean, my client, automatically)
  143. jonas’ I think there’s a difference between a client deliberately not supporting something and a client which hasn’t gotten around to implement something yet
  144. pep. "screw pidgin"? That's my thoughts
  145. jonas’ screw pidgin sounds like a plan
  146. pep. jonas’, I think the line is pretty thin nonetheless
  147. jonas’ it is
  148. jonas’ I’d say though, anything which makes users lose actual content is non-negotiable
  149. pep. What is "actual content"
  150. Ge0rG reminds me of the previous bifröst version that only put the filename into the body, not the full URL, so I had to grep my raw XML logs for it.
  151. jonas’ pep., message bodies. for example, it would be non-acceptable if XHTML-IM did not specify a plain-text <body/> fallback.
  152. jonas’ or what Ge0rG says
  153. pep. I say actual content goes further than that tbh. Context is as much important to me than the message
  154. Ge0rG yeah, there should always be graceful fallback to <body> for legacy clients. The other side of the medal being a wording in a XEP that allows complying clients to remove the body without losing info
  155. jonas’ pep., it’s a minimum, not an absolute definition
  156. dwd has left
  157. pep. That's why I still put up with part/join noise from Android
  158. pep. Or iOS
  159. Ge0rG pep.: what's your point re 0066?
  160. pep. (and I can tell you it's ugly)
  161. pep. Ge0rG, body = oob is less than optimal. I can already do that better in xhtml-im tbh.
  162. pep. Better
  163. pep. <p>Foo <img src="https://bar/baz.png"/> look at my picture!</p>
  164. Ge0rG pep.: there was a section in my mail starting with "While XEP-0066 is less than ideal" :P
  165. pep. But you're still pushing for it
  166. Ge0rG pep.: and your counter-proposal is "Use XHTML-IM for inline media"?
  167. pep. That's one of the counter-proposals I guess yes
  168. pep. SIMS is another obvious solution
  169. dwd has joined
  170. Andrew Nenakhov Sims?! That uglyness based on yet another markup principle?
  171. Ge0rG pep.: there are two ways how CS can be used. Either we use it to tell developers which XEPs we want them to adopt to make XMPP great, or we use it to tell developers which XEPs they should implement to make their clients interoperable with the current status quo. Last time I checked it was the latter.
  172. pep. ?
  173. pep. (that was for Andrew Nenakhov)
  174. pep. In any case I agree with daniel's point. It's not the time anymore
  175. pep. And hmm, I'm not entirely sure that's what's actually perceived re CS
  176. Ge0rG Andrew Nenakhov: while I appreciate your brevity, you might want to elaborate why you disapprove of it in a longer form, on the ML, in a separate message.
  177. Andrew Nenakhov Because it is based on yet another markup principle, which is silly and unnecessary for IM
  178. Andrew Nenakhov We do need a method to pass additional data and multiple files/images/documents/etc in one stanza but trying to pretend that we need to do it in html like way with marking up body is not a good idea
  179. Guus pep. I don't quite agree it's not the time anymore. I welcome everyone to discuss this further, in the understanding that any outcome will go in the 2020 suite.
  180. Andrew Nenakhov We came up with a simple use of xep-0221 media element, however probably should just unwrap that media element from form tag - some old clients react not ideally on forms
  181. Ge0rG Andrew Nenakhov: I don't see any body markup in the XEP, besides of the XHTML-IM example, where it's obviously appropriate
  182. Guus (let's not wait discussing things, which will only delay 2020)
  183. pep. Guus, yes that's what daniel said, this can go in 2020, it doesn't have to keep 2019 waiting
  184. Guus pep. exactly. I agree with that (but let's not stop discussing things because they won't go in '19!)
  185. pep. Also in the meantime we can implement a proper solution and stop talking about oob for this use-case altogether :)
  186. Andrew Nenakhov Ge0rG, isn't that reference a markup? <reference xmlns='urn:xmpp:reference:0' begin='17' end='20' type='data'> ... Etc
  187. Ge0rG pep.: are you reading my thoughts? :D
  188. pep. Ge0rG, then please stop proposing it :(
  189. Guus stop using PEP for your thoughts, Ge0rG
  190. pep. kicks Guus
  191. Guus I ment Personal Eventing, not you! 😃
  192. Ge0rG Andrew Nenakhov: ah, that one. I never liked XEP-0372 and hope we can get SIMS independently of that as well
  193. Ge0rG Interestingly, SIMS doesn't even mention the existence of XEP-0372
  194. Maranda has left
  195. Maranda has joined
  196. lovetox has joined
  197. lovetox Ge0rG why do you think 0066 is a horrible mess?
  198. frainz has left
  199. Ge0rG lovetox: multiple reasons: 1) you need to do an additional HTTP HEAD before you know whether you should download the file (size, content type) 2) the body=url requirement makes integration of text and image impossible 3) in 0066 there is no wording about using that as an indicator of "inline media" 4) security-paranoid people can't know whether they want to load the media without first leaking their IP address
  200. frainz has joined
  201. Ge0rG 4 is heavily related to 1, but still a bit different
  202. Ge0rG 5) the body=url requirement isn't documented
  203. lovetox Did you read my reply on the list?
  204. lovetox body=url is not a requirement nor a indication for other clients to do UI actions
  205. lovetox its a simple fallback body like in other XEPs
  206. lovetox I dont see how you use any other alternative (SIMS) without providing a fallback body
  207. lovetox if you choose so you could do the same with 0066
  208. rion has left
  209. lovetox 1) yes more metadata is always nice, but i wouldnt call it a horrible mess
  210. Ge0rG Now I wonder when / whether I used the words "horrible mess" re 0066.
  211. Ge0rG lovetox: I think that body=url is enforced by Conversations for inline media, which is a bit unfortunate. I'd have gone with body.replace(url, "") instead to allow the file + comment legacy situation
  212. pep. "lovetox> body=url is not a requirement nor a indication for other clients to do UI actions", Conversations would like to disagree with you
  213. Ge0rG technically speaking, displaying an URL in the client is a perfectly fine way of handling it. But the UX of that is a bit sub-optimal, *especially* on mobile devices.
  214. lovetox And what Conversations does is how the world implements something or ..?!
  215. pep. lovetox, yes? it's been a while we've renamed to The Conversations Protocol, you missed the note? :)
  216. Ge0rG didn't you know that the C in CS-2019 is for "Conversations"?
  217. alacer has joined
  218. Ge0rG Conversations at least has spiked mobile XMPP adoption in the last years, _despite_ its UX
  219. jonas’ I think "because of", actually
  220. pep. yeah, I'd say so as well
  221. Ge0rG 🤣
  222. flow ditto
  223. larma has joined
  224. Ge0rG okay, okay. Let's be honest. It's a great client and super smooth for beginners. It just has some minor quirks that I'm very obsessed about
  225. rtq3 has joined
  226. ThibG has left
  227. ThibG has joined
  228. alacer has left
  229. Ge0rG flow: is there any kind of disco#info cache in Smack? I'd like to re-use the disco#info results between MUCManager.providesMucService() and other places.
  230. andy has left
  231. andy has joined
  232. Seve unpopularopinion: Very hard for me to use Conversations at the beginning, the interface was not really easy for me at first. Now I look back and I don't get why it was difficult for me to use
  233. jonas’ Seve, maybe you are like me and you’re not familiar with how stuff works on android
  234. jonas’ that was it for me, at least
  235. Seve Probably, jonas’, got an 'smartphone' pretty late
  236. Maranda has left
  237. Maranda has joined
  238. pep. lovetox: pardon my French, I actually meant the "memo", not the "note". The O-memo.
  239. pep. leaves now
  240. !xsf_Martin has joined
  241. dwd has left
  242. dwd has joined
  243. dwd has left
  244. dwd has joined
  245. andy has left
  246. andy has joined
  247. ThibG has left
  248. ThibG has joined
  249. dwd has left
  250. dwd has joined
  251. lumi has joined
  252. dwd has left
  253. alacer has joined
  254. alacer has left
  255. ThibG has left
  256. ThibG has joined
  257. dwd has joined
  258. andy has left
  259. andy has joined
  260. andy has left
  261. lskdjf has joined
  262. alacer has joined
  263. dwd has left
  264. dwd has joined
  265. dwd has left
  266. alacer has left
  267. alacer has joined
  268. valo has left
  269. valo has joined
  270. yvo has joined
  271. rtq3 has left
  272. rtq3 has joined
  273. blabla has left
  274. !xsf_Martin has left
  275. blabla has joined
  276. dwd has joined
  277. dwd has left
  278. dwd has joined
  279. dwd has left
  280. alacer has left
  281. dwd has joined
  282. jmpman has joined
  283. dwd has left
  284. dwd has joined
  285. dwd has left
  286. larma has left
  287. dwd has joined
  288. nyco has left
  289. nyco has joined
  290. Holger Those Nextcloud people ... implementing chat from scratch and now wondering how to reinvent federation and the rest of XMPP: https://github.com/nextcloud/spreed/issues/21
  291. Holger They arrived at unique IDs a few minutes ago.
  292. MattJ :)
  293. Ge0rG Somebody should tell them about matrixmpp
  294. Seve Another failure :( we really need to make sure other communities and projects like Nextcloud are aware of XMPP and understand that it can be used (surprise!)
  295. larma has joined
  296. dwd has left
  297. dwd has joined
  298. dwd has left
  299. Holger https://apps.nextcloud.com/apps/ojsxc was already there, but implementing from scratch is just so much more fun.
  300. rtq3 has left
  301. alacer has joined
  302. rtq3 has joined
  303. dwd has joined
  304. yvo has left
  305. blabla has left
  306. Yagiza has joined
  307. dwd has left
  308. dwd has joined
  309. Andrew Nenakhov We're actually planning to make file gallery for Xabber on top of nextcloud
  310. dwd has left
  311. blabla has joined
  312. rtq3 has left
  313. rtq3 has joined
  314. Andrew Nenakhov has left
  315. Andrew Nenakhov has joined
  316. Andrew Nenakhov has left
  317. dwd has joined
  318. Zash has left
  319. Zash has joined
  320. Andrew Nenakhov has joined
  321. Andrew Nenakhov has left
  322. Andrew Nenakhov has joined
  323. Andrew Nenakhov has left
  324. Andrew Nenakhov has joined
  325. Andrew Nenakhov has left
  326. Andrew Nenakhov has joined
  327. Andrew Nenakhov has left
  328. Andrew Nenakhov has joined
  329. Andrew Nenakhov has left
  330. Andrew Nenakhov has joined
  331. Seve Andrew Nenakhov, https://www.goffi.org/b/hGKs6B4wd8dsgNZd5MzQjN/file-sharing-landing-next-release-salut
  332. Seve Maybe you want to explore what goffi has been working on for this kind of feature
  333. Andrew Nenakhov has left
  334. Alex has left
  335. Andrew Nenakhov has joined
  336. Andrew Nenakhov has left
  337. Andrew Nenakhov has joined
  338. moparisthebest Does a xep specifying a new iq element need to define it's own namespace for it? Also what are the rules/conventions for doing so?
  339. moparisthebest New iq child element*
  340. contrapunctus Holger: why not inform them?
  341. dwd has left
  342. dwd has joined
  343. contrapunctus (Or _remind_ them.)
  344. dwd has left
  345. Andrew Nenakhov has left
  346. Holger contrapunctus: I doubt they haven't heard of JSXC, but yes I think I'll gonna troll that issue of nobody else does.
  347. Holger But now ... meeting.
  348. Andrew Nenakhov has joined
  349. Andrew Nenakhov has left
  350. Andrew Nenakhov has joined
  351. Andrew Nenakhov has left
  352. Seve I was going towrite something like 'XMPP!11' but I would be glad if you do it, Holger :D
  353. Andrew Nenakhov has joined
  354. andy has joined
  355. Andrew Nenakhov has left
  356. Andrew Nenakhov has joined
  357. Andrew Nenakhov Seve, I'll take a look, yes
  358. lumi has left
  359. lnj has joined
  360. dwd has joined
  361. kokonoe has left
  362. kokonoe has joined
  363. ralphm has joined
  364. nyco hello
  365. Guus Hi!
  366. Seve Hi
  367. ralphm waves
  368. ralphm bangs gavel
  369. ralphm 0. Welcome + Agenda
  370. ralphm Who do we have and comments on the agenda.
  371. nyco _o/ agenda good to me
  372. MattJ Hey
  373. Seve is here
  374. Guus nothign to add from me
  375. ralphm Full house!
  376. ralphm 1. Minute taker
  377. ralphm Who?
  378. kokonoe has left
  379. ralphm Well, that's disappointing.
  380. ralphm 2. E2E Auth, CA req
  381. nyco we should all edit the same doc in real time while having conversations here
  382. ralphm https://xmpp.org/extensions/inbox/eax-car.html
  383. ralphm nyco: no, we need a minute taker that isn't involved in the discussion. But that's not the topic now.
  384. nyco so, can we be a CA? do we have the resources, capacity, knowledge, process?
  385. Guus Ralph, regarding 2 - correct me if I'm wrong, but this is about accepting the XEP into 'experimental' state, right?
  386. ralphm nyco: as I read the document, it doesn't call for the XSF being a CA
  387. nyco ah
  388. nyco misunderstood?
  389. MattJ Yes, it's not about being a CA
  390. nyco ok, then what?
  391. Seve Are we deciding on the whole XEP or just what it involves the XSF, the 2.2 section?
  392. MattJ As described in the document, we would provide a URL that redirects to one or more CAs
  393. ralphm Seve: I think this is just about accepting it as a XEP, not the full thing, because it is unfinished.
  394. ralphm I have a bunch of questions on the latter, but specifically, if Experimental stage requires us to set something up already.
  395. kokonoe has joined
  396. MattJ I imagine so
  397. MattJ zinid, around?
  398. ralphm Because I am indeed curious what would be in section 4
  399. ralphm and particularly if including a CA in that redirect service will infer some kind of validity/trust/etc. in the reliability of a said CA
  400. Seve agrees
  401. ralphm and whether we, like browsers, need to have procedures for evaluating and possibly evicting CAs
  402. pep. Most likely?
  403. Guus ralphm but that can be a question to be answered before moving from Experimental to Proposed, I think.
  404. ralphm if so, I'm a bit hesitent to accept Experimental as the stage where we start up a service
  405. ralphm hesitant even
  406. Guus What if we accept this as Experimental, in the understanding that we use that state to discuss within the XSF if we are capable/qualified/willing to host and manage the service?
  407. Guus so, without immediately starting to provide the service
  408. ralphm I.e. how do we relay the (apparent) Board's belief that until this thing goes to Active, whatever we put in that service is to not (yet) to be trusted for production use.
  409. Kev You might choose to put a new revision in first.
  410. Kev Saying ... upon advancing to Draft/equiv...
  411. ralphm Kev: unfortunately, since this is procedural, there's only Active
  412. Kev Right, I couldn't be bothered to check.
  413. Kev But the point stands.
  414. Guus Experimental -> Proposed -> Active ?
  415. ralphm Yeah
  416. Kev Text that says "Upon advancing to Active, the XSF will ..."
  417. Guus end-users don't see such revisions, though.
  418. ralphm So Kev, you mean we encode in the document that we put that caveat
  419. Kev That way the XSF isn't obliged to do anything until they advance it.
  420. ralphm I.e. before accepting as XEP
  421. Kev Like various other things say "Upon advancing to Draft, the Registrar..."
  422. Kev ralphm: Yes. That would address the concern, wouldn't it?
  423. ralphm It would
  424. Guus alternatively, different URLs for services based on state of the XEP?
  425. ralphm Or both
  426. Guus unsure if non-static URLs would defeat the purpose of the XEP though.
  427. Andrew Nenakhov has left
  428. ralphm Well, I think having a fresh start when it goes active makes sense.
  429. Andrew Nenakhov has joined
  430. Alex has joined
  431. Guus it would remove the concern that you just raised (that I share)
  432. MattJ Makes sense to me
  433. Guus zinid are you around?
  434. ralphm That said, I haven't read RFC 6940 yet, which describes this particular well-known URI
  435. Guus Assuming the worst-case scenario, where it disallows this.
  436. Guus is a disclaimer in the XEP that things shouldn't be trusted until the XEP is moved to Active state, sufficient?
  437. ralphm Well, we could have, say, test.xmpp.org instead of just xmpp.org during the experimental stage, for the well-known to live at
  438. Kev Until and unless :) I think some sort of notice that it's not 'real' until Active is worthwhile.
  439. Guus oh, that I like that pragmatic solution, Ralph
  440. ralphm Kev: does that sound good to you with your iteam hat on?
  441. Guus Kev I agree that it's worhtwhile, but I was asking if it in itself was enough.
  442. Kev ralphm: TBPH, I've not been following in enough detail to answer that, let me scroll back.
  443. Kev If the question is 'can we host something at test.xmpp.org?' the answer is 'sure'.
  444. blabla has left
  445. Maranda has left
  446. blabla has joined
  447. Kev Although I'm not sure whether it's worth it compared to just saying in the XEP it's not 'active' yet.
  448. Kev But we can do it.
  449. ralphm Ok, so I think this discussion highlights our concerns, which counts as the feedback for the Author to process per Section 5 of XEP-0001.
  450. Guus Kev - I think it would be worth-while, if only to prevent code from having to parse the XEP state to determine if some kind of trust setting should be enabled.
  451. Kev Guus: I don't think it really does that, does it?
  452. ralphm I move we urge the Author to process this, and resubmit.
  453. Seve Is the Author then going to add the information regarding the process until it gets to Active?
  454. Seve Ok
  455. frainz has left
  456. Seve I agree
  457. Guus +1 on ralphm motion
  458. ralphm I don't think we are asking for a fully specced out Business Rules section, yet. That can be done while Experimental.
  459. ralphm +1
  460. Seve +1
  461. Guus Kev I can imagine that some software does not want to use the service until the XEP is Active.
  462. ralphm Guus: seems to me to be a feature
  463. Seve What's your take on this, MattJ and nyco?
  464. Kev Guus: Right. I'm assuming any such software will simply not trust it until their next release after it's active, rather than polling a URL and seeing when it starts to exist.
  465. nyco +1 for resubmit for Business Rules, I'd like to see a non-empty section, at least mentioning some identified problematics
  466. Guus not having a service on the 'active' URL prevents confusion there, I think.
  467. Kev This is a low-F issue for me.
  468. Guus kk
  469. MattJ Sounds fine to me
  470. andy has left
  471. ralphm Ok, motion carry. Thanks for submission zinid, we look forward for the new version.
  472. ralphm "to"
  473. ralphm and "carries". Typing. Sigh
  474. ralphm 3. XEP-0345
  475. ralphm Form of Membership Applications
  476. dwd has left
  477. dwd has joined
  478. Guus pep. raised some concerns in LC
  479. pep. (!)
  480. dwd has left
  481. Guus one of which is that the XEP specifies a restriction to natural persons, while our bylaws explicitly define other entities.
  482. Guus I feel that that should be addressed.
  483. waqas has joined
  484. Guus that's the only concern I have/share (unless others now bring up good points that I didn't think of 😛 )
  485. Guus also, I checked with the XSF Secretary, as this involves a process he's familiar with: he had no concerns.
  486. MattJ I'm curious what the membership feels, specifically about the requirement to list employment
  487. ralphm It is pretty normal for corporations to narrow down what's allowed in bylaws
  488. MattJ We've already had discussions based on just listing names
  489. Guus MattJ membership has had two LC's to express what they feel.
  490. Seve I think Relevant Affiliations is important, as a member.
  491. MattJ Guus, true
  492. ralphm The reason for listing employment is specifically to curb influence by a one or more larger companie
  493. ralphm s
  494. Seve Exactly
  495. pep. There was also comments about "if real names really need to be provided, would it be possible to just provide them to the secretary or somesuch"
  496. MattJ ralphm, right, but (as with name) this could potentially be privately maintained by the Secretary
  497. pep. this ^
  498. ralphm It could
  499. Guus MattJ I agree that it could, but as it never has been, I don't feel that's needed now - unless someone has a good argument.
  500. Seve I must say members may need to know that
  501. waqas has left
  502. waqas has joined
  503. Guus (still interested in hearing from that one person you knew)
  504. waqas has left
  505. ralphm I think that transparency on who's member of the the XSF is a good thing.
  506. Seve I feel this XEP is only stating in writing the current and past procedure of being a member.
  507. ralphm Seve: this is indeed its purpose
  508. Seve Which we should be quite comfortable with it, in my opinion.
  509. pep. Seve, you mean you see no reason for changing it then?
  510. pep. k
  511. ralphm As such, I'm not sure we should at this point discuss changes to it.
  512. Guus agreed - but the concern regarding the more specific definition than the one in the bylaws remains.
  513. Guus why are we making things more specific in this XEP?
  514. ralphm For what it is worth, I think the 2014 thread of remarks, by Matthew Miller, were more about wording than content-wise. Dave mentioned that it inspired him to changes, but I haven't seen those.
  515. waqas has joined
  516. pep. I assume there has never been any case of a non-natural entity applying?
  517. ralphm Guus: because that just codifies what we've been doing from the beginning.
  518. Guus pep. that might be true, but is that a reason to now forbid it?
  519. pep. Guus, not what I'm saying no
  520. ralphm There's been no need or request for a non-natural entity to be a member of the XSF.
  521. Kev Guus: I think so, yes.
  522. pep. Just curious
  523. Seve pep., I must admit I have been always really careful about privacy, and until I didn't became a member of the XSF or submited a XEP, I never published my real name online. I think this is important to be able to trust the XSF and understand it as a serious foundation. Even though you and me can think about the option of not making the name of your company public, in reality, I think it is not the best think when talking about a public foundation like the XSF
  524. ralphm AFAIK
  525. Guus Kev curious about reasoning there.
  526. karoshi has left
  527. karoshi has joined
  528. Kev Guus: If it actually happened it'd be a horrendous can of worms for us.
  529. grumpy has left
  530. waqas has left
  531. pep. The issue to me really is that I don't know if there's a need for a real name.
  532. waqas has joined
  533. ralphm E.g. our voting process currently uses a bot with a jid that is expected to belong to a natural person.
  534. pep. ralphm, does it?
  535. Guus The bylaws state that there's one person that represents the entity
  536. Guus that'd still work.
  537. ralphm pep.: see Alex' e-mails around member elections or other votes
  538. Seve Would an entity be able to be a member, and also members of that entity?
  539. ralphm Seve: good question
  540. ralphm I don't see a good reason for having this right now.
  541. waqas has left
  542. ralphm That the bylaws allow for it, just makes it easier to change our mind later, without paying lawyers and such.
  543. waqas has joined
  544. dwd has joined
  545. Guus it's not a hill I'm going to die on.
  546. ralphm Yes, please don't die.
  547. MattJ Same here, I'm fine with it
  548. ralphm Do we feel that we've processed feedback suffiently to vote on its advancement?
  549. Guus I have noticed the real name remarks, but I don't share those concerns
  550. Guus the omission of not having a process that verifies that a real-sounding-name is indeed, real, is one that I can live with
  551. Guus I'm happy to vote.
  552. ralphm I motion that XEP-0345 progresses to Active.
  553. Guus +1
  554. pep. Not going to die on that hill either, but :/
  555. nyco +1
  556. waqas has left
  557. Seve I would like to explore if confirmation on that person should be needed (If real name is correct and so on), but I think it we can move along for now. I'm +1
  558. Guus (let the records reflect that pep. is looking sad on a hill)
  559. ralphm pep.: to be sure, it being Active doesn't mean it can't change later
  560. ralphm +1
  561. Seve I would like to explore if confirmation on that person should be needed (If real name is correct and so on), but I think we can move forward for now. I'm +1
  562. ralphm (Guus: I welcome you to write the minutes)
  563. ralphm MattJ?
  564. MattJ +1 from me
  565. pep. ralphm, ok, good to know. But judging by this discussion, this is probably not going to change, because we're not welcoming the kind of people that would like this to
  566. pep. (bootstraping issues?)
  567. MattJ My opinion here is that, as was mentioned, we're documenting what we're currently doing in practice
  568. ralphm motion carries. Let the Editors go through to the mechanics to move XEP-0345 to Active.
  569. Guus jonas’ ^
  570. Seve pep., what is a bootstrap issue?
  571. ralphm pep.: you having an opinion on this and being a member seems to be counter your point.
  572. pep. Seve, you need enough of something already to have something carry on, or even be a thing
  573. Guus My remaining available time is limited.
  574. nyco aka chicken and egg
  575. ralphm Guus: mine too
  576. ralphm Since we're 48 minutes in, I'd like to move the remaining items to next week.
  577. MattJ wfm
  578. ralphm 4. Date of Next
  579. ralphm +1W
  580. Guus wfm
  581. ralphm 5. Close
  582. ralphm Thanks all!
  583. ralphm bangs gavel
  584. Guus Thank you
  585. MattJ Thanks!
  586. nyco thx all
  587. Seve Thank you, everybody :)
  588. Seve pep., you mean that, because we don't have enough people that don't want to say their real names, we don't want to let that option be available?
  589. pep. replace the last "we don't want" by "it is unlikely"
  590. ralphm pep.: what I mean is that your question on the need of Real Names™ right now is still a valid one, and I'd welcome a discussion on that topic.
  591. pep. Ok
  592. pep. As I said I'm not going to fight tooth and nail for it, but I also want to be welcoming to people who'd feel concerned about it
  593. ralphm I might even be convinced to change my mind, but for now I feel like the transparency outweighs the concerns (which might need to be more clearly defined).
  594. Zash I didn't read all the backlog, but I'd like to point out that knowledge of real names could be limited to the secretary if needed for legal reasons.
  595. ralphm I also want to note that having this discussion doesn't require pre-existing membership.
  596. ralphm Zash: that was mentioned
  597. Zash Check
  598. Seve If that was the case, would you need a reason to hide your name to the members?
  599. lovetox has left
  600. pep. what is visible to members is usually visible to everyone
  601. alacer has left
  602. pep. Seve, Secretary-only might still not be a valid solution to some fwiw
  603. ralphm I think the only non-public thing in the XSF is the Board mailing list.
  604. Seve I think you have a point though, pep. Since we don't do a check on the name, you could just say you are called Peter Nielsen and let the members trust the application (something that is stated in the XEP, section 7. Security Considerations)
  605. lnj has left
  606. Seve For now though, even I always cared of having a digital life and a 'real' life completely decoupled, I agree with ralphm about transparency
  607. Kev If one cares about decoupling digital life and real life, one still can - pretty much all contribution can be performed with just your digital persona, it's only becoming a member of the real-world organisation that requires a real-world person.
  608. pep. I think transparency should be in acts
  609. pep. And I'm fine with judging people with whatever identity they want to share. I'm already not digging up Facebook accounts of applying members anyway..
  610. pep. (Maybe I should)
  611. Seve laughs
  612. Seve pep., Imagine that when applying for membership to the XSF, you have a button that says 'Log in with Facebook' :D
  613. pep. I wouldn't apply.
  614. Seve pep., I would not even be able to!
  615. Seve (I don't have an account there)
  616. pep. Same, fwiw, but that wasn't why I answered that
  617. Seve I know :)
  618. pep. Same, fwiw, but that's not why I answered that
  619. rtq3 has left
  620. rtq3 has joined
  621. zinid oh, I slept away the meeting
  622. frainz has joined
  623. jmpman has left
  624. Maranda has joined
  625. lnj has joined
  626. mrDoctorWho has left
  627. mrDoctorWho has joined
  628. Maranda has left
  629. Maranda has joined
  630. vaulor has left
  631. vaulor has joined
  632. alacer has joined
  633. dwd has left
  634. dwd has joined
  635. dwd has left
  636. dwd has joined
  637. lnj has left
  638. Maranda has left
  639. Maranda has joined
  640. dwd has left
  641. dwd has joined
  642. dwd has left
  643. kokonoe has left
  644. melvo has left
  645. kokonoe has joined
  646. melvo has joined
  647. blabla has left
  648. debacle has joined
  649. waqas has joined
  650. blabla has joined
  651. Steve Kille has left
  652. ralphm zinid: hope you can work with the comments made during the meeting
  653. waqas has left
  654. waqas has joined
  655. neshtaxmpp has left
  656. Nekit has left
  657. dwd has joined
  658. Maranda has left
  659. Maranda has joined
  660. alacer has left
  661. rtq3 has left
  662. rtq3 has joined
  663. marc_ has joined
  664. dwd has left
  665. dwd has joined
  666. moparisthebest $ dig -p5354 @ +short debian.org
  667. moparisthebest got DoX working
  668. dwd has left
  669. moparisthebest that's UDP -> XMPP listener -> XMPP resolver -> TCP, and back
  670. Yagiza has left
  671. j.r has left
  672. j.r has joined
  673. moparisthebest wire format is: <iq to='dns@example.org/listener' id='27tZp-7' type='get'><dns xmlns='https://moparisthebest.com/dns'>vOIBIAABAAAAAAABB2V4YW1wbGUDb3JnAAABAAEAACkQAAAAAAAADAAKAAj5HO5JuEe+mA</dns></iq> <iq to='dns@example.org/resolver' id='27tZp-7' type='result'><dns xmlns='https://moparisthebest.com/dns'>vOKBoAABAAEAAAABB2V4YW1wbGUDb3JnAAABAAHADAABAAEAAAhjAARduNgiAAApEAAAAAAAAAA</dns></iq>
  674. moparisthebest which is a real request+response for $ dig -p5354 @ +short +tcp example.org -> cc Wiktor :)
  675. moparisthebest I'll have the code pushed up tonight
  676. Wiktor moparisthebest: 👏 looking forward to seeing your code
  677. jonas’ and I thought I was weird
  678. Seve Haha jonas’
  679. moparisthebest Zash, Ge0rG, re: discussion yesterday, bootstrap-wise, if you hard-code a IP + port + username + (maybe anonymous auth, maybe password), it could be used to get proper SRV records for whatever is next etc right? :D
  680. moparisthebest it'd be easy to set up a public "bootstrap account" like that which is firewalled off from talking to anything else but the resolver
  681. Ge0rG moparisthebest: you should have some obfuscated AFD reference in the namespace tag.
  682. Ge0rG moparisthebest: +1 for anonymous auth
  683. moparisthebest what's AFD ?
  684. Ge0rG April Fool's Day
  685. moparisthebest ah right, I think it's better to leave everyone wondering forever if it's serious or april fools joke :P
  686. Ge0rG moparisthebest: can we have some interesting / sensible disco#items offering as well?
  687. moparisthebest I mean, it works, *could* be useful, meh
  688. Ge0rG moparisthebest: oh. There is a category of XEP to spoil that.
  689. moparisthebest right I think it should be Standards Track instead of Humorous for the same reason :D
  690. Ge0rG 🤔
  691. moparisthebest yes, ideally everyone that looks at it has that expression on their face forever
  692. Ge0rG moparisthebest: also can one subscribe to NOTIFY events over XMPP? That would be a real benefit
  693. Ge0rG moparisthebest: I'm not sure council will be able and willing to follow that argumentation
  694. moparisthebest yea it's up to them of course, but I can try :)
  695. moparisthebest it's no more silly than DoH which is a *real thing (tm)*
  696. Ge0rG I'm not sure. XMPP has some significant amount of round trips at session setup, which is amortized over it's typical multi hour life time
  697. moparisthebest that makes it *more* efficient than DoH if you only connect once and send multiple queries over hours/days/years
  698. Ge0rG Touche
  699. dwd has joined
  700. debacle has left
  701. zinid Ge0rG: +1 and the reason I don't want new SASL or how it's called
  702. lovetox has joined
  703. marc_ has left
  704. ThibG has left
  705. ThibG has joined
  706. dwd has left
  707. dwd has joined
  708. dwd has left
  709. Maranda has left
  710. Maranda has joined
  711. dwd has joined
  712. j.r has left
  713. neshtaxmpp has joined
  714. ralphm has left
  715. marc_ has joined
  716. j.r has joined
  717. rtq3 has left
  718. rtq3 has joined
  719. ThibG has left
  720. ThibG has joined
  721. dwd has left
  722. dwd has joined
  723. dwd has left
  724. lumi has joined
  725. lnj has joined
  726. lorddavidiii has left
  727. lorddavidiii has joined
  728. vanitasvitae has left
  729. vanitasvitae has joined
  730. waqas has left
  731. j.r has left
  732. j.r has joined
  733. lnj has left
  734. dwd has joined
  735. j.r has left
  736. j.r has joined
  737. igoose has left
  738. j.r has left
  739. j.r has joined
  740. dwd has left
  741. dwd has joined
  742. kokonoe has left
  743. kokonoe has joined
  744. valo has left
  745. melvo has left
  746. dwd has left
  747. melvo has joined
  748. melvo has left
  749. jonas’ zinid, wat? SASL2 is supposed to reduce number of roundtrips
  750. jonas’ it saves a stream reset
  751. dwd has joined
  752. j.r has left
  753. j.r has joined
  754. 404.city has joined
  755. j.r has left
  756. Zash Did anyone remember why that stream reset exists?
  757. lnj has joined
  758. jonas’ the wording in RFC 6120 which I remember talks about something security I think
  759. jonas’ which makes sense for TLS, I think, because you can add new info in the stream header which you wouldn’t want to add when you haven’t authenticated your peer yet.
  760. Zash I was convinced it was to make sure that there wasn't any trace of credentials in the parser that could leak
  761. j.r has joined
  762. Zash Also security layers, but that's gotten replaced by TLS these days
  763. j.r has left
  764. moparisthebest what's the reason for SASL etc anyway, why not <auth username="bob@example.org" password="thaoeutnh"/> as the first message after the TLS connection is established?
  765. Zash (DIGEST-MD5 could include negotiation of encryption)
  766. j.r has joined
  767. Zash moparisthebest: You mean how it was before?
  768. jonas’ moparisthebest, SASL gives you flexibility and good stuff like SCRAM
  769. moparisthebest worded another way, if TLS is mandatory, what's the point
  770. Zash SCRAM
  771. jonas’ SCRAM allows both parties to not store the plain text password
  772. moparisthebest jonas’, is that "hiding password from server" ?
  773. moparisthebest eh
  774. Zash Hides password from everyone
  775. jonas’ avoiding to ever have to store the plaintext password
  776. jonas’ which is a good thing
  777. moparisthebest is that really worth all the complexity?
  778. Zash Client can store magic hashes, magic hashes sent on the wire, magic hashes stored on the server.
  779. jonas’ SCRAM isn’t that complex
  780. Zash It's fairly simple in fact
  781. Zash But maybe that's just bias from exposure to DIGEST-MD5
  782. moparisthebest and un-upgradeable etc etc if I follow along correctly?
  783. Holger And expensive if you allow PLAIN.
  784. Zash Why would you upgrade again?
  785. moparisthebest sounds pretty expensive/complex overall, for almost no benefit, to me
  786. jonas’ e2ee is more complex
  787. jonas’ ;P
  788. zinid Holger, in that SCRAM mail thread I'm told to adjust the server capacity (read: hardware is cheap). This is pathetic.
  789. lovetox Did it not only have value if we assume people use the same password often on many services?
  790. zinid it's like suggesting using O(N) instead of O(log(N)) and "adjust the capacity"
  791. jonas’ lovetox, not having to store plaintext passwords anywhere is always a good thing, although I’ll miss my Poor Man’s pass (`xpath -e 'string(/account/account[string(name)="$MYJID"]/password)' ~/.purple/accounts.xml 2>/dev/null`)
  792. lovetox jonas’, i think this is only true if you assume the password is not a unique password for only that service
  793. igoose has joined
  794. dwd has left
  795. dwd has joined
  796. jonas’ lovetox, ah, yes
  797. jonas’ but we’re still not quite at device passwords
  798. dwd has left
  799. lovetox which is probably a correct assumption for most people in this world
  800. moparisthebest but we've long been at "seperate password for each service" so I don't get the point
  801. jonas’ moparisthebest, that’s the ideal world, but not the real world
  802. lovetox moparisthebest, you maybe :)
  803. moparisthebest simple auth would also support per device passwords, TOTP etc etc
  804. lovetox i know my parents are definitly not at one password per service :D
  805. moparisthebest isn't "use a password manager" basically been the industry standard advice for years now?
  806. jonas’ you confuse the industry with what normal people do in the real world
  807. moparisthebest well, those people also don't use XMPP :'(
  808. jonas’ not quite true
  809. lovetox moparisthebest, if this would be true there would be no value in services like "is my password pwned"
  810. alacer has joined
  811. lovetox dont know what the name of the site was
  812. jonas’ haveibeenpwned
  813. jonas’ or something like that
  814. lovetox yeah
  815. moparisthebest another argument would be, XMPP is basically the only thing that goes through these lengths not to store password, so what's the point
  816. moparisthebest if you don't re-use it, it doesn't matter, if you do it's everywhere elso on your computer in plaintext?
  817. jonas’ moparisthebest, that seems to boil down to "others are at least as bad, so we don’t have to care" which is not a standard I want to work with
  818. dwd has joined
  819. lovetox from a client pov, this is not much work to implement
  820. lovetox from a server pov it probably has downsides
  821. lovetox but also some upsides
  822. Holger lovetox: Yes, only if we assume users reuse passwords and attackers can identify their other accounts. And of course attackers can still try to grab passwords from registration or password changes, or from SASL PLAIN logins.
  823. Holger And obviously they must be successful in taking over your server in the first place 🙂
  824. lovetox Holger i think the most likely scenario is, your server gets pwned
  825. lovetox they steal the emails and passwords
  826. lovetox and try other services
  827. lovetox not other xmpp accounts
  828. jonas’ good thing XMPP services don’t store emails :)
  829. moparisthebest which bcrypt/scrypt/pbkf2 etc all have had solved for years
  830. vaulor has left
  831. lovetox as a server hoster i would see it as a positive if i know i dont store real passwords from users
  832. moparisthebest servers don't store plaintext passwords anyway
  833. vaulor has joined
  834. moparisthebest I think it's worthless for the client not to store it basically :/
  835. Zash SCRAM uses PBKDF2 already
  836. Zash Along with one weird trick that means you don't have to do the expensive computation
  837. lovetox moparisthebest, what do you mean they dont store it in plaintext? how do they authenticate a PLAIN connection than?
  838. alacer has left
  839. moparisthebest they store them hashed
  840. jonas’ lovetox, ... by pbkdf2-ing things and comparing hashes?
  841. zinid SASL EXTERNAL!!!1111
  842. Holger lovetox: Yes, there's obviously value in hashing passwords, but I don't quite get this OMG-IT'S-2019-PLAINTEXT-PASSWORDS-NOOO-GO drama. SCRAM has downsides, so it's a trade-off and admins must decide.
  843. lovetox jonas’, so why use SCRAM then?
  844. efrit has joined
  845. jonas’ lovetox, less expensive when both sides support it
  846. jonas’ Holger, except for the upgradability, *does* it have downsides?
  847. zinid jonas’, external services?
  848. Zash And the upgrade problem of SCRAM mostly boils down to that you need the plain text to upgrade, which is quite normal for this kind of thing
  849. jonas’ assuming that you store hashed passwords anyways, it actually has the upside that you save the computation when you have a client which supports it. when the client only supports PLAIN, you have to hash, but you also have to do that when you store hashed anyways.
  850. jonas’ zinid, ah, yes, the pain with the external services. I know it myself.
  851. Holger jonas’: As I said it's expensive if you allow PLAIN, so DoS vector. Plus external services like e.g. STUN/TURN/SIP as zinid said.
  852. moparisthebest Zash, so it prevents you from needing to store plaintext on client, that's the only benefit, and it requires plaintext on client to upgrade?
  853. moparisthebest what's the benefit again?
  854. jonas’ Holger, see what I wrote about the PLAIN issue.
  855. jonas’ it is only more expensive if you consider storing plaintext passwords a real alternative
  856. Holger Yes, I wasn't making your assumption.
  857. Holger Of course it's an alternative.
  858. Zash moparisthebest: Ugh. I don't even.
  859. zinid is storing plaintext an alternative? I don't think that's what users expect you to do
  860. zinid but you can lie of course!
  861. kokonoe has left
  862. lovetox So there is no perfect solution?
  863. 404.city has left
  864. lovetox DoS vector with plain, SCRAM does not work with external services and not upgradeable easily
  865. zinid SASL EXTERNAL, bitches!!111
  866. kokonoe has joined
  867. lovetox how does that work, you authenticate over another channel?
  868. Zash zinid: Also problematic
  869. moparisthebest if... all HTTP services ever can handle the "DoS vector of plain" then I'm pretty sure XMPP servers can
  870. Zash zinid: Or rather, which kind of SASL EXTERNAL?
  871. zinid Zash, X.509 certs
  872. zinid Zash, also, you can say about everything "also problematic"
  873. moparisthebest HTTP has far more auths in comparison, sometimes on every request
  874. zinid read this http://upload.zinid.ru/xep-eax-csr.html (it's not finished, I'm still working on it)
  875. Holger zinid: I don't think day-to-day users ever question the password storage format. If they do I'd expect most to assume the server has the password as they never heard of hashes.
  876. Zash zinid: Mostly I'm concerned about certificates being sent in the clear, tho maybe TLS 1.3 fixed that. Not sure.
  877. zinid Holger, yeah, but the ones who question are very loud
  878. Holger Indeed.
  879. jonas’ Holger, it’s not about what day-to-day users question or expect, it’s about sensible practices in the IT industry and not looking very dumb when you get owned.
  880. zinid Zash, it's fixed in TLS1.3, we checked that with Wiktor recently
  881. zinid Zash, both client and server certs are now encrypted
  882. Holger jonas’: Yes, and my point above was that this is more of a hype thing than a sensible practice.
  883. Zash zinid: Then yes, client certs are pretty nice
  884. zinid Zash, so read my scribble!!!111
  885. jonas’ Holger, to be clear, you think that not storing plaintext passwords is more of a hype thing than a sensible practice?
  886. zinid feedback is welcome even at this stage of the scribble
  887. dwd has left
  888. dwd has joined
  889. lovetox but how does the client obtain the client cert? what if he changes device?
  890. Holger jonas’: If you look at it without the OMG drama, as I'd expect from IT people who know their job, you'll see it's a trade-off.
  891. jonas’ sure it’s a trade-off
  892. zinid lovetox, sigh, look at my proposal please 🙁
  893. jonas’ (I’m storing passwords with SSHA, which is pretty much plaintext for a determined attacker)
  894. zinid at least at intro
  895. lovetox yeah im reading now
  896. lovetox sorry :)
  897. Holger jonas’: So "plaintext is NO-GO" is not the obviously correct decision.
  898. jonas’ but I’d also say that the default is more like "don’t store plaintext unless you have a very good reason to do so"
  899. Holger All else being equal, sure. That's stating the obvious. The hype is about stopping at this point.
  900. jonas’ I see
  901. rtq3 has left
  902. dwd has left
  903. efrit has left
  904. pep. >jonas’> Holger, it’s not about what day-to-day users question or expect, it’s about sensible practices in the IT industry and not looking very dumb when you get owned. I'd argue it's neither of these, it's about privacy terms and morale (of keeping your promises) :)
  905. moparisthebest it's invisible to users anyway
  906. moparisthebest I don't know what conversations, gajim, dino do when I type my password in
  907. pep. It is indeed
  908. moparisthebest if anything, users expect the website they type their user+pass in to have their user+pass
  909. dwd has joined
  910. moparisthebest because that's how every website ever works
  911. pep. tbh, I don't think users expect :/
  912. pep. (at all)
  913. waqas has joined
  914. Nekit has joined
  915. waqas has left
  916. waqas has joined
  917. dwd has left
  918. UsL has left
  919. j.r has left
  920. j.r has joined
  921. vaulor has left
  922. Steve Kille has joined
  923. dwd has joined
  924. debacle has joined
  925. j.r has left
  926. j.r has joined
  927. ralphm has joined
  928. j.r has left
  929. j.r has joined
  930. j.r has left
  931. j.r has joined
  932. rion has joined
  933. ralphm has left
  934. ralphm has joined
  935. valo has joined
  936. j.r has left
  937. j.r has joined
  938. ralphm has left
  939. ralphm has joined
  940. rtq3 has joined
  941. lovetox has left
  942. ralphm has left
  943. ralphm has joined
  944. lovetox has joined
  945. rtq3 has left
  946. lnj has left
  947. rtq3 has joined
  948. ralphm has left
  949. ralphm has joined
  950. grumpy has joined
  951. lnj has joined
  952. kokonoe has left
  953. kokonoe has joined
  954. UsL has joined
  955. valo has left
  956. j.r has left
  957. Nekit has left
  958. j.r has joined
  959. j.r has left
  960. ThibG has left
  961. ThibG has joined
  962. j.r has joined
  963. !xsf_Martin has joined
  964. ralphm has left
  965. ralphm has joined
  966. Steve Kille has left
  967. j.r has left
  968. j.r has joined
  969. j.r has left
  970. ralphm has left
  971. ralphm has joined
  972. j.r has joined
  973. andrey.g has left
  974. valo has joined
  975. j.r has left
  976. j.r has joined
  977. rion has left
  978. rion has joined
  979. andrey.g has joined
  980. lumi has left
  981. goffi has left
  982. rion has left
  983. ThibG has left
  984. ThibG has joined
  985. blabla has left
  986. blabla has joined
  987. lovetox has left
  988. debacle has left
  989. blabla has left
  990. melvo has joined
  991. rtq3 has left
  992. rtq3 has joined
  993. rtq3 has left
  994. rtq3 has joined
  995. ralphm has left
  996. ralphm has joined
  997. ThibG has left
  998. ThibG has joined
  999. karoshi has left
  1000. rtq3 has left
  1001. rtq3 has joined
  1002. frainz has left
  1003. frainz has joined
  1004. waqas has left
  1005. waqas has joined
  1006. waqas has left
  1007. waqas has joined
  1008. waqas has left
  1009. rtq3 has left