XSF Discussion - 2017-10-24

  1. matlag

    Yes, and apparently the take away for the moment is someone does not like your mascote

  2. waqas has joined

  3. daniel has left

  4. Guus has left

  5. daniel has joined

  6. Valerian has left

  7. waqas has left

  8. efrit has joined

  9. SamWhited has left

  10. Tobias has joined

  11. lskdjf has left

  12. la|r|ma has left

  13. dwd has left

  14. Valerian has joined

  15. dwd has left

  16. daniel has left

  17. daniel has joined

  18. la|r|ma has joined

  19. lskdjf has joined

  20. daniel has left

  21. daniel has joined

  22. lumi has left

  23. stefandxm has left

  24. ralphm has joined

  25. Arc has joined

  26. Syndace has joined

  27. Syndace has joined

  28. Valerian has left

  29. tux has left

  30. tux has joined

  31. efrit has left

  32. dwd has left

  33. dwd has left

  34. jere has left

  35. jere has joined

  36. jere has left

  37. jere has joined

  38. Arc


  39. daniel has left

  40. daniel has joined

  41. SamWhited has left

  42. stefandxm has joined

  43. Guus has left

  44. Tobias has left

  45. daniel has left

  46. daniel has joined

  47. stefandxm has left

  48. Arc has left

  49. arc has left

  50. arc has joined

  51. daniel has left

  52. daniel has joined

  53. goffi has joined

  54. arc has left

  55. arc has joined

  56. uc has joined

  57. Arc has joined

  58. arc has left

  59. Guus has left

  60. arc has joined

  61. arc has left

  62. arc has joined

  63. dwd has left

  64. ralphm has left

  65. Tobias has joined

  66. Guus has left

  67. edhelas

    yup saw that, I answered on the discussion already

  68. daniel has left

  69. daniel has joined

  70. edhelas

    at least people are not talking about Matrix :p

  71. Zash

    Great success

  72. dwd has left

  73. ralphm has joined

  74. daniel has left

  75. daniel has joined

  76. daniel has left

  77. daniel has joined

  78. zinid

    is matrix still alive?

  79. zinid

    I still remember the claim "Insanely scalable and performant next-generation server (Dendrite) on the horizon" and waiting patiently

  80. edhelas


  81. Zash

    You get a ruby thing that needs 2 gigs of memory for a few users

  82. daniel has left

  83. daniel has joined

  84. edhelas

    RAM is meant to be used

  85. zinid


  86. zinid

    it's in Go

  87. Zash

    I mean the current server

  88. zinid

    the current is in python

  89. daniel has left

  90. daniel has joined

  91. Zash

    Same same :P

  92. zinid

    yes, crap

  93. zinid

    and then they chose another crap

  94. zinid

    every server in Go I used is leaking and unstable as hell

  95. daniel has left

  96. daniel has joined

  97. daniel has left

  98. daniel has joined

  99. ralphm has left

  100. daniel has left

  101. daniel has joined

  102. stefandxm has joined

  103. Tobias has joined

  104. Guus has left

  105. dwd has left

  106. ralphm has joined

  107. daniel has left

  108. sonny has joined

  109. dwd has left

  110. stefandxm has left

  111. daniel has joined

  112. Steve Kille has left

  113. Steve Kille has joined

  114. daniel has left

  115. jubalh has joined

  116. jubalh has left

  117. jubalh has joined

  118. zinid

    damn, I cannot even read the MIX XEP, yet I have to implement it, wtf...

  119. efrit has joined

  120. edhelas

    I know that feeling

  121. Ge0rG has left

  122. lskdjf has joined

  123. jabberatdemo has joined

  124. Zash has left

  125. jubalh has joined

  126. efrit has left

  127. Arc has left

  128. Arc has joined

  129. daniel has left

  130. jabberatdemo has left

  131. la|r|ma has joined

  132. lskdjf has joined

  133. sonny has left

  134. sonny has joined

  135. sonny has joined

  136. sonny has joined

  137. jcbrand has joined

  138. daniel has left

  139. daniel has joined

  140. efrit has joined

  141. jubalh has joined

  142. dwd

    zinid, You're implementing MIX? Our implementation still doesn't entirely match the XEP. Too many things don't work well in practise.

  143. zinid

    dwd: I implemented the very first version, it's outdated of course

  144. zinid

    and looking at the current XEP I'm losing motivation, it's overly complex

  145. Tobias has joined

  146. Ge0rG

    Maybe we can just fix MUC.

  147. stefandxm has joined

  148. dwd

    zinid, Some parts are fine. Others get a bit weird, mostly around proxy vs real jids.

  149. Zash

    Ge0rG: Make me motivated to work on mod_minimix or whatever I called it. Makes you join MUCs with your bare JID. I forget what parts got weird.

  150. zinid

    Ge0rG: I also tend to think it's easier to fix MUC

  151. zinid

    or implement "simple" muc

  152. Ge0rG

    Zash: write to standards@!

  153. Zash

    Ge0rG: Implementation first!

  154. Zash

    Ge0rG: Technically not requiring any standards yet. Protocol doesn't change.

  155. Ge0rG

    Zash: joining with a bare JID is a protocol change.

  156. Zash

    Does MUC forbid that?

  157. Ge0rG

    I'm pretty sure it does

  158. zinid


  159. Ge0rG

    okay, I'm not sure.

  160. Zash

    Arbitrary JID limitations should go away

  161. dwd

    No, it doesn't.

  162. Zash

    What if a server wants to join a room that doesn't have a node? :)

  163. efrit has left

  164. dwd

    Oh, room jids have to be of specific forms.

  165. Ge0rG

    what if a server wants to join a room that runs at the bare JID of the server?

  166. Ge0rG

    dwd: you can join chat.yax.im as a MUC.

  167. dwd

    Ge0rG, You're not making the argument you think you are there.

  168. Ge0rG

    dwd: I'm not sure I wanted to make an argument at all

  169. dwd

    Ge0rG, First bullet-point in XEP-0045§3.

  170. Ge0rG

    dwd: that is not normative

  171. dwd

    Ge0rG, What? Why not?

  172. Zash

    > For the sake of backwards-compatibility [with] groupchat 1.0

  173. dwd

    Zash, That is indeed the rationale for the requirement stated.

  174. Ge0rG

    dwd: it merely states a result of some historical quirks, it doesn't require that a MUC MUST have that form.

  175. Zash

    dwd: How does that translate into bare host rooms being forbidden?

  176. dwd

    Ge0rG, You think unless it uses a mystical incantation of RFC 2119 you can ignore it?

  177. Ge0rG

    dwd: I think that "well written" and "XEP 0045" don't belong into the same sentence.

  178. dwd

    Zash, It says they're requirements. Seems they're probably required. Whether that's a good idea or not is an entirely different matter.

  179. Zash

    dwd: What, and here I was just grepping for MUST and ignored everything else! :)

  180. zinid

    yeah, this is very important problem: should a room have node part? it should be resolved asap!

  181. Zash

    dwd: But does that mean you need to support room@host or *only* room@host?

  182. Zash mumbles on about ambiguity

  183. Ge0rG

    dwd: there is no requirement that the room name must be non-empty

  184. dwd

    Zash, It's there as a statement of fact: "Each room is identified as a "room JID" <room@service>", so I'd say if a room cannot be so identified it's not conformant to the spec.

  185. dwd

    Ge0rG, Yes there is, the local-part of a jid cannot be zero-length.

  186. dwd

    Zash, I'm not saying this is a sensible requirement, or that it wouldn't work any other way. I'm merely saying that this is what the XEP says.

  187. Ge0rG

    except the XEP is not very clear in its wording

  188. zinid

    Ge0rG: "each room is identified"

  189. zinid

    isn't this clear?

  190. dwd

    Zash, But anyway. It says nothing I can find on the subject of what the occupant's real jids are (though it infers they're full jids a few times, it never states this as a requirement).

  191. Zash

    So MUC at bare host aren't rooms, but special magical hidden places for cool people only! :)

  192. zinid

    of course, "MUST be of <room@server>" would be clearly, but XEP authors prefer very long sentence with cryptic words :)

  193. Zash

    dwd: Shiny

  194. Ge0rG

    Zash: XEP authors are people, too

  195. Zash

    dwd: So nothing prevents a server from just sending one join stanza, then keeping track of which local resources have joined, forking incoming groupchats as needed

  196. Ge0rG

    Zash: so you are moving MSN from the MUC to the user's server

  197. dwd

    zinid, "Each room MUST be identified as" would be longer, not shorter. But FWIW, I really hate littering a document with RFC 2119 language, and prefer to use it more sparingly to highlight more subtle cases.

  198. Zash

    Which also means it can easily do MAM without a mess

  199. Zash

    Ge0rG: Pretty much, yes

  200. Ge0rG

    Zash: and MUC-PMs

  201. Ge0rG

    But it would probably break biboumi in surprising ways

  202. dwd

    Zash, More or less. But presence would remain a mess. And if you avoided that, you're getting very close to MIX.

  203. stefandxm has left

  204. Zash

    dwd: Why I called my draft code "minimix" :)

  205. Ge0rG

    Zash: write it in a way that you can plug it into MUC or into the server, and fix nick changes etc.

  206. Ge0rG

    and presence priority.

  207. lskdjf has joined

  208. zinid

    dwd: I just wanted to say that would be great to have shorter sentences with simplier words, think about non-native speakers

  209. zinid

    dwd: I recall there is even RFC stating that

  210. Ge0rG

    zinid: there is a reason for so many Shakespeare references in the XEPs.

  211. dwd

    zinid, Yes, I agree simple sentences are better.

  212. zinid

    Ge0rG: to promote English culture?

  213. dwd

    zinid, Even though its an American doing so, most of the time.

  214. dwd

    zinid, I'd be tempted, myself, to use Tolstoy. More characters, for a start.

  215. zinid

    dwd: but this is clearly your move :P In other RFCs are just used Bob and Alice

  216. Ge0rG

    dwd: that reminds me of http://idlewords.com/talks/website_obesity.htm

  217. dwd

    zinid, Also, I read War and Peace (and various other Tolstoy, Chekov, Dostoyevsky) back in my teens and cannot remember the characters anymore.

  218. zinid

    dwd: lol, I didn't even read them :D

  219. Arc has left

  220. Arc has joined

  221. Steve Kille has left

  222. daniel has left

  223. daniel has joined

  224. dwd

    zinid, Well, I did read them in English, in fairness.

  225. arc has left

  226. arc has joined

  227. Ge0rG has left

  228. arc has left

  229. arc has joined

  230. Arc has left

  231. arc has left

  232. arc has joined

  233. arc has left

  234. arc has joined

  235. arc has left

  236. arc has joined

  237. tim@boese-ban.de has joined

  238. tim@boese-ban.de has joined

  239. tim@boese-ban.de has joined

  240. arc has left

  241. arc has joined

  242. arc has left

  243. arc has joined

  244. ralphm has left

  245. arc has left

  246. arc has joined

  247. tim@boese-ban.de has joined

  248. tim@boese-ban.de has joined

  249. tim@boese-ban.de has joined

  250. ralphm has joined

  251. stefandxm has joined

  252. dwd has left

  253. lumi has joined

  254. dwd has left

  255. sonny has joined

  256. jere has joined

  257. la|r|ma has joined

  258. la|r|ma has joined

  259. stefandxm has left

  260. Zash has left

  261. jere has left

  262. jere has joined

  263. dropcash77 has joined

  264. dropcash77 has left

  265. jere has left

  266. jere has joined

  267. intosi has left

  268. jabberatdemo has joined

  269. dwd has left

  270. ralphm has left

  271. dwd has left

  272. mimi89999 has joined

  273. sonny has joined

  274. mimi89999 has joined

  275. jabberatdemo has left

  276. jere has left

  277. jere has joined

  278. pep. has left

  279. pep. has joined

  280. daniel has left

  281. lumi has left

  282. alacer has joined

  283. intosi has joined

  284. daniel has left

  285. daniel has left

  286. ralphm has left

  287. Valerian has joined

  288. nyco has left

  289. daniel has left

  290. sonny has joined

  291. stefandxm has joined

  292. lumi has joined

  293. waqas has joined

  294. ralphm has left

  295. stefandxm has left

  296. uc has joined

  297. uc has joined

  298. lumi has left

  299. Zash has joined

  300. uc has joined

  301. uc has joined

  302. la|r|ma has left

  303. alacer has left

  304. vanitasvitae has joined

  305. uc has left

  306. uc has joined

  307. Valerian has left

  308. stefandxm has joined

  309. waqas has left

  310. waqas has joined

  311. ralphm has left

  312. SamWhited

    I think I skipped War and Peace in highschool, but Anna Karenina is still one of my favorite books.

  313. SamWhited

    zinid: what servers in Go gave you trouble? One of Go's features is that it makes resource leaks hard, so that surprises me.

  314. zinid

    SamWhited: ipfs

  315. alacer has joined

  316. zinid


  317. zinid

    one of the point is memory leaking

  318. zinid

    gc performance sucks also

  319. goffi has left

  320. SamWhited

    How did they manage that? Go's gc can correct a 50 gig heap in under 10ms in most cases

  321. SamWhited


  322. zinid

    is it from Google's advertisement? :)

  323. Holger

    Complex systems run into memory leaks more or less easily no matter what the language, no?

  324. SamWhited

    No, it's from data I've seen in prod.

  325. zinid

    Holger: we have ejabberd with several month uptime without leaking for example

  326. zinid

    yes, the consumption might be high, but not leaking

  327. Holger

    zinid: Yes sure, I'm not saying all complex systems are leaking :-)

  328. Ge0rG

    All complex systems are leaking, just at different speeds ;)

  329. Holger

    But if you get something wrong, i.e. if you accumulate references to blobs over time, no GC in the world will save you from that.

  330. SamWhited

    I'm reasonably sure none of these things have anything to do with the language though; you can't have a traditional memory leak in go because there's gc, but if you always add things to an append only list and keep a reverence forever then obviously there's nothing the language can do

  331. Valerian has joined

  332. SamWhited

    You can leak resources in Go, eg. forget to close a file descriptor or have an infinitely looping coroutine, but defer/close makes that pretty hard to do.

  333. zinid

    the point is that it doesn't matter how you leak it

  334. zinid

    also, would be great to have tools

  335. zinid

    to see where is leaking

  336. goffi has joined

  337. zinid

    and looking at IPFS guys there are no such tools :)

  338. SamWhited

    It does if you're going to blame the language, because if it's a bug I'd like to fix it. What kind of tools?

  339. SamWhited

    There is extensive tooling for that

  340. zinid


  341. zinid

    one year already, with several duplicates

  342. zinid

    you might want to suggest them the tool :)

  343. Zash

    Tooling for what, exactly?

  344. SamWhited

    I will, that sounds like the ipfs people just don't know what they're doing. Pprof can ve used to monitor the heap size, and all Go binaries have built in gc logging (you can set an environment variable and they'll dump runtime statistics)

  345. Holger

    I'm not sure Go servers will typically use goroutines in a similar way to Erlang processes. If so I'd want tools to query resource usage and state of individual goroutines (or groups of them), to modify the state, to kill them; or I'll return to Erlang :-)

  346. SouL has joined

  347. Zash

    I want tools too

  348. SamWhited

    Holger: I don't think it makes sense to do that, they're much lighter weight and you might have multiple per task, but you could.

  349. Holger

    Zash: Says the Lua programmer ... :-)

  350. Holger

    SamWhited: Much leighter weight than what? It makes a *lot* of sense in Erlang.

  351. SamWhited

    It doesn't make sense in Go, I mean. Go's coroutines are lighter weight.

  352. Holger

    Than what :-)

  353. Holger

    If you're a server, would you typically use a goroutine to handle a client connection?

  354. SamWhited

    Yes, maybe several.

  355. Holger

    If so you will of course take advantage of being able to introspect that at runtime.

  356. jere has joined

  357. SamWhited

    Yes, it's certainly not as easy as in a dynamic language, but there are process monitoring tools to show you long running goroutines

  358. SamWhited

    Monitoring is common, manually killing or changing the state isn't, it's not a dynamic language. Although there are debuggers that can do that, I guess.

  359. SamWhited

    Well, monitoring is as easy, mutating isn't.

  360. zinid

    supervision can be implemented in any language

  361. zinid

    but seems like everyone copies idea of "goroutines" and think they got Erlang

  362. Ge0rG

    But everbody knows that you need overpriced special experts for Erlang and C++ projects.

  363. zinid

    lack of runtime introspection is the stopper factor for me in any such fancy language

  364. Holger

    They have hype. Go is a bit like Matrix :-)

  365. Holger

    (Well except that Go is actually successful.)

  366. zinid


  367. zinid

    fair remark :D

  368. edhelas

    Matrix is successfull, there's thousands of subscribers on their chatrooms

  369. Zash

    Shun the hype!

  370. zinid

    edhelas: they have even me there!

  371. stefandxm has left

  372. zinid

    but I don't use Matrix...

  373. Zash

    edhelas: Is that an accurate indicator of success?

  374. edhelas

    zinid you're a spy on cover sent by the XSF ?

  375. dwd has left

  376. zinid

    edhelas: I used to be a spy once (or twice)

  377. Steve Kille has left

  378. jere has joined

  379. SamWhited

    I really wanted to like matrix, but the basic premise of the protocol is crap and they built it in an unsustainable way (and then were surprised when the money dried up)

  380. dwd has left

  381. SamWhited has joined

  382. SamWhited has joined

  383. Zash

    SamWhited: Why did you want to like it?

  384. waqas has left

  385. zinid

    "unsustainable way"? what do you mean? like they don't have enough resources to develop/promote/etc it?

  386. SamWhited

    Zash: So that I could have something that was an interoperable and federated standard that wasn't our broken crap, unfortunately it never became the alternative I hoped it would

  387. SamWhited

    zinid: they had enough resources, until they didn't. It's unsustainable because they expected one company to pay them for full time developers forever

  388. zinid


  389. SamWhited

    And we saw how that works out… not that they couldn't continue it in a more sustainable way now, but they seem to expect to still be able to be paid full time for it.

  390. lumi has joined

  391. Guus

    What irks me is that it's just one implementation - done by the same people that develop the standards.

  392. zinid

    well the idea that a single company controls a *federated* protocol is broken

  393. Guus

    not sure if it's broken - but it does not bode well.

  394. SamWhited

    Yah, I hoped they'd get other implementations later, but it wasn't a healthy ecosystem

  395. edhelas

    what about OStatus/ActivityPub ?

  396. zinid

    from innovative perspective I used to find Tox even more interesting than Matrix, but it's dead too

  397. zinid

    There is Ring.cx, but buggy as hell

  398. edhelas

    Ring is interesting but unfortunately their architecture prevent them to have advanced features

  399. edhelas

    like history, sync and profiles

  400. edhelas

    you cannot compare apples and oranges

  401. zinid

    edhelas: I think it's possible with dumb servers

  402. zinid

    Aka backup servers

  403. edhelas

    WhatsApp like

  404. zinid

    Well it scales good

  405. waqas has joined

  406. Zash

    Talking about p2p with servers?

  407. edhelas


  408. zinid

    Zash: hybrid

  409. zinid

    But more p2pish

  410. edhelas

    the whatsapp accounts are bound to the devices

  411. edhelas

    so to sync history between devices, or migrating them they use "backup servers"

  412. Zash

    Like Skype?

  413. zinid

    You see, if you have several devices you can synchronize yourself, you don't even need backups

  414. edhelas

    Skype is now a dumb centralized service since Microsoft bought them

  415. Zash

    Any client dev interested in doing client to client MAM?

  416. edhelas

    but why :D

  417. zinid

    And if all your devices offline and someone sent you a message, you will request it on login (via Delta from the contact)

  418. Zash

    edhelas: IIRC they switched it to the MSN infrastructure

  419. zinid

    So backups might not even be needed, at least for everyone

  420. zinid

    There is a problem with conferences in such system tho

  421. dwd has left

  422. Alex has joined

  423. Alex has left

  424. dwd has left

  425. zinid has left

  426. Zash has left

  427. dwd has left

  428. Zash has joined

  429. Wiktor has joined

  430. jcbrand has left

  431. tim@boese-ban.de has left

  432. zinid has left

  433. jcbrand has joined

  434. stefandxm has joined

  435. zinid has left

  436. dwd

    As edhelas says, Skype centralized a while back, mostly because of mobile devices.

  437. Guus has left

  438. stefandxm has left

  439. zinid

    dwd: yes, mobile complicates everything, especially ios restrictions

  440. Valerian has left

  441. Valerian has joined

  442. dwd has left

  443. dwd has left

  444. Guus has left

  445. Guus has left

  446. jcbrand has left

  447. jcbrand has joined

  448. dwd has left

  449. daniel has left

  450. daniel has joined

  451. daniel has left

  452. daniel has joined

  453. moparisthebest has joined

  454. daniel has left

  455. daniel has joined

  456. dwd has left

  457. jcbrand has left

  458. daniel has left

  459. daniel has joined

  460. jcbrand has joined

  461. daniel has left

  462. daniel has joined

  463. Alex has joined

  464. daniel has left

  465. daniel has joined

  466. jjrh has left

  467. Alex has left

  468. Guus has left

  469. stefandxm has joined

  470. jjrh has left

  471. jjrh has left

  472. jjrh has left

  473. jubalh has left

  474. intosi has left

  475. Guus has left

  476. valo has joined

  477. Valerian has left

  478. Valerian has joined

  479. Valerian has left

  480. nyco has left

  481. stefandxm has left

  482. stefandxm has joined

  483. Guus has left

  484. jcbrand has left

  485. jubalh has left

  486. Valerian has joined

  487. Alex has joined

  488. Tobias has joined

  489. tim@boese-ban.de has joined

  490. Syndace has joined

  491. Syndace has joined

  492. jubalh has left

  493. Alex has left

  494. jubalh has left

  495. Guus has left

  496. Guus has left

  497. jubalh has left

  498. Kev has left

  499. jubalh has joined

  500. zinid has left

  501. tux has left

  502. sonny has joined

  503. sonny has joined

  504. sonny has joined

  505. xnyhps has joined

  506. sonny has left

  507. sonny has joined

  508. jubalh has left

  509. nyco has left

  510. sonny has left

  511. sonny has joined

  512. Ge0rG has left

  513. Ge0rG has left

  514. jubalh has left

  515. Alex has joined

  516. jcbrand has joined

  517. mimi89999 has left

  518. mimi89999 has joined

  519. ralphm has left

  520. jubalh has joined

  521. sonny has joined

  522. sonny has joined

  523. jcbrand has left

  524. jcbrand has joined

  525. intosi has joined

  526. jcbrand has left

  527. jcbrand has joined

  528. Valerian has left

  529. jcbrand has left

  530. daniel has left

  531. daniel has joined

  532. jcbrand has joined

  533. Alex has left

  534. moparisthebest has joined

  535. moparisthebest has joined

  536. Valerian has joined

  537. dwd has left

  538. Alex has joined

  539. jere has joined

  540. la|r|ma has left

  541. zinid has left

  542. jubalh has left

  543. uc has joined

  544. lskdjf has joined

  545. ralphm has left

  546. jubalh has left

  547. jcbrand has left

  548. ralphm has left

  549. daniel has left

  550. Alex has left

  551. daniel has joined

  552. SouL has left

  553. jubalh has joined

  554. jubalh has left

  555. Steve Kille has joined

  556. daniel has left

  557. daniel has joined

  558. Neustradamus has joined

  559. daniel has left

  560. daniel has joined

  561. waqas has left

  562. daniel has left

  563. daniel has joined

  564. daniel has left

  565. daniel has joined

  566. ralphm has joined

  567. jubalh has joined

  568. jubalh has left

  569. jubalh has joined

  570. tux has left

  571. jubalh has left

  572. jubalh has joined

  573. daniel has left

  574. efrit has joined

  575. goffi has left

  576. jubalh has left

  577. jubalh has joined

  578. nyco has left

  579. ralphm has left

  580. ThurahT has left

  581. ThurahT has joined

  582. intosi has left

  583. ThurahT has left

  584. Ge0rG has left

  585. jubalh has left

  586. dwd has joined

  587. ThurahT has joined

  588. dwd has left

  589. dwd has joined

  590. Bunneh has joined

  591. dwd has left

  592. dwd has joined

  593. dwd has left

  594. daniel has joined

  595. jubalh has joined

  596. Guus has left

  597. Valerian has left

  598. arc has left

  599. arc has joined

  600. lskdjf has joined

  601. jubalh has left

  602. SamWhited has left

  603. Valerian has joined

  604. Arc has joined

  605. Guus has left

  606. dwd has joined

  607. efrit has left

  608. jjrh has left

  609. jjrh has left

  610. jjrh has left

  611. dwd has left

  612. dwd has joined

  613. dwd has left

  614. dwd has joined

  615. Guus has left

  616. dwd has left

  617. moparisthebest has joined

  618. moparisthebest has joined

  619. jjrh has left

  620. vanitasvitae has left

  621. Zash has left

  622. Arc has left

  623. Arc has joined

  624. dwd has joined

  625. dwd has left

  626. dwd has joined