XSF Discussion - 2017-11-10

  1. Ge0rG has left

  2. arc has left

  3. Arc has left

  4. Arc has joined

  5. arc has joined

  6. uc has joined

  7. jjrh has left

  8. Ge0rG has left

  9. jjrh has left

  10. jjrh has left

  11. jjrh has left

  12. jjrh has left

  13. jere has left

  14. jere has joined

  15. Ge0rG has left

  16. Guus has left

  17. jjrh has left

  18. daniel has left

  19. Ge0rG has left

  20. Valerian has left

  21. Valerian has joined

  22. Valerian has left

  23. jjrh has left

  24. jjrh has left

  25. Guus has joined

  26. Lance has joined

  27. la|r|ma has joined

  28. Guus has left

  29. Ge0rG has left

  30. Guus has joined

  31. Arc has left

  32. Arc has joined

  33. Ge0rG has joined

  34. Valerian has joined

  35. Ge0rG has left

  36. sonny has left

  37. sonny has joined

  38. Guus has left

  39. Guus has joined

  40. la|r|ma has joined

  41. lskdjf has joined

  42. Ge0rG has left

  43. tux has left

  44. tux has joined

  45. SamWhited has left

  46. efrit has joined

  47. Ge0rG has left

  48. Valerian has left

  49. SamWhited has left

  50. Valerian has joined

  51. Valerian has left

  52. SamWhited has joined

  53. jere has left

  54. jere has joined

  55. Tobias has joined

  56. Tobias has joined

  57. Arc has left

  58. Arc has joined

  59. Ge0rG has left

  60. matlag has left

  61. arc has left

  62. arc has joined

  63. efrit has left

  64. efrit has joined

  65. bear has left

  66. daniel has left

  67. nyco has left

  68. nyco has joined

  69. Ge0rG has left

  70. Ge0rG has left

  71. Valerian has joined

  72. Ge0rG has left

  73. Ge0rG has left

  74. bear has joined

  75. Lance has left

  76. Ge0rG has left

  77. Ge0rG has left

  78. Valerian has left

  79. Ge0rG has left

  80. lumi has left

  81. Ge0rG has left

  82. uc has left

  83. uc has joined

  84. arc has left

  85. arc has joined

  86. efrit has left

  87. Ge0rG has left

  88. Ge0rG has left

  89. SamWhited has left

  90. jere has left

  91. Ge0rG has left

  92. Syndace has joined

  93. Syndace has joined

  94. Ge0rG has left

  95. daniel has left

  96. Ge0rG has left

  97. Ge0rG has left

  98. Ge0rG has left

  99. daniel has left

  100. Guus has left

  101. Guus has joined

  102. Ge0rG has left

  103. goffi has joined

  104. daniel has left

  105. arc has left

  106. arc has joined

  107. jubalh has joined

  108. Arc has left

  109. daniel has left

  110. arc has left

  111. arc has joined

  112. arc has left

  113. arc has joined

  114. Guus has left

  115. Guus has joined

  116. jubalh has left

  117. arc has left

  118. arc has joined

  119. xnyhps has left

  120. Guus has left

  121. Guus has joined

  122. ralphm has left

  123. ralphm has left

  124. intosi has joined

  125. Ge0rG has left

  126. marc has joined

  127. ralphm has left

  128. waqas has left

  129. Steve Kille has left

  130. Steve Kille has left

  131. Steve Kille has left

  132. Ge0rG has left

  133. Steve Kille has joined

  134. ralphm has left

  135. edhelas has left

  136. jubalh has left

  137. jubalh has left

  138. @Alacer has joined

  139. la|r|ma has joined

  140. jubalh has joined

  141. ralphm has joined

  142. Ge0rG has joined

  143. jubalh has left

  144. jubalh has joined

  145. daniel has left

  146. Ge0rG has left

  147. ralphm has joined

  148. daniel has left

  149. ralphm has left

  150. mimi89999 has joined

  151. lskdjf has joined

  152. daniel has left

  153. jcbrand has joined

  154. Zash has left

  155. Guus

    Any webrtc aficionado here?

  156. edhelas


  157. marc


  158. Zash has left

  159. jonasw

    possibly in the future

  160. edhelas

    I'm still waiting for clients that are proposing native WebRTC + native Jingle to do tests with Movim :)

  161. Guus

    (I'm a noob, my terminiology might be off): I'm looking for information on the SSLTCP ICE canidate. As far as I understand, it "mimics" a SSL/TLS handshake to fool some firewalls into accepting traffic, without doing actual SSL/TLS encryption (thus not fooling proper firewalls).

  162. Guus

    my questions: a) exactly what version of the clienthello (I think?) is mimiced? b) There appears to be something called TURNS which does full TLS that allows passage through proper filewalls (with the overhead of encryption). This is pretty hard to find via google - where's that documented?

  163. Guus


  164. jonasw

    Guus, https://tools.ietf.org/html/rfc5766

  165. jonasw

    that mentions "turns"

  166. jonasw

    (including the quotes)

  167. jonasw

    so maybe "TURN over TLS" is a good search term

  168. jonasw

    (that term at least works for me with google, but my google is well-trained on RFCs etc.)

  169. Guus


  170. jonasw

    a quick google suggests that ssltcp is propretary

  171. jonasw


  172. jonasw

    so aside from reverse engineering google hangouts, it could be tricky to find out how it works

  173. Guus

    ah, Microsoft does document something similar, it appears. They're clalling that MS-TURN: http://interoperability.blob.core.windows.net/files/MS-TURN/[MS-TURN].pdf

  174. Guus

    "Pseudo-TLS over TCP"

  175. daniel has left

  176. daniel has left

  177. Guus has left

  178. efrit has joined

  179. Alex has joined

  180. @Alacer has left

  181. uc has joined

  182. uc has joined

  183. @Alacer has joined

  184. Zash has joined

  185. arc has left

  186. arc has joined

  187. jubalh has joined

  188. Syndace has left

  189. daniel has left

  190. zinid has left

  191. andrey.g has left

  192. Guus

    so, yeah, the SSLTCP ICE pseudo clienthello is a SSL v2.0 clienthello with a specific challenge (yey for wireshark)

  193. jonasw

    sslv2, amusing. but I wouldn’t be surprised if the kind of firewalls fooled by that would also be the kind of firewalls not giving a lot about actual transport security :-)

  194. Guus

    exactly what I was thinking. It also answers my question on why the multiplexer I was using didn't seem to pick it up with the default "TLS" probe :)

  195. jubalh has joined

  196. jere has joined

  197. lskdjf has joined

  198. jubalh has left

  199. sonny has joined

  200. waqas has joined

  201. waqas has left

  202. daniel has left

  203. edhelas has left

  204. jcbrand has left

  205. la|r|ma has joined

  206. daniel has left

  207. Alex has left

  208. daniel has left

  209. Syndace has left

  210. daniel has left

  211. ralphm has left

  212. jere has left

  213. jere has joined

  214. Alex has left

  215. daniel has left

  216. jubalh has joined

  217. Valerian has joined

  218. daniel has left

  219. daniel has joined

  220. intosi has left

  221. jubalh has left

  222. jubalh has joined

  223. Alex has joined

  224. jubalh has left

  225. intosi has joined

  226. efrit has left

  227. vanitasvitae has joined

  228. vanitasvitae has joined

  229. vanitasvitae has left

  230. lumi has joined

  231. vanitasvitae has joined

  232. lskdjf has left

  233. lskdjf has joined

  234. Alex has left

  235. vanitasvitae has left

  236. Valerian has left

  237. moparisthebest

    Guus: also stun and turn alpn IDs here https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

  238. zinid

    still no our ALPNs in the list

  239. zinid

    xmpp-server and xmpp-client

  240. daniel has left

  241. moparisthebest

    zinid: supposedly iana approved and they will be there next update

  242. moparisthebest

    I want to guess and say that was a month ago

  243. andrey.g has joined

  244. vanitasvitae has joined

  245. lovetox has joined

  246. lumi has joined

  247. Syndace has left

  248. Valerian has joined

  249. daniel has left

  250. Guus has left

  251. daniel has left

  252. daniel has joined

  253. waqas has joined

  254. waqas has left

  255. la|r|ma has left

  256. Syndace has left

  257. Syndace has left

  258. ralphm has joined

  259. tux has joined

  260. jere has left

  261. jere has joined

  262. jere has left

  263. jere has joined

  264. jere has left

  265. jere has joined

  266. Guus has left

  267. Syndace has left

  268. valo has joined

  269. valo has joined

  270. Syndace has left

  271. bjc has joined

  272. la|r|ma has joined

  273. la|r|ma has joined

  274. Ge0rG has left

  275. Zash has left

  276. Ge0rG has left

  277. Guus has left

  278. @Alacer has left

  279. Ge0rG has left

  280. ralphm has left

  281. Ge0rG has left

  282. Guus has left

  283. intosi has left

  284. Guus has left

  285. marc has left

  286. uc has joined

  287. daniel has left

  288. daniel has joined

  289. uc has joined

  290. Zash has left

  291. la|r|ma has joined

  292. la|r|ma has joined

  293. daniel has left

  294. daniel has joined

  295. tux has joined

  296. @Alacer has joined

  297. ralphm has joined

  298. Guus has left

  299. tux has joined

  300. Valerian has left

  301. la|r|ma has left

  302. la|r|ma has joined

  303. Valerian has joined

  304. tux has left

  305. jere has left

  306. jere has joined

  307. tux has joined

  308. jere has joined

  309. jere has joined

  310. bjc has left

  311. bjc has joined

  312. Guus has left

  313. vanitasvitae has left

  314. daniel has left

  315. Steve Kille has left

  316. Steve Kille has left

  317. Steve Kille has joined

  318. jubalh has joined

  319. ralphm has left

  320. jere has left

  321. jere has joined

  322. jere has left

  323. jere has joined

  324. jabberatdemo has joined

  325. Steve Kille has left

  326. jabberatdemo has left

  327. Guus has left

  328. Tobias has joined

  329. Guus has left

  330. jere has left

  331. jere has joined

  332. ralphm has joined

  333. Ge0rG has joined

  334. Guus has left

  335. jubalh has left

  336. bjc has joined

  337. daniel has left

  338. Valerian has left

  339. daniel has left

  340. Valerian has joined

  341. jjrh has left

  342. jjrh has left

  343. SamWhited

    daniel: the wording is a bit confusing, I'll have to think about how that whole section can be rewritten later, but here's a patch for the issue you mentioned: https://github.com/xsf/xeps/pull/539

  344. Zash has left

  345. jubalh has joined

  346. Zash has left

  347. daniel

    SamWhited, yes. wording this is the only downside of this otherwise useful change... I think you did a good job though.

  348. SamWhited

    It may be better to rewrite that chunk as a list of rules in the order you should apply them when parsing

  349. daniel

    should probably contain a few 'negative' examples as well. like `*foo *bar` (indicate that this wont be styled)

  350. daniel

    but we can finish the XEP first before we add more examples

  351. SamWhited

    Good call, I should add some for this rule to that list (there is a list of things that aren't styled)

  352. SamWhited

    (added that one)

  353. jubalh has joined

  354. daniel

    Conversations Master has already been updated to reflect that change by the way. That's going to be shipped with one of the bug fix releases that always follow my minor releases

  355. daniel

    Will be interesting to see where the broader 'leave keywords in' discussion leads

  356. SamWhited

    I still don't have the regular release for whatever reason

  357. daniel

    If people really end up hating the keywords we will have to think about and opt in annotations or what ever

  358. SamWhited

    Yah, I'll be curious about that. I still think it's an implementation detail and is up to individual clients/services, which is why I only made it a SHOULD after we upgraded it from MAY

  359. daniel

    I just promoted from beta to stable an hour ago

  360. daniel

    Guess you are not on the beta channel

  361. SamWhited

    oh, I thought it was already out, nevermind then

  362. SamWhited

    yah, I think the beta group didn't like my Google Apps account or something? I can't remember

  363. daniel

    > oh, I thought it was already out, nevermind then So did I 😀

  364. SamWhited

    hah, that explains it

  365. Guus

    has that / _ italics vs underline discussion come to an end?

  366. moparisthebest

    the problem with opt-in (client sending 'this is styled') is how would a client know I meant *bold*, that's sorta the whole point

  367. SamWhited

    Guus: I'm not sure. I didn't hear any compelling reason to change it other than one or two XMPP clients were doing / aleady, so I didn't, but if it's what the community wants I'm happy to do so.

  368. moparisthebest

    Guus, never

  369. SamWhited

    But I felt that didn't outweigh the fact that most other messengers seemed to be doing _ already and that _ has meant italics since the days of typewriters

  370. Guus

    I was discussing it with some frontend-oriented colleagues. They basically said: "Both underlining and italic are used to express emphasis. Never allow underlining for anything else than hyperlinks. Underlining has it's origin with typewriters, that (mechanically) didn't have skewed letters."

  371. SamWhited

    oh yah, I think you mentioned that; that seems like a good enough reason not to add underlines and to keep _ for italics to me.

  372. Guus

    is it an idea to simply define both as "emphasis" and let the client use whatever they prefer?

  373. lumi has joined

  374. SamWhited

    I defined it that way originally, where actually doing italics was a MAY; it's a SHOULD now, but I could be persauaded to go back.

  375. moparisthebest

    so do you support /this/ for italics too?

  376. SamWhited

    I just thought it made more sense to strive for consistency.

  377. Guus

    I personally prefer _ for italics - but most historical usage implies underline.

  378. moparisthebest

    I'm not actually sure where that comes from

  379. SamWhited

    There is of course nothing stopping clients from also supporting /this/, it just won't be as consistent

  380. SamWhited

    The typewriter historical usage implies italics, just not until you actually go to typeset it… maybe we should have a timer and it should randomly change into italics!

  381. moparisthebest

    does the XEP say both or not though

  382. SamWhited

    The XEP doesn't mention /

  383. moparisthebest

    I don't know the answer as to whether it should or not

  384. SamWhited

    I also thought it was likely that / would collide with paths

  385. Guus

    using / for markup is annoying, if your text has URLs (the stuff that ironically, requires an underline in rendering...)

  386. SamWhited

    /this/is/a/path/ would be italisized under the current rules

  387. SamWhited

    or "this" and "a" would anyways

  388. lumi has left

  389. moparisthebest

    URLs wouldn't

  390. SamWhited

    just "this", rather.

  391. moparisthebest

    a folder file path would and a file path would not

  392. Guus

    meh, perhaps it's best to just go with something and stop discussing :)

  393. moparisthebest

    at least for me that falls under who cares territory

  394. lumi has joined

  395. SamWhited

    It seems like there is a slight upside to using _ over /, so unless someone *really* comes up with a compelling reason I'll probably leave it as is

  396. SamWhited

    Although, at this point I'm not even sure if this will be accepted so ¯\_(ツ)_/¯

  397. moparisthebest

    I have nothing compelling :) just that I've always done /italics/ and gajim does it too

  398. moparisthebest

    it doesn't matter

  399. SamWhited

    yah, I like /italics/ pretty well too

  400. Guus

    yeah, hence my suggestion to define _ as well as / as 'emphasis' and throw consistency out of the window.

  401. lumi has joined

  402. Guus

    not sure if it's a fair tradeoff though

  403. SamWhited

    It doesn't seem worth it to me

  404. moparisthebest

    what's 'emphasis' ? bold or italics?

  405. Guus

    emphasis is typically expresses with underline or italics

  406. Guus

    ... but your quesion alone proves that it's a bad idea :)

  407. SamWhited

    I call it "bold" and "italics" right now in the protoxep, but they're both a SHOULD. Maybe I should merge those sections and say that they're different types of "emphasis", someone asked for it and I said I would, I just didn't want to make the change unless it was accepted (although now I've already done more work, might as well do a bit more)

  408. moparisthebest

    to me, obviously, 'emphasis' is unclear so I'd say bold/italics etc

  409. moparisthebest

    if the only argument is 'accessible' clients well they have to decide the difference anyway so

  410. moparisthebest

    there isn't a XEP police going you translated that to voice wrong

  411. daniel

    /this/is/a/path/ would emphasize the whole thing

  412. daniel

    Because the inner / will be ignored

  413. Ge0rG

    paths are important, they need emphasis.

  414. daniel

    With the PR SamWhited just made

  415. daniel

    Not with the published rules

  416. moparisthebest

    but I think /this/is/a/path/to/a/file would not emphasize anything right?

  417. moparisthebest

    because only folders are important, not files

  418. daniel

    moparisthebest: yes

  419. moparisthebest


  420. Ge0rG

    so directories are more important than files.

  421. moparisthebest


  422. SamWhited

    daniel: I don't think the change I made affects that one will it?

  423. daniel

    oh you are right

  424. daniel

    it will emphasize /this/

  425. daniel

    with both the old and the new rules

  426. daniel

    still not cool though. and a reason not to use / as a keyword

  427. moparisthebest

    what if my OS uses _ as a path seperator, then I'm back to the same problem

  428. jubalh has joined

  429. moparisthebest

    all of these messenger silently changes my send text is a problem I've always had in every client

  430. moparisthebest

    I wish they followed these rules where at least the characters were left in

  431. moparisthebest

    that fixes everything, so in my opinion what actually gets bolded/etc doesn't really matter

  432. moparisthebest

    try pasting code in 'lync' or 'skype for business' for example, it's a nightmare

  433. Guus

    whatsapp nicely fades the keywords a little, but keeps them in place

  434. moparisthebest

    perfect imho

  435. jjrh has left

  436. jubalh has left

  437. jubalh has joined

  438. jjrh has left

  439. jjrh has left

  440. jjrh has left

  441. ralphm has left

  442. jjrh has left

  443. daniel has left

  444. arc has left

  445. arc has joined

  446. daniel has left

  447. jjrh has left

  448. jjrh has left

  449. arc has left

  450. arc has joined

  451. jubalh has left

  452. Ge0rG has left

  453. sonny has left

  454. sonny has joined

  455. sonny has left

  456. sonny has joined

  457. sonny has joined

  458. sonny has joined

  459. Guus

    SamWhited: what about nested formatting? formatting in code blocks is likely unwanted, but what about in quotations?

  460. SamWhited

    Guus: It's allowed by the spec

  461. ThurahT has left

  462. Tobias has joined

  463. Guus

    "Block quotes may contain any child block, including other quotations"

  464. Guus

    I misread that as "may contain other quotations"

  465. SamWhited

    I probably also need to define the block/span thing better

  466. arc has left

  467. arc has joined

  468. Guus

    You're not mentioning hyperlinks - but I'd expect that most clients that do styling, would also make those clickable (and give them corresponding style). Maybe mention that?

  469. SamWhited

    I thought about it, but I didn't want to formally specify those (same with lists) because it's just something I'd expect clients to do by themselves and it's not really the same thing as the other indicators

  470. sonny has joined

  471. ThurahT has joined

  472. Lance has joined

  473. sonny has joined

  474. sonny has joined

  475. SamWhited

    Maybe just a quick mention to note that most clients probably will want to also auto-link hyperlinks

  476. Guus

    SamWhited: links shouldn't be rendered in preformatted blocks though.

  477. SamWhited

    and that lists were left off because users can type "1." easily enough

  478. Guus

    I'd not mention lists at all, I think.

  479. SamWhited

    I don't know if it matters if lists are rendered in preformatted blocks or not, but that does seem worth mentioning one way or another.

  480. arc has left

  481. Arc has joined

  482. SamWhited

    Even if it's just to say "clients may want to consider this and whether they want it or not"

  483. SamWhited


  484. Guus

    ... I'm wondering if the adoption rate of the XEP would be significantly higher if you'd forget about blocks completely, and do spans only.

  485. Guus

    (that's an elaborate way to admit that I'm a lazy client dev)

  486. SamWhited

    I wouldn't be against that, although I think the blocks aren't very difficult to implement either. Did you run into any trouble while playing with it?

  487. Guus

    SamWhited: not 'trouble', but it does require me to rewrite parts of the displaying code. Things are easier when I only need to concern myself with single lines.

  488. Guus

    I quite dislike implementing stuff that has all kind of exceptional cases "if then do that except for when this is that"

  489. Guus

    the spans are already complex. Having to think of nesting spans or blocks in other blocks - meh, I'd rather fix another bug. :)

  490. Guus

    as I said, lazy.

  491. Guus

    also, preformatted blocks add little value for me, personally (I can see how they could be useful, but I'd much rather have people use a service like pastebin, isntead of cluttering up my MUC)

  492. Guus

    blockquotes could be useful to an extend, but the XEP would be interesting in itself without it.

  493. arc has joined

  494. Guus

    also: people in open_chat now are experimenting with cowsay in the muc.

  495. SamWhited

    I thought about making that an easter egg in my little client… if you did ```cowsay it would pipe it through that first and then display

  496. Guus

    shouldn't block text be mono-spaced?

  497. SamWhited

    That was the idea

  498. Guus

    I don't think it mentions that explicitly

  499. SamWhited

    oops, thanks, I'll add that to my todo as well

  500. SamWhited

    It mentions it in one of the examples!

  501. SamWhited

    > This should show up as monospace, preformatted text ⤴

  502. SamWhited

    Probably need some normative language there

  503. Guus

    is this valued: ``` hello ```

  504. Guus

    also, lines with ``` could easily by accident end with some random whitespace - might be good to explicitly allow for that?

  505. SamWhited

    hmm, no, I just didn't expand that section as much as I thought I did

  506. SamWhited

    It should only be the sequence "```\n" at the beginning of a line followed by "\n```"

  507. SamWhited

    I think; I'm not sure how likely accidental use of it would be without that

  508. Guus


  509. SamWhited

    why the space?

  510. Guus

    because people copy/paste stuff sloppy?

  511. SamWhited

    maybe it should just be any line starting with ``` and anything after it is ignored, then people can shove syntax highlighting hints in there like github does

  512. Guus

    I've had hell with the import of DER certs, because of a trailing space somewhere. It might be good to be somewhat lenient.

  513. SamWhited

    yah, makes sense

  514. Guus

    (then again, I'm leaning towards dropping all of this weird complexity by dropping blocks from the xep completely)

  515. Guus

    two xeps? Styled spans, Styles blocks?

  516. Guus

    well, I'm going to pour myself a drink and call it a night :)

  517. Guus

    will lurk on mobile

  518. Guus


  519. SamWhited

    I suppose they don't all have to be a must; if the ``` blocks don't provide value for you, it's not like they'll look terrible if someone else sends you one and your client doesn't style it

  520. Ge0rG

    Can we have a language identifier right after the initial ``` ?

  521. Guus has left

  522. arc has left

  523. arc has joined

  524. SamWhited

    I don't think I'd want to call it a language identifier specifically, but maybe just say that the start of preformatted blocks is any line that matches ```.*\n and then clients that want to could assume it was a language thing

  525. Ge0rG

    SamWhited: call it a syntax hint, then it's sufficiently free form

  526. vanitasvitae has left

  527. Lance has joined

  528. jcbrand has joined

  529. Arc

    it rages on

  530. Valerian has left

  531. SamWhited

    Arc: It's all part of my secret plan to not be re-elected next term.

  532. Guus

    We'll punish you by reelecting you anyways.

  533. Valerian has joined

  534. Arc

    its true.

  535. Arc

    idk tho, 5 people must be elected to council.

  536. Arc

    you're easily one of the most qualified

  537. SamWhited

    heh, thanks… drat though, I guess I'll have to think up more controversial proposals to create right before the election

  538. efrit has joined

  539. jubalh has joined

  540. Kev

    I don't *think*, although I might misremember, that all the slots have to be filled.

  541. efrit has left

  542. efrit has joined

  543. pep. has joined

  544. efrit has left

  545. efrit has joined

  546. efrit has left

  547. efrit has joined

  548. jubalh has left

  549. jubalh has joined

  550. jjrh has left

  551. jubalh has left

  552. jubalh has joined

  553. jjrh has left

  554. jubalh has left

  555. jubalh has joined

  556. jubalh has left

  557. jubalh has joined

  558. Zash has left

  559. Valerian has left

  560. SamWhited has left

  561. jubalh has left

  562. jubalh has joined

  563. SamWhited has left

  564. jjrh has left

  565. jubalh has left

  566. jubalh has joined

  567. Zash has left

  568. marc has left

  569. jubalh has joined

  570. jubalh has joined

  571. jjrh has left

  572. jjrh has left

  573. jere has joined

  574. jubalh has left

  575. jubalh has joined

  576. jere has joined

  577. Valerian has joined

  578. jere has left

  579. jere has joined

  580. jubalh has left

  581. jubalh has joined

  582. uc has joined

  583. Zash has left

  584. uc has joined

  585. daniel has left

  586. jubalh has left

  587. jubalh has joined

  588. marc has left

  589. moparisthebest has joined

  590. uc has joined

  591. lovetox has left

  592. lovetox has joined

  593. jubalh has left

  594. jcbrand has left

  595. lovetox has left

  596. la|r|ma has left

  597. la|r|ma has joined

  598. daniel has left

  599. jjrh has left

  600. daniel has left

  601. daniel has joined

  602. Ge0rG has joined

  603. jere has left

  604. Zash has left

  605. SamWhited has joined

  606. SamWhited has joined

  607. Guus has left

  608. goffi has left