jdev - 2021-12-17


  1. sonny has left

  2. sonny has joined

  3. mac has left

  4. mac has joined

  5. kikuchiyo has left

  6. Zash has left

  7. Zash has joined

  8. tom has left

  9. dezant has left

  10. debacle has left

  11. moparisthebest has joined

  12. marc0s has left

  13. marc0s has joined

  14. kikuchiyo has joined

  15. edhelas has left

  16. edhelas has joined

  17. edhelas has left

  18. edhelas has joined

  19. Zash has left

  20. Zash has joined

  21. dezant has joined

  22. Pete has left

  23. Kev has left

  24. Kev has joined

  25. Pete has joined

  26. cypherred has joined

  27. cypherred has left

  28. Kev has left

  29. Kev has joined

  30. mac has left

  31. mac has joined

  32. Zash has left

  33. Yagizа has joined

  34. Zash has joined

  35. jgart has left

  36. dezant has left

  37. SouL has joined

  38. kikuchiyo has left

  39. kikuchiyo has joined

  40. al has joined

  41. jgart has joined

  42. mac has left

  43. mac has joined

  44. jgart has left

  45. marc0s has left

  46. marc0s has joined

  47. Zash has left

  48. COM8 has joined

  49. me9 has joined

  50. pasdesushi has joined

  51. Zash has joined

  52. kikuchiyo has left

  53. kikuchiyo has joined

  54. COM8 has left

  55. COM8 has joined

  56. COM8 has left

  57. COM8 has joined

  58. COM8 has left

  59. COM8 has joined

  60. COM8 has left

  61. xecks has left

  62. xecks has joined

  63. wurstsalat has joined

  64. emus has joined

  65. pasdesushi has left

  66. msavoritias has joined

  67. hiran has left

  68. me9 has left

  69. pasdesushi has joined

  70. al has left

  71. marc0s has left

  72. marc0s has joined

  73. marc0s has left

  74. marc0s has joined

  75. marc0s has left

  76. marc0s has joined

  77. marc0s has left

  78. marc0s has joined

  79. kikuchiyo has left

  80. kikuchiyo has joined

  81. Yagizа has left

  82. pulkomandy has left

  83. pulkomandy has joined

  84. marc0s has left

  85. marc0s has joined

  86. Zash has left

  87. pulkomandy has left

  88. sonny has left

  89. sonny has joined

  90. sonny has left

  91. sonny has joined

  92. goffi has joined

  93. sonny has left

  94. sonny has joined

  95. Zash has joined

  96. kikuchiyo has left

  97. sonny has left

  98. sonny has joined

  99. sonny has left

  100. sonny has joined

  101. marc0s has left

  102. marc0s has joined

  103. debacle has joined

  104. kikuchiyo has joined

  105. moparisthebest has left

  106. moparisthebest has joined

  107. jgart has joined

  108. marc0s has left

  109. marc0s has joined

  110. mac has left

  111. moparisthebest has left

  112. al has joined

  113. debacle has left

  114. defanor

    Were there attempts to write down a collective wish list for a reusable library's properties (except for compliance)? I'm working on one too, and trying to make it reusable, but I have a lingering suspicion that it may miss properties important to others. The main properties I've picked are an asynchronous C API and letting a program to work with XML directly (including hooks for sending/receiving, optionally telling the library to not send/process those).

  115. Kev

    The whole XML thing is really debatable.

  116. Kev

    If you have an abstraction in the library, users don't have to know how XMPP is represented on the wire, only the semantics - clearly good. OTOH, abstracting away the XML makes it that little bit harder to deal with the XML when you want to do something not yet supported by the library.

  117. Kev

    I don't think either is clearly better (although an abstraction without a way to add your own payloads is clearly a problem), they both have drawbacks.

  118. defanor

    I figured that XML (and flexibility in general) is important for reusability, while convenience functions abstracting it can be sprinkled on top later (though already doing that for some of the more cumbersome to compose bits).

  119. sonny has left

  120. sonny has joined

  121. sonny has left

  122. sonny has joined

  123. flow has joined

  124. Martin has left

  125. Martin has joined

  126. al has left

  127. atomicwatch has left

  128. atomicwatch has joined

  129. antranigv has left

  130. antranigv has joined

  131. COM8 has joined

  132. COM8 has left

  133. COM8 has joined

  134. COM8 has left

  135. antranigv has left

  136. sonny has left

  137. sonny has joined

  138. contrapunctus

    As it happens, I've never done any XMPP-related development before. Apart from the client library, the other project I was interested in was an XMPP-IRC bridge (which, unlike Biboumi, connects an MUC with an IRC room and lets users participate in the same conversation from either protocol)...would that be a suitable project to gain XMPP development experience?

  139. sonny has left

  140. sonny has joined

  141. jonas’

    it is certainly more well-scoped

  142. jonas’

    but it has some issues on the IRC side, I think

  143. jonas’

    as IRC isn't federated

  144. rafasaurus has left

  145. contrapunctus

    jonas’: Hm...how does that affect a bridge? 🤔️

  146. goffi has left

  147. rafasaurus has joined

  148. jonas’

    contrapunctus, how are IRC users going to interact with a bridge?

  149. flow

    contrapunctus, such XMPP-IRC MUC↔IRC-Channel bridges already exist, we use one. It's basically a bot that joins both rooms and forwards the messages

  150. jonas’

    flow, bots are not bridges!

  151. jonas’

    they are terrible and we should stop praising them ;)

  152. flow

    maybe, but it works

  153. contrapunctus

    flow: are users on both sides visible to the other side?

  154. flow

    although yes, the main problem is that you don't know who is on the other side

  155. flow

    but I am not sure if you can solve that

  156. flow

    maybe on the XMPP side, but on the IRC side that would mean creating accounts on demand

  157. flow

    and IRC networks haven often strong countermeasure against multiple accounts from the same IP

  158. flow

    and IRC networks haven often strong countermeasures against multiple accounts from the same IP

  159. jonas’

    ^ unless you happen to be an IRC server

  160. jonas’

    hence, the point about federation

  161. flow

    yeah, but you don't become an IRC server easily, at least in IRCNet, Libera and OFTC

  162. jonas’

    also the channel namespace

  163. jonas’

    flow, you can easily become an IRC server -- by being one. but that then means that IRC users have to log into your single-server network

  164. jonas’

    (mod_irc?!)

  165. contrapunctus

    Or...asking the IRC admins to permit multiple accounts from your XMPP server?

  166. jonas’

    contrapunctus, where is the difference to the biboumi model then?

  167. flow

    contrapunctus, I doublt that any IRC operator would aggree to this

  168. jonas’

    flow, you're wrong about that

  169. flow

    because then their countermeasures could be circumvented by any xmpp server

  170. jonas’

    I have allowlisting for my biboumi instance with at least ircnet

  171. defanor

    Is it what Matrix is doing on Libera? There's a lot of users with [m] suffixes in their names.

  172. contrapunctus

    ^

  173. MattJ

    No

  174. jonas’

    flow, I had allowlisting with freenode, though they require you to run identd for bans

  175. MattJ

    The Libera staff have consistently denied s2s-level access to their network for bridging purposes

  176. MattJ

    IRC s2s is not like XMPP s2s, each server has significant power over the network, and they don't want third-party code with that power

  177. flow

    contrapunctus, in any case, you want to reach out to IRC operators and clarify what, if anything, and how they would allow multiple connections before starting to code

  178. jonas’

    MattJ, but matrix has an allowlisting for number of connections, which is what the question was about?

  179. flow

    don't get me wrong, it's not that I wouldn't welcome a proper IRC↔XMPP bridge

  180. jonas’

    contrapunctus, so, which downsides do you see with the biboumi approach which you'd like to fix, and how?

  181. flow

    and researching what matrix does seems like a good starting point

  182. MattJ

    jonas’, okay, I guess I skimmed the backlog too quickly, I was triggered by "you can easily become an IRC server"

  183. jonas’

    MattJ, oh you can, by running your own single-server network ;)

  184. jonas’

    (which is what I meant)

  185. inky has joined

  186. goffi has joined

  187. jonas’

    so a thing which exposes an IRC c2s interface on the one side (mimicing a single-node network) and an XMPP component interface implementing MUC on the other side would work

  188. flow

    jonas’, biboumi is an XMPP component on the users XMPP service, right?

  189. jonas’

    with the downsides of restricting everyone of the lowest common denominator of IRC (think usernames, rich messages etc.)

  190. MattJ

    Matrix is just allowed to have many connections. They give each connected user a unique IPv6 address in an agreed block, and have an agreed ident string

  191. jonas’

    flow, on *some users XMPP service, yes

  192. flow

    jonas’, then one advantage over the biboumi approach would be that you don't need such a component at all (irregardless where it runs)

  193. jonas’

    flow, well, you need a component which does the bridging

  194. contrapunctus

    jonas’: In the Biboumi approach, communities are divided rather than connected. I want to bridge some MUCs to some IRC channels, have users on both sides see each other, and users on the XMPP side see each others' status, avatars, typing notifications, read markers etc.

  195. flow

    you simply join the superchat@chat.example.org and be in a room with people from #superchat @ libera

  196. contrapunctus

    jonas’: In the Biboumi approach, communities stay divided rather than being connected. I want to bridge some MUCs to some IRC channels, have users on both sides see each other, and users on the XMPP side see each others' status, avatars, typing notifications, read markers etc.

  197. jonas’

    contrapunctus, so you just need to extend biboumi to broadcast the XMPP magic to all connected users instead of using the IRC reflection?

  198. jonas’

    contrapunctus, so you just need to extend biboumi to broadcast the XMPP magic to all connected XMPP users instead of using the IRC reflection?

  199. jonas’

    (for which there is an issue I think but it simply hasn't been implemented)

  200. flow

    and the number of the entitys in the room would be the same when the bridged room is viewed from both networks

  201. jonas’

    flow, you can have that today -- join #yaook%irc.oftc.net@irc.jabberfr.org ;). It's a MUC, but you can also join it from IRC ;)

  202. flow

    jonas’, and that's the technical setup behind this?

  203. jonas’

    biboumi is

  204. flow thinks

  205. flow

    so if I join that MUC, then an IRC user is connected simultaneously?

  206. jonas’

    yes

  207. flow

    ahh I wasn't aware that this wroks

  208. flow

    ahh I wasn't aware that this wroks

  209. flow

    ahh I wasn't aware that this works

  210. jonas’

    that's just how biboumi works ;)

  211. flow

    and vica versa for IRC users joining the channel?

  212. jonas’

    yep

  213. flow

    I always thought of biboumi if a personal gateway

  214. flow

    but I've to admint, I never used it. but that could change

  215. jonas’

    the only difference between that and a normal MUC is that XMPP specific protocols are mostly discarded (avatars, typing notifications etc.) and that biboumi will split overlong messages.

  216. flow

    jonas’, dou you know if this required any interaction with OFTC operators to setup up?

  217. jonas’

    not if you have only have one or two XMPP-side users on your instance

  218. jonas’

    if you have more, you'll probably want to talk to them to agree on a model which scales for ident purposes

  219. jonas’

    my personal instance doesn't have many connections to OFTC, so I didn't bother

  220. jonas’

    (I did bother for IRCnet though)

  221. jonas’

    (where I just talked to one of the admins and got a something-line which granted me a higher limit)

  222. contrapunctus

    > contrapunctus, so you just need to extend biboumi to broadcast the XMPP magic to all connected XMPP users instead of using the IRC reflection? jonas’: wouldn't that mean all XMPP users are joining the IRC room, rather than my description of "bridging an MUC and an IRC room"? The benefit of the latter is, people can jump ship from IRC to XMPP without losing their community.

  223. flow

    I see, very interesting, thanks!

  224. jonas’

    contrapunctus, what is the difference?

  225. jonas’

    the practical difference

  226. jonas’

    it is a MUC on the XMPP side and a channel on the IRC side

  227. jonas’

    (except for the broadcast of XMPP magic, which could "easily" be implemented in biboumi)

  228. marc0s has left

  229. marc0s has joined

  230. contrapunctus

    and this MUC exists independently of the IRC channel? e.g. what happens if the IRC server goes down, or the IRC channel is destroyed?

  231. pep.

    > jonas’> (for which there is an issue I think but it simply hasn't been implemented) I remember some backlash against that

  232. jonas’

    contrapunctus, ah, then it's gone :)

  233. jonas’

    contrapunctus, if you want to avoid that, then yeah, the model needs to change so that the bridge component uses an existing MUC service (which it could and maybe should implement/provide on its own, but doesn't have to) instead of implementing MUC

  234. jonas’

    that would also solve the XMPP magic broadcast, but comes with other challenges (mapping usernames between protocols, reserving usernames across protocols etc.)

  235. toz has joined

  236. jonas’

    the advantage of the biboumi model in that regardis that the "primary" copy of the room lives on the protocol with the lower amount of features, i.e. biboumi can enforce, on the high-feature side, that clients don't make use of those features (spaces in nicknames)

  237. jonas’

    that would need cooperation from the MUC service in the other model

  238. jonas’

    the biboumi model also means that users can more directly interact with IRC, e.g. to place bans, run IRC-specific commands or to authenticate with NickServ

  239. jonas’

    much of which is only partially standardized and cannot be dealt with in a generic way in a bridge

  240. inky has left

  241. debacle has joined

  242. Zash

    Bot bridge but multiple puppets?

  243. contrapunctus

    I guess I'll start by implementing an MUC service as a learning project...it seems to be a common factor...

  244. antranigv has joined

  245. jonas’

    contrapunctus, that sounds like a reasonable way to learn XMPP

  246. Zash

    Or some sort of FMUC/DMUC with IRC as one peer?

  247. jonas’

    mmmm let biboumi instances speak f-muc with each other

  248. jonas’

    ^5 Zash

  249. Zash

    **5

  250. jonas’

    why not xor 0b101?

  251. moparisthebest has joined

  252. jonas’

    contrapunctus, another bit to think about: if the IRC server goes down, what to do with XMPP messages sent in the meantime? lost to IRC users? probably ok, they're used to netsplits :)

  253. Zash

    ^ is power to me

  254. Zash

    Hm, why did I not read that as 'starts with 5' when coming from the sed master?

  255. antranigv has left

  256. antranigv has joined

  257. toz has left

  258. Kev

    FWIW, the M-Link IRC gateway works by bridging a MUC and an IRC channel, so anyone in either sees anyone in the other. It's much harder to deal with than a traditional 'join an IRC channel that looks like a MUC' gateway.

  259. debacle has left

  260. moparisthebest has left

  261. contrapunctus

    Kev: I see...by "much harder to deal with", do you mean for users, administrators, or the gateway authors?

  262. Kev

    Gateway authors.

  263. Kev

    And it needs the IRC server to be amenable to that many connections from the XMPP server.

  264. sonny has left

  265. sonny has joined

  266. mac has joined

  267. moparisthebest has joined

  268. edhelas has left

  269. edhelas has joined

  270. nephele has joined

  271. inky has joined

  272. sonny has left

  273. sonny has joined

  274. kikuchiyo has left

  275. marc0s has left

  276. marc0s has joined

  277. mac has left

  278. mac has joined

  279. kikuchiyo has joined

  280. antranigv has left

  281. antranigv has joined

  282. inky has left

  283. antranigv has left

  284. jgart has left

  285. Zash has left

  286. Zash has joined

  287. antranigv has joined

  288. rafasaurus has left

  289. antranigv has left

  290. rafasaurus has joined

  291. jgart has joined

  292. mac has left

  293. mac has joined

  294. inky has joined

  295. Ingolf has left

  296. Ingolf has joined

  297. me9 has joined

  298. contrapunctus

    Is a gateway/transport just a particular kind of component?

  299. antranigv has joined

  300. Kev

    They are often implemented as components, although don't need to be.

  301. Kev

    (And are the most common form of component)

  302. Zash

    Maybe you could say that gateway/transport is a role, component is a method of connecting to a server

  303. Zash

    A bot, connected as any other client, can have that role.

  304. Zash

    You can also do it with s2s connections

  305. Zash

    Or as an internal plugin in the sersver

  306. Zash

    Or as an internal plugin in the server

  307. contrapunctus

    Makes sense, thanks.

  308. edhelas has left

  309. edhelas has joined

  310. inky has left

  311. dezant has joined

  312. kikuchiyo has left

  313. mac has left

  314. mac has joined

  315. marc0s has left

  316. marc0s has joined

  317. sonny has left

  318. sonny has joined

  319. Alex has left

  320. Alex has joined

  321. antranigv has left

  322. antranigv has joined

  323. COM8 has joined

  324. COM8 has left

  325. COM8 has joined

  326. COM8 has left

  327. inky has joined

  328. kikuchiyo has joined

  329. COM8 has joined

  330. COM8 has left

  331. al has joined

  332. marc0s has left

  333. marc0s has joined

  334. marc0s has left

  335. marc0s has joined

  336. Wojtek has joined

  337. marc0s has left

  338. marc0s has joined

  339. marc0s has left

  340. marc0s has joined

  341. mac has left

  342. mac has joined

  343. marc0s has left

  344. marc0s has joined

  345. al has left

  346. xecks has left

  347. xecks has joined

  348. pulkomandy has joined

  349. me9 has left

  350. dezant has left

  351. pulkomandy has left

  352. pulkomandy has joined

  353. debacle has joined

  354. pulkomandy has left

  355. pulkomandy has joined

  356. dezant has joined

  357. marc0s has left

  358. marc0s has joined

  359. pulkomandy

    I think the mod_irc way makes sense (muc hosted on xmpp and happens to also be exported as a non-federated irc server). irc is already so fragmented that irc users won't mind joining yet another irc network (that just happens to in fact be the xmpp network)

  360. mac has left

  361. Zash

    pulkomandy, don't mention that horror plz

  362. pulkomandy

    Until this happens, biboumi will do

  363. Kev

    It depends heavily on the reason people want an IRC bridge. There are (non-theoretical) situations where that model would make sense. There are also situations where it doesn't work at all.

  364. Zash

    Dealing with the differences between IRC and MUC is ... painful. Beware!

  365. Zash

    You'd probably have to enforce all IRC restrictions on MUC for it to work.

  366. Kev

    I actually think XMPP Server acting as an IRC server is the easiest of the models to make work sensibly.

  367. Zash

    Having been part of an attempt at this, that was not my experience.

  368. pulkomandy

    It depends how good you want the experience to be for the irc users, I guess

  369. Zash

    I think you just end up writing an IRC server that happens to talk a restricted subset of XMPP

  370. pulkomandy

    If you look at how Matrix does it (even when they just bridge their users to an existing irc): long messages get transformed to a link to their http server, that irc users need to click

  371. pulkomandy

    If a discussion is made mostly of long messages it gets v annoying very quickly

  372. Holger

    .oO( https://github.com/processone/ejabberd-contrib/tree/master/ircd doesn't seem to be super-actively maintained these days ... )

  373. Kev

    Zash: Interesting. I thought IRCv3 would cover quite a lot of things to make it not horrible.

  374. Zash

    Kev: Mmmm maybe IRCv3 makes it acceptable. Who knows?

  375. kikuchiyo has left

  376. kikuchiyo has joined

  377. pulkomandy has left

  378. pulkomandy has joined

  379. nephele

    Matrixes bridge is nice for other reasons too, they transform messages with irc nicknames in them to the matrix equivalent nicknames... so if you were to pick a common noun on the irc side....

  380. pulkomandy has left

  381. pulkomandy has joined

  382. raghavgururajan has left

  383. raghavgururajan has joined

  384. raghavgururajan has left

  385. raghavgururajan has joined

  386. pulkomandy has left

  387. pulkomandy has joined

  388. mac has joined

  389. homebeach has left

  390. Matrix Traveler (bot) has left

  391. Matrix Traveler (bot) has joined

  392. homebeach has joined

  393. raghavgururajan has left

  394. marc0s has left

  395. marc0s has joined

  396. pulkomandy has left

  397. Yagizа has joined

  398. Yagizа has left

  399. Yagizа has joined

  400. tom has joined

  401. raghavgururajan has joined

  402. marc0s has left

  403. marc0s has joined

  404. PapaTutuWawa has joined

  405. 9lakes has left

  406. 9lakes has joined

  407. mac has left

  408. mac has joined

  409. marc0s has left

  410. marc0s has joined

  411. marc0s has left

  412. marc0s has joined

  413. pulkomandy has joined

  414. Yagizа has left

  415. pulkomandy has left

  416. rom1dep has left

  417. pulkomandy has joined

  418. marmistrz has joined

  419. marc0s has left

  420. marc0s has joined

  421. spectrum has left

  422. spectrum has joined

  423. nephele has left

  424. Kev has left

  425. Kev has joined

  426. Yagizа has joined

  427. pulkomandy has left

  428. pulkomandy has joined

  429. pulkomandy has left

  430. pulkomandy has joined

  431. pulkomandy has left

  432. pulkomandy has joined

  433. rom1dep has joined

  434. Kev has left

  435. Kev has joined

  436. Kev has left

  437. Kev has joined

  438. pulkomandy has left

  439. pulkomandy has joined

  440. Yagizа has left

  441. Kev has left

  442. Kev has joined

  443. glickyong has joined

  444. dezant has left

  445. Kev has left

  446. Kev has joined

  447. Kev has left

  448. Kev has joined

  449. pulkomandy has left

  450. pulkomandy has joined

  451. dezant has joined

  452. Kev has left

  453. Kev has joined

  454. Kev has left

  455. Kev has joined

  456. Yagizа has joined

  457. sonny has left

  458. sonny has joined

  459. sonny has left

  460. sonny has joined

  461. Yagizа has left

  462. homebeach has left

  463. Matrix Traveler (bot) has left

  464. Matrix Traveler (bot) has joined

  465. homebeach has joined

  466. Kev has left

  467. Kev has joined

  468. sonny has left

  469. sonny has joined

  470. mac has left

  471. Kev has left

  472. Kev has joined

  473. 9lakes has left

  474. marmistrz has left

  475. Kev has left

  476. Kev has joined

  477. marmistrz has joined

  478. 9lakes has joined

  479. edhelas has left

  480. edhelas has joined

  481. Kev has left

  482. Kev has joined

  483. Kev has left

  484. Kev has joined

  485. marmistrz has left

  486. marmistrz has joined

  487. sonny has left

  488. Neustradamus has left

  489. marc0s has left

  490. marc0s has joined

  491. marc0s has left

  492. marc0s has joined

  493. Kev has left

  494. Kev has joined

  495. dezant has left

  496. raghavgururajan has left

  497. Wojtek has left

  498. Kev has left

  499. Kev has joined

  500. Kev has left

  501. Kev has joined

  502. marc0s has left

  503. marc0s has joined

  504. Kev has left

  505. Kev has joined

  506. Kev has left

  507. Kev has joined

  508. nephele has joined

  509. Kev has left

  510. Kev has joined

  511. dezant has joined

  512. marc0s has left

  513. marc0s has joined

  514. Kev has left

  515. Kev has joined

  516. marc0s has left

  517. marc0s has joined

  518. Kev has left

  519. Kev has joined

  520. marc0s has left

  521. marc0s has joined

  522. Kev has left

  523. homebeach has left

  524. Matrix Traveler (bot) has left

  525. Kev has joined

  526. Matrix Traveler (bot) has joined

  527. homebeach has joined

  528. Kev has left

  529. Kev has joined

  530. marc0s has left

  531. marc0s has joined

  532. marc0s has left

  533. marc0s has joined

  534. Kev has left

  535. Kev has joined

  536. Kev has left

  537. Kev has joined

  538. rafasaurus has left

  539. rafasaurus has joined

  540. Kev has left

  541. Kev has joined

  542. Kev has left

  543. Kev has joined

  544. Kev has left

  545. Kev has joined

  546. Kev has left

  547. Kev has joined

  548. Kev has left

  549. homebeach has left

  550. Matrix Traveler (bot) has left

  551. Matrix Traveler (bot) has joined

  552. homebeach has joined

  553. Kev has joined

  554. test1 has joined

  555. test1 has left

  556. dezant has left

  557. Kev has left

  558. Kev has joined

  559. marc0s has left

  560. marc0s has joined

  561. Kev has left

  562. Kev has joined

  563. test1 has joined

  564. test1 has left

  565. marc0s has left

  566. marc0s has joined

  567. marc0s has left

  568. marc0s has joined

  569. Kev has left

  570. Kev has joined

  571. Kev has left

  572. Kev has joined

  573. homebeach has left

  574. Matrix Traveler (bot) has left

  575. Matrix Traveler (bot) has joined

  576. homebeach has joined

  577. Kev has left

  578. Kev has joined

  579. inky has left

  580. marmistrz has left

  581. Kev has left

  582. Kev has joined

  583. Kev has left

  584. Kev has joined

  585. Kev has left

  586. Kev has joined

  587. Zash has left

  588. Zash has joined

  589. Zash has left

  590. Kev has left

  591. Kev has joined

  592. Zash has joined

  593. Zash has left

  594. Zash has joined

  595. Zash has left

  596. atomicwatch has left

  597. Zash has joined

  598. nephele has left

  599. msavoritias has left

  600. Kev has left

  601. Kev has joined

  602. glickyong has left

  603. Kev has left

  604. Kev has joined

  605. Kev has left

  606. Kev has joined

  607. Kev has left

  608. Kev has joined

  609. edhelas has left

  610. edhelas has joined

  611. PapaTutuWawa has left

  612. test1 has joined

  613. test1 has left

  614. goffi has left

  615. Kev has left

  616. Kev has joined

  617. contrapunctus has left

  618. contrapunctus has joined

  619. SouL has left

  620. emus has left

  621. sonny has joined

  622. emus has joined

  623. debacle has left

  624. Kev has left

  625. Kev has joined

  626. Kev has left

  627. Kev has joined

  628. pasdesushi has left

  629. pasdesushi has joined

  630. Kev has left

  631. Kev has joined