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.


  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


  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


  365. Guus


  366. Seve


  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


  373. Seve is here

  374. Guus

    nothign to add from me

  375. ralphm

    Full house!

  376. ralphm

    1. Minute taker

  377. ralphm


  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


  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


  388. nyco


  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


  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


  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


  460. Seve


  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


  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


  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


  494. Seve


  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.


  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


  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


  554. pep.

    Not going to die on that hill either, but :/

  555. nyco


  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


  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


  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


  578. ralphm

    4. Date of Next

  579. ralphm


  580. Guus


  581. ralphm

    5. Close

  582. ralphm

    Thanks all!

  583. ralphm bangs gavel

  584. Guus

    Thank you

  585. MattJ


  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.


  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


  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


  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


  771. jonas’

    SCRAM allows both parties to not store the plain text password

  772. moparisthebest

    jonas’, is that "hiding password from server" ?

  773. moparisthebest


  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’


  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’


  813. jonas’

    or something like that

  814. lovetox


  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


  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