XSF Discussion - 2018-11-16

  1. mrdoctorwho has joined

  2. winfried has joined

  3. genofire has left

  4. marc has left

  5. genofire has left

  6. Zash has left

  7. lnj has left

  8. matlag has left

  9. thorsten has left

  10. thorsten has joined

  11. matlag has left

  12. matlag has left

  13. jjrh has left

  14. jjrh has left

  15. UsL has left

  16. UsL has joined

  17. Guus has left

  18. Guus has joined

  19. Guus has left

  20. lskdjf has left

  21. l has left

  22. Guus has joined

  23. efrit has joined

  24. Guus has left

  25. Guus has joined

  26. Guus has left

  27. Guus has joined

  28. guusdk has left

  29. guusdk has left

  30. guusdk has joined

  31. j.r has joined

  32. j.r has joined

  33. SamWhited has left

  34. Zash has left

  35. Guus has left

  36. Guus has joined

  37. Guus has left

  38. Guus has joined

  39. vanitasvitae has left

  40. vanitasvitae has joined

  41. lskdjf has joined

  42. Guus has left

  43. Guus has joined

  44. guusdk has left

  45. APach has left

  46. APach has joined

  47. Guus has left

  48. efrit has left

  49. matlag has left

  50. matlag has left

  51. Guus has joined

  52. matlag has left

  53. j.r has joined

  54. j.r has joined

  55. lskdjf has left

  56. waqas has joined

  57. j.r has joined

  58. j.r has joined

  59. vanitasvitae has left

  60. vanitasvitae has joined

  61. genofire has left

  62. Yagiza has joined

  63. lskdjf has left

  64. pep. has left

  65. Guus has left

  66. j.r has joined

  67. l has left

  68. j.r has joined

  69. waqas has left

  70. jjrh has left

  71. Str4tocaster has joined

  72. Nekit has joined

  73. Str4tocaster has left

  74. Str4tocaster has joined

  75. Guus has joined

  76. lnj has joined

  77. Nekit has left

  78. Nekit has joined

  79. Nekit has left

  80. Nekit has joined

  81. krauq has joined

  82. Str4tocaster has left

  83. Str4tocaster has joined

  84. Nekit has left

  85. Nekit has joined

  86. Nekit has left

  87. Nekit has joined

  88. lorddavidiii has joined

  89. rion has left

  90. Str4tocaster has left

  91. Str4tocaster has joined

  92. Str4tocaster has left

  93. Str4tocaster has joined

  94. Str4tocaster has left

  95. Str4tocaster has joined

  96. Str4tocaster has left

  97. Str4tocaster has joined

  98. goffi has joined

  99. lovetox has joined

  100. labdsf has left

  101. ThibG has joined

  102. ThibG has joined

  103. lovetox

    MattJ, this does not really answer the question for what you use it, i wonder too what use case this could have

  104. lovetox

    maybe something like teamwork, where different people in a groupchat can add stuff to a message?

  105. lovetox

    something like threads ^^

  106. lovetox

    seems converse shows now in front of every groupchat message a green checkmark i wonder what it means

  107. lnj has left

  108. Str4tocaster has left

  109. Str4tocaster has joined

  110. Nekit has left

  111. Nekit has joined

  112. lovetox

    hm we could use it for omemo because right now we cant send a message AND a httpupload link

  113. lovetox

    this way we could send pictures with comments but encrypted

  114. lovetox

    daniel ^

  115. pep.

    lovetox: it's 0184 I think, the checkmark

  116. lovetox

    i dont think so, that would make absolutly no sense at all

  117. lovetox

    i think it means the message was reflected by the muc

  118. lovetox

    but instead of now seeing on *every* message a green check mark, i would have opted for seeing a red mark for the 1 in 1000 messages that is not received because the muc is down or my connection

  119. guusdk has left

  120. guusdk has left

  121. Nekit has left

  122. Nekit has joined

  123. lovetox

    ok they recently added 0184

  124. lovetox

    wow now i know one of the 100 participants of this chat received my message

  125. lovetox


  126. Nekit has left

  127. Nekit has joined

  128. daniel

    I think in groups the checkmark should be generated by the reflection

  129. daniel

    That's how Conversations does it

  130. daniel

    In 1:1 it uses 184. In groups it's reflection. Same UI to the user

  131. MattJ

    Makes sense

  132. lovetox

    didnt look through the code, lets assume they did that 🙂

  133. Nekit has left

  134. Nekit has joined

  135. edhelas has left

  136. edhelas has joined

  137. Str4tocaster has left

  138. guusdk has left

  139. guusdk has joined

  140. Str4tocaster has joined

  141. Ge0rG

    daniel [08:07]: > In 1:1 it uses 184. In groups it's reflection. Same UI to the user Same in yaxim

  142. Zash has left

  143. remko has joined

  144. Str4tocaster has left

  145. Str4tocaster has joined

  146. jonas’

    MattJ, I’m asking because somebody is attempting to use attaching for quotations

  147. jonas’

    and I think that would lead to suboptimal UI if clients show the "quoting" message right below the other one

  148. jonas’

    (which is however a sensible UI for attachments)

  149. Zash has left

  150. Zash has left

  151. andy has joined

  152. lovetox

    we have some other xep for quoting

  153. lovetox

    references or something like that

  154. jonas’


  155. MattJ

    jonas’, I agree with you

  156. labdsf has joined

  157. jonas’

    MattJ, tell than to them: https://github.com/siacs/Conversations/issues/3125

  158. Zash has left

  159. MattJ


  160. jonas’

    MattJ, tell that to them: https://github.com/siacs/Conversations/issues/3125

  161. MattJ

    I think I have an outstanding diff for that XEP anyway

  162. jonas’

    granted, in my original critique I forgot to mention *how* clients display it

  163. jonas’

    ("out of order", which may be more grave than what sam expects)

  164. MattJ

    Don't have time today

  165. jonas’

    ah, right

  166. Zash has left

  167. Steve Kille has left

  168. Steve Kille has left

  169. Zash has left

  170. ralphm

    With the recent news around http/3, I was wondering if anyone here has thought about a QUIC binding for XMPP.

  171. Steve Kille has joined

  172. lnj has joined

  173. daniel has left

  174. lovetox has left

  175. flow

    ralphm, what would the advantages be, besides "it's http"?

  176. ralphm

    I'm especially interested in the decrease in required roundtrips and if it behaves more efficiently in mobile networks (compared to TCP).

  177. ThibG has left

  178. ThibG has joined

  179. ralphm

    I'm talking about QUIC, not http/3 (which is HTTP-over-QUIC).

  180. flow

    but isn't http-over-quic http/3?

  181. flow

    ahh now I got it

  182. flow

    don't we have most round trips on the xmpp protocol layer? I don't see how quic would e.g. decrease the SASL roundtips. But I'm curious if there are any other advantages of using quic, but right now, I can't think of any.

  183. daniel

    Doesn't quic have multipath tcp basically

  184. jonas’

    (because using multipath tcp directly would be too sane?)

  185. daniel

    So we wouldn't have to reauth after every network change

  186. lnj has left

  187. daniel

    > (because using multipath tcp directly would be too sane?) Nobody supports that and quic has the power of Google behind it

  188. ralphm

    Well, from what I understand, the initial setup, which incliudes TLS 1.3, would be a nice benefit.

  189. jonas’

    daniel, yes, talking about google etc. not using existing IETF standards and rolling their own instead

  190. daniel

    Right. But if you can't stop them you could at least benefit from it

  191. daniel

    (I don't actually have any stakes or opinion in Quic or xmpp over quic)

  192. flow

    ahh that multipath fature sure would be nice

  193. ralphm

    There's a nice picture here: https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/

  194. flow

    also it appears that XMPP over QUIC would be for most parts trivial

  195. flow

    like you could replace your languages Socket object with a QuicSocket object and be done

  196. ralphm

    I could also see a use for in-(quic)-band file transfers, but that's indeed a bit more advanced.

  197. Ge0rG

    ralphm: a mobile client has too many roundtrips to count, _after_ the TLS handshake

  198. Ge0rG

    ralphm: I made a proposal to have the client dump all desired connection state into bind2, and let the server figure out everything

  199. flow

    Ge0rG, but that is only true for the intital connection

  200. ralphm

    Ge0rG: I know this, but the SASL-2 suggestions from dwd could help with that.

  201. ralphm

    So sure, there's work to be done on both fronts

  202. flow

    if you mostly resume your xmpp connection using quic the round trips should go down to near zero

  203. Ge0rG

    flow: 0198 also has a bunch of round-trips, at least the one you need to ensure whether the session got resumed

  204. flow

    Ge0rG, I dunno if xep198 would be that involved when using quic

  205. flow

    hmm it also appwars that quic is a IETF thing, at least there appears to be an IETF WG

  206. daniel

    > Ge0rG, I dunno if xep198 would be that involved when using quic At least the resume part

  207. daniel

    You'd still need the acks

  208. flow

    daniel, do you?

  209. flow

    I mean there are still nice

  210. daniel

    I don't think quic has acks

  211. flow

    but if the resumption of the stream is performed on the quic layer, without the upper layers being bothered

  212. flow

    hmm I though quic has stream properties, but could be wrong

  213. Ge0rG

    you know, TCP has got acks, and if we had sane APIs instead of Unix sockets, we could actually query the TCP ack state from the OS and not need 0198 acks.

  214. flow

    true, that is why I said acks are still nice, but I'm not sure if you still need xep198 resumption when using quic to handle a network switch

  215. flow

    I also believe that unix sockets are sane APIs and that you don't get nothing by checking the TCP ack state

  216. flow

    cause eventually you want application protocol acks, which tcp acks are not

  217. ralphm

    I guess that's the upshot of QUIC, it moves this to userland.

  218. jonas’

    yes, because re-implementing decade-proven stuff in userland is always good /s

  219. ralphm

    yes, because re-thinking decade-proven stuff is never a viable approach.

  220. vaulor has joined

  221. Ge0rG

    it's not about re-thinking it but about working around limitations in its entrenched implementation

  222. alacer has joined

  223. lovetox has joined

  224. Alex has joined

  225. tux has left

  226. ralphm

    Indeed. I think QUIC is a very interesting development, and was just curious if it could benefit XMPP, too.

  227. blabla has left

  228. Ge0rG

    somebody should do a quic prototype.

  229. guusdk has left

  230. guusdk has joined

  231. daniel

    Ge0rG: I see what you did there

  232. Maranda has left

  233. Maranda has joined

  234. Guus

    Hey, my summit announcement blogpost didn't pop up in the blog. Did I mess something up?

  235. ralphm

    There are some interesting comments about QUIC here: https://www.codavel.com/2018/09/17/quic-vs-tcptls-and-why-quic-is-not-the-next-big-thing/. Despite the title, it seems the benefits for something like XMPP might be greater than for HTTP.

  236. alacer has left

  237. Ge0rG

    surprisingly, HTTP is slowly approching XMPP, protocol-wise

  238. blabla has left

  239. Zash has left

  240. Str4tocaster has left

  241. Str4tocaster has joined

  242. Str4tocaster has left

  243. Str4tocaster has joined

  244. ralphm has joined

  245. flow

    not sure if I'd call it surprisingly, but true, true

  246. Zash

    HTTP/2 seems an awful lot like SSH

  247. rion has left

  248. alacer has joined

  249. blabla has joined

  250. blabla has left

  251. blabla has joined

  252. Ge0rG

    And WS is a TCP socket exchanging framed messages.

  253. vaulor has joined

  254. Zash


  255. Str4tocaster has left

  256. Str4tocaster has joined

  257. Str4tocaster has left

  258. Str4tocaster has joined

  259. Str4tocaster has left

  260. Str4tocaster has joined

  261. Str4tocaster has left

  262. Str4tocaster has joined

  263. Str4tocaster has left

  264. Str4tocaster has joined

  265. Str4tocaster has left

  266. Str4tocaster has joined

  267. daniel has left

  268. tux has left

  269. blabla has left

  270. blabla has joined

  271. blabla has left

  272. blabla has joined

  273. blabla has left

  274. blabla has joined

  275. Str4tocaster has left

  276. Str4tocaster has joined

  277. lumi has joined

  278. blabla has left

  279. Str4tocaster has left

  280. Str4tocaster has joined

  281. moparisthebest has left

  282. Str4tocaster has left

  283. Str4tocaster has joined

  284. Str4tocaster has left

  285. Str4tocaster has joined

  286. valo has joined

  287. valo has joined

  288. Str4tocaster has left

  289. Str4tocaster has joined

  290. Zash has left

  291. Zash has left

  292. Str4tocaster has left

  293. Str4tocaster has joined

  294. lovetox has left

  295. Str4tocaster has left

  296. Str4tocaster has joined

  297. Str4tocaster has left

  298. Str4tocaster has joined

  299. Str4tocaster has left

  300. Str4tocaster has joined

  301. ralphm

    Like Beep

  302. Zash has left

  303. guusdk has left

  304. blabla has left

  305. blabla has joined

  306. rion has left

  307. Andrew Nenakhov has left

  308. Andrew Nenakhov has joined

  309. blabla has left

  310. j.r has left

  311. Alex has left

  312. Yagiza has left

  313. Str4tocaster has left

  314. Str4tocaster has joined

  315. Holger has left

  316. blabla has joined

  317. lovetox has joined

  318. j.r has joined

  319. Str4tocaster has left

  320. Str4tocaster has joined

  321. Str4tocaster has left

  322. Str4tocaster has joined

  323. daniel has left

  324. Str4tocaster has left

  325. Str4tocaster has joined

  326. blabla has left

  327. blabla has left

  328. MattJ

    Hmm, not sure I see the benefits of QUIC specifically

  329. alacer has left

  330. MattJ

    ...given in-order requirements in XMPP, and a single stream between client and server

  331. Zash

    Something something having two channels could be useful for large binary low-priority transfers

  332. Zash

    SCTP :(

  333. MattJ

    RTT reduction is already possible without QUIC, and changing IP is just 198

  334. jonas’


  335. MattJ


  336. fippo

    mattj: do you work at google? they seem to think that way

  337. matlag has left

  338. MattJ

    fippo: regarding SCTP? I tried to keep the dream alive for quite some time, but short of renaming to HTTP/4, it's never going to see sensible adoption

  339. jonas’


  340. Zash

    MattJ: Could change IP with less overhead if MPTCP got done and deployed

  341. Zash

    Oh and SCTP is deployed and used! .. in WebRTC

  342. Zash

    SCTP over DTLS over UDP

  343. jonas’


  344. fippo

    well, google wants to kill that

  345. fippo

    and usrsctp is the only usable library and has funding issues :-|

  346. fippo

    I think mattias wimmer (of jabberd1) once proposed s2s over sctp...

  347. j.r has joined

  348. j.r has joined

  349. Str4tocaster has left

  350. Str4tocaster has joined

  351. flow

    MattJ, I'm not sure, but QUIC could get you free instant stream resumption it appears

  352. flow

    and i'm not sure how xmpp's in-order requirement is related to quic

  353. MattJ

    QUIC's main purpose is multiplexing without head-of-line blocking. XMPP needs neither of those

  354. MattJ

    The other things QUIC provides can be done with TCP

  355. flow

    you mean "on top of TCP"

  356. MattJ


  357. flow

    sure, but quic gives you resumption for free

  358. MattJ

    So instead of reimplementing TCP semantics on top of UDP

  359. flow

    you don't have to implement xep198 resumption

  360. Zash

    MPTCP would also give you that

  361. flow

    probably, in the end the surviver will likely be the thing with widely available libraries

  362. flow

    and which works in the current IP environment

  363. MattJ

    Which QUIC is not from a glance

  364. flow

    (in reality, and not on paper)

  365. Zash

    XMPP over HTTP over QUIQ over DTLS over UDP with ugly hacks to make it look like plain text DNS?

  366. flow

    quic libraries seem to be sparse, true

  367. Zash

    flow: Do you think we should just go along with stupid things like that or try to do it right? Because I want to do things right.

  368. flow

    but it doesn't appear to be unlikely that there will be some for android (and java), possibly even from google itself

  369. flow

    Zash, well, doing things right is usually what one should do, but I don't see how quic is doing things wrong, feel free to feed me the missing pieces

  370. Zash

    I haven't looked at QUIC recently, but isn't it supposed to be a transport protocol? So, running it over another transport protocol is meh

  371. Alex has joined

  372. waqas has joined

  373. flow

    I don't see a point for sticking to the OSI model just for the sake of it

  374. flow

    it appears sensible to run such a thing over udp

  375. Zash

    HTTP over UDP was a thing already tho

  376. flow

    "it breaks layering" is never a good argument, unless it is followed by an argument why it is bad

  377. daniel

    Or what layers are

  378. Zash has left

  379. Guus

    An Ogre is like an onion...

  380. flow

    right now I think of quick as an TCP socket on steriods with tls, compression, automatic resumption in case of connectivity/network change

  381. flow

    and looking at the XEPs we have, those are propertys XMPP also wants

  382. flow

    it is true that XMPPs doesn't need quic's multiplexing feature, but, yah know, nobody forces you to use it

  383. flow

    then again, didn't we have a XEP (or ProtoXEP) which multiplexes multiple sessions over the same stream?

  384. Nekit has left

  385. Nekit has joined

  386. mimi89999 has joined

  387. mimi89999 has joined

  388. jonas’

    for s2s

  389. Str4tocaster has left

  390. ralphm

    MattJ: flow, of course the number of libraries is still a bit sparse. QUIC is not even finished yet.

  391. Yagiza has joined

  392. ralphm

    And to be sure, Google QUIC was taken apart to IETF QUIC (with a handful of specs) + HTTP-on-QUIC.

  393. j.r has joined

  394. ralphm

    Some background here: https://blog.cloudflare.com/the-road-to-quic/

  395. Zash has left

  396. MattJ has joined

  397. guusdk has left

  398. guusdk has joined

  399. Andrew Nenakhov has left

  400. daniel has left

  401. Andrew Nenakhov has joined

  402. Andrew Nenakhov has joined

  403. blabla has left

  404. Zash has left

  405. marc has joined

  406. moparisthebest has joined

  407. moparisthebest has left

  408. moparisthebest has joined

  409. labdsf has left

  410. labdsf has joined

  411. matlag has left

  412. rion has left

  413. andy has left

  414. vanitasvitae has left

  415. Holger has left

  416. guusdk has left

  417. guusdk has joined

  418. blabla has joined

  419. krauq has left

  420. waqas has left

  421. tux has joined

  422. krauq has joined

  423. lskdjf has left

  424. vanitasvitae has left

  425. lskdjf has joined

  426. genofire has left

  427. genofire has left

  428. lskdjf has joined

  429. Alex has joined

  430. genofire has joined

  431. winfried has joined

  432. genofire has left

  433. genofire has joined

  434. Steve Kille has joined

  435. Kev has joined

  436. Kev has joined

  437. Kev has joined

  438. Steve Kille has joined

  439. Steve Kille has left

  440. Kev has joined

  441. Steve Kille has joined

  442. jonas’

    Guus, I think I know what went wrong with your blog post

  443. jonas’

    it went into some "drafts" folder

  444. jonas’

    my suspicion is that it treated the publish timestamp as UTC, and since that was greater than the time of the build, it treated it as unpublished draft

  445. jonas’

    I retriggered the build

  446. Guus

    ah, I didn't take notice much of the timestamp

  447. jonas’

    (you can see that it went into some draft folder by searching this https://hub.docker.com/r/xmppxsf/xmpp.org/builds/bgajpfwqegw7nfzcthinnui/ for the file name)

  448. jonas’

    (and you can find the build by clicking the "docker|building" tag thing in the readme after a merge)

  449. Guus

    That's some kind of implementation that can be used to schedule posts, then?

  450. jonas’

    it could, if we had automatic rebuilds

  451. Guus

    well, thanks for figuring that one out 🙂

  452. jonas’

    you’re welcome

  453. jonas’

    thanks for boarding :)

  454. Guus

    where are my warm nuts?

  455. jonas’

    I have questions about that question

  456. Guus

    wait, don't answer that one.

  457. jonas’

    it’s either delicious or TMI

  458. Guus

    I _just_ realised.

  459. l has left

  460. jonas’

    and here I was wondering which double-entendre I could’ve missed in "thanks for boarding" which doesn’t go into the direction of airplanes or torture.

  461. Guus

    Ok, I'm off to pick up my kids from daycare, before I make more of a fool of myself here. 🙂

  462. jonas’

    good luck!

  463. Alex has left

  464. Guus

    (I shall be making a fool of myself elsewhere now)

  465. jonas’

    you’ll blend in

  466. guusdk has left

  467. guusdk has joined

  468. Yagiza has left

  469. guusdk has left

  470. lumi has left

  471. guusdk has left

  472. guusdk has joined

  473. waqas has joined

  474. Steve Kille has left

  475. ThibG has joined

  476. ta has joined

  477. ralphm has joined

  478. lskdjf has left

  479. mightyBroccoli has left

  480. alexde has joined

  481. marc has left

  482. marc has joined

  483. lnj has joined

  484. alexde has left

  485. APach has left

  486. Link Mauve

    SCTP got some adoption as part of WebRTC, but now there are discussions about replacing it with QUIC too.

  487. jonas’

    Guus, your blog post is up :)

  488. Link Mauve

    At the last Rustfest in Paris, there was someone working on a QUIC parser, but I don’t remember who, nor what kind of milestone they reached.

  489. tux has joined

  490. pep.

    Yeah I remember one guy implementing a bunch of stuff from the spec during the impl days

  491. matlag has left

  492. mightyBroccoli has joined

  493. lumi has joined

  494. matlag has left

  495. tux has left

  496. tux has joined

  497. guusdk has left

  498. guusdk has joined

  499. SamWhited has left

  500. ta has left

  501. tux has joined

  502. Ge0rG has left

  503. lorddavidiii has left

  504. Lance has joined

  505. tux has joined

  506. APach has joined

  507. lorddavidiii has joined

  508. sonny has left

  509. sonny has joined

  510. tux has joined

  511. tux has joined

  512. labdsf has left

  513. APach has left

  514. APach has joined

  515. mimi89999 has left

  516. lskdjf has left

  517. lskdjf has left

  518. matlag has left

  519. lskdjf has joined

  520. Yagiza has joined

  521. Yagiza has left

  522. ralphm

    Link Mauve: I also found this https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-02, and https://w3c.github.io/webrtc-quic/

  523. genofire has left

  524. Yagiza has joined

  525. ralphm

    I.e. the QUIC WG actually made changes to the initial packet byte to accomodate multiplixing with RTP/STUN/etc.

  526. tux has joined

  527. ralphm has left

  528. mimi89999 has left

  529. ThibG has joined

  530. ThibG has joined

  531. blabla has left

  532. vaulor has joined

  533. peter has joined

  534. Guus

    jonas’: tx!

  535. labdsf has joined

  536. Steve Kille has left

  537. Steve Kille has left

  538. blabla has left

  539. blabla has joined

  540. Steve Kille has joined

  541. guusdk has left

  542. guusdk has joined

  543. labdsf has left

  544. vaulor has joined

  545. labdsf has joined

  546. Steve Kille has left

  547. Lance has left

  548. marc has left

  549. Alex has joined

  550. guusdk has joined

  551. l has joined

  552. marc has joined

  553. daniel has left

  554. Neustradamus has left

  555. daniel has joined

  556. waqas has left

  557. rion has left

  558. Lance has joined

  559. Lance has left

  560. Lance has joined

  561. blabla has joined

  562. marc has left

  563. matlag has left

  564. alacer has joined

  565. alacer has left

  566. alacer has joined

  567. Lance has left

  568. Lance has joined

  569. Zash has left

  570. Lance has left

  571. Lance has joined

  572. alacer has left

  573. peter has left

  574. l has joined

  575. l has joined

  576. lskdjf has joined

  577. guusdk has left

  578. guusdk has joined

  579. Guus has left

  580. guusdk has left

  581. lskdjf has joined

  582. lskdjf has joined

  583. SamWhited has left

  584. thorsten has joined

  585. Lance has left

  586. labdsf has left

  587. labdsf has joined

  588. l has joined

  589. l has joined

  590. lskdjf has left

  591. lskdjf has joined

  592. l has joined

  593. Alex has left

  594. lorddavidiii has left

  595. lorddavidiii has joined

  596. Nekit has joined

  597. Lance has joined

  598. lskdjf has joined

  599. valo has joined

  600. Yagiza has left

  601. lskdjf has left

  602. lskdjf has joined

  603. thorsten has left

  604. goffi has left

  605. APach has left

  606. APach has joined

  607. lskdjf has joined

  608. lskdjf has joined

  609. matlag has left

  610. winfried has left

  611. winfried has joined

  612. ThibG has left

  613. ThibG has joined

  614. remko has left

  615. Guus has left

  616. blabla has left

  617. lskdjf has left

  618. Alex has joined

  619. lskdjf has joined

  620. tux has joined

  621. lskdjf has joined

  622. lskdjf has joined

  623. valo has joined

  624. ta has left

  625. lskdjf has joined

  626. lskdjf has joined

  627. ta has left

  628. ta has left

  629. ta has left

  630. thorsten has joined

  631. peter has joined

  632. lskdjf has joined

  633. lskdjf has joined

  634. lskdjf has joined

  635. lskdjf has joined

  636. ta has left

  637. j.r has left

  638. j.r has joined

  639. waqas has joined

  640. Alex has left

  641. peter has left

  642. j.r has joined

  643. j.r has joined

  644. ta has left

  645. Holger has left

  646. ta has left

  647. ta has left

  648. ta has left

  649. vanitasvitae has left

  650. vanitasvitae has joined

  651. waqas has left

  652. waqas has joined

  653. moparisthebest has joined

  654. lorddavidiii has left

  655. matlag has left

  656. rion has left

  657. ThibG has joined

  658. Lance has left

  659. waqas has left

  660. matlag has left

  661. l has left

  662. lskdjf has left

  663. lskdjf has joined

  664. ThibG has joined

  665. Lance has joined

  666. rion has left

  667. matlag has left

  668. moparisthebest has joined

  669. Lance has left

  670. lnj has left

  671. moparisthebest has left

  672. moparisthebest has joined

  673. matlag has left

  674. guusdk has left

  675. lovetox_ has joined

  676. matlag has left

  677. MattJ has joined

  678. ThibG has left

  679. ThibG has joined

  680. matlag has left

  681. thorsten has left

  682. thorsten has joined