XSF Discussion - 2019-03-24

  1. Neustradamus has left
  2. Neustradamus has joined
  3. Neustradamus has left
  4. Neustradamus has joined
  5. debacle has left
  6. Neustradamus has left
  7. Neustradamus has joined
  8. Neustradamus has left
  9. Neustradamus has joined
  10. Neustradamus has left
  11. Neustradamus has joined
  12. arc has left
  13. arc has joined
  14. Neustradamus has left
  15. Neustradamus has joined
  16. UsL has left
  17. UsL has joined
  18. lnj has left
  19. Neustradamus has left
  20. Neustradamus has joined
  21. rtq3 has left
  22. rtq3 has joined
  23. gengar has joined
  24. arc has left
  25. arc has joined
  26. gengar has left
  27. lumi has left
  28. karoshi has left
  29. gengar has joined
  30. Neustradamus has left
  31. Neustradamus has joined
  32. gengar has left
  33. gengar has joined
  34. rtq3 has left
  35. gengar has left
  36. gengar has joined
  37. gengar has left
  38. Neustradamus has left
  39. Neustradamus has joined
  40. gengar has joined
  41. gengar has left
  42. gengar has joined
  43. alacer has joined
  44. ThibG has left
  45. larma has left
  46. alacer has left
  47. alacer has joined
  48. alacer has left
  49. alacer has joined
  50. alacer has left
  51. alacer has joined
  52. lskdjf has left
  53. alacer has left
  54. alacer has joined
  55. alacer has left
  56. arc has left
  57. arc has joined
  58. gengar has left
  59. gengar has joined
  60. gengar has left
  61. gengar has joined
  62. alacer has joined
  63. alacer has left
  64. alacer has joined
  65. gengar has left
  66. gengar has joined
  67. gengar has left
  68. alacer has left
  69. alacer has joined
  70. arc has left
  71. arc has joined
  72. gengar has joined
  73. alexis has joined
  74. gengar has left
  75. gengar has joined
  76. alexis has left
  77. alexis has joined
  78. gengar has left
  79. gengar has joined
  80. alexis has left
  81. alexis has joined
  82. gengar has left
  83. oli has joined
  84. gengar has joined
  85. alexis has left
  86. alexis has joined
  87. ThibG has joined
  88. alacer has left
  89. alacer has joined
  90. moparisthebest has left
  91. igoose has left
  92. igoose has joined
  93. moparisthebest has joined
  94. alexis has left
  95. alexis has joined
  96. gengar has left
  97. gengar has joined
  98. gengar has left
  99. arc has left
  100. arc has joined
  101. gengar has joined
  102. gengar has left
  103. jubalh has joined
  104. jubalh has left
  105. jubalh has joined
  106. alacer has left
  107. alacer has joined
  108. jubalh has left
  109. jubalh has joined
  110. gengar has joined
  111. gengar has left
  112. alexis has left
  113. jubalh has left
  114. gengar has joined
  115. gengar has left
  116. oli has left
  117. kokonoe has left
  118. Nekit has joined
  119. lnj has joined
  120. Erkan Files has joined
  121. Erkan Files has left
  122. mabihir has joined
  123. kokonoe has joined
  124. gengar has joined
  125. arc has left
  126. gengar has left
  127. gengar has joined
  128. arc has joined
  129. gengar has left
  130. gengar has joined
  131. karoshi has joined
  132. karoshi has left
  133. karoshi has joined
  134. oli has joined
  135. gengar has left
  136. gengar has joined
  137. !xsf_Martin has joined
  138. gengar has left
  139. zach has left
  140. zach has joined
  141. gengar has joined
  142. larma has joined
  143. ThibG has left
  144. ThibG has joined
  145. gengar has left
  146. gengar has joined
  147. Guus MattJ / flow : https://github.com/xsf/xeps/pull/771
  148. gengar has left
  149. Guus Would something go horribly, horribly wrong, if a server simply adds a stable/unique stanza ID to any message that it processes?
  150. MattJ It makes client life hard/impossible, sadly
  151. MattJ Clients would no longer know when a message is archived or not
  152. MattJ So they don't know if the id can/should be stored for later querying (e.g. for catch-up)
  153. Guus I do not like the fact that we're deducing that something is archived by merely detecting the presence of something that's supposed to be an opaque identifier.
  154. Guus (also, I don't have a better suggestion)
  155. MattJ Guus: that's why <archived> existed
  156. Guus What's the impossibility for clients, exactly?
  157. larma has left
  158. Holger Hmm I don't quite see this problem. There's no guarantee archived messages will remain in the archive forever anyway.
  159. Holger And I don't quite see how the info whether a locally stored message is also in the archive helps the client.
  160. Holger In my book it's fine to add a stanza ID to all messages. It may actually help with non-MAM use cases.
  161. larma has joined
  162. gengar has joined
  163. Guus It'd make my implementation a lot easier...
  164. Andrew Nenakhov > Would something go horribly, horribly wrong, if a server simply adds a stable/unique stanza ID to any message that it processes? In short that's the basis of our XEP that we use to ensure message delivery. Works well.
  165. Nekit has left
  166. Guus Andrew Nenakhov the basis is that something goes wrong if we do (and you found an alternative), or: you do it, and you've seen that nothing goes wrong?
  167. Andrew Nenakhov Client sends stanza with provisional id, server stamps it with 0359 unique and stable id, sends this id to client as a confirmation.
  168. Andrew Nenakhov Guus, define wrong )
  169. Guus Mushroom-clouds on the horizon.
  170. Andrew Nenakhov We centralize everything to work via server archive. If archive breaks, kaput, yes
  171. gengar has left
  172. neshtaxmpp has left
  173. Andrew Nenakhov > Mushroom-clouds on the horizon. In case of an all scale nuclear weapon attack, im protocols will hardly matter anymore
  174. neshtaxmpp has joined
  175. mabihir has left
  176. mabihir has joined
  177. Guus Andrew Nenakhov I do like to make sure though that IM protocol design decisions do not cause an all scale nuclear weapon attack.
  178. gengar has joined
  179. MattJ Holger, you're right (there is no guarantee archived messages will remain in the archive forever)
  180. MattJ But if it's not in the archive, the client can assume it was purged and it needs to re-fetch the archive
  181. gengar has left
  182. 404.city has joined
  183. j.r has left
  184. rtq3 has joined
  185. mimi89999 has left
  186. ta has left
  187. ta has joined
  188. Guus MattJ: how can it fetch a purged archive?
  189. jubalh has joined
  190. MattJ Guus, I mean in the sense that old messages are purged
  191. Guus Mind you that it is Sunday, I'm an idiot, and did not have enough coffee
  192. Guus I don't understand.
  193. MattJ Messages in the archive are not kept forever on most deployments
  194. MattJ The oldest messages are removed after some expiry time (let's say 30 days)
  195. gengar has joined
  196. Guus with you so far.
  197. Guus but why does the client need to re-fetch the archive if that happens?
  198. Guus need/would want to
  199. jubalh has left
  200. jubalh has joined
  201. MattJ So a client that wants to receive all messages works by continuously remembering the id of the last archived message it received
  202. MattJ When it goes offline for a couple of days, it will come back online and request all messages since the last id it saw
  203. Guus if anything, it'd do a massive amount of data transfer only to end up with _less_ local history?
  204. MattJ With me still?
  205. Guus yes
  206. MattJ So now it goes offline for two months
  207. MattJ The last id it saw is no longer in the server's archive
  208. MattJ So it performs the query and gets item-not-found
  209. MattJ so it knows that the message has been expired, and any messages in the archive are messages it has never seen before
  210. MattJ because they are all newer
  211. Guus right. And if we'd slap on a stanza-id on every message without archiving, it'd _always_ get a item-not-found, assume its local cache is older than that's on the server, and it'd download all history, every time.
  212. Guus that's what you're saying, right?
  213. MattJ Yes
  214. !xsf_Martin has left
  215. gengar has left
  216. Guus I'm guessing that it'd not do this if the server doesn't advertise the MAM feature though.
  217. oli has left
  218. MattJ Sure
  219. oli has joined
  220. waqas I feel like the whole "item-not-found means get full archive" thing is a hack. A server could lose a message for other reasons, e.g., storage failure causing recent stuff to be lost, or deletion of specific message due to gdpr, or some bug, etc.
  221. MattJ waqas, it's not allowed to
  222. pep. > and it'd download all history, every time. It would download up to the date it just requested
  223. Guus waqas I was trying to formulate a similar remark in my head.
  224. MattJ waqas, it can replace with placeholders if it needs to
  225. pep. Which may or may not be the whole history
  226. waqas MattJ: Storage failure isn't something someone can't be allowed to have.
  227. MattJ waqas, handling storage failure in defined ways is entirely sensible
  228. Guus sure, but soleely depening on 'item-not-found' based on a last-known ID still seems ... hackish...
  229. Guus sure, but solelely depening on 'item-not-found' based on a last-known ID still seems ... hackish...
  230. MattJ Guus, it's defined by the XEP to be this way, it's absolutely not a hack
  231. MattJ I mean, what else would you guys propose??
  232. waqas MattJ: Not really. If you lose a disk and restore from recent'ish backup, you'll have a situation where supposedly every recent message would be item-not-found..
  233. Guus MattJ it's a lot easier to disagree with stuff without having to suggest better alternatives 😉
  234. gengar has joined
  235. MattJ waqas, you can't just rewind time like that in most systems without consequences
  236. waqas Yes, and given that laws of physics disallow "messages can't be removed from archive after acked", a protocol shouldn't rely on that.
  237. j.r has joined
  238. Guus what if the client asks for the last-known ID archived by the server?
  239. waqas MattJ: To be clear, I think a sane recommendation would be if item-not-found, get archive by some timestamp based setup, but trying to get archive from beginning of time is silly in such a case.
  240. pep. (What I said above?)
  241. Guus (removed bad idea)
  242. waqas Yep, listen to pep.
  243. MattJ Yes, but the server was relocated to a different timezone and the admin forgot to set it to UTC
  244. pep. Dates don't include TZs? :s
  245. waqas Almost all popular dbs people use (mysql, postgres) in their default replica settings, when the master node is lost and another takes over (or a restoration from backup happens) will potentially lose recent writes. If the MAM XEP wants to assume that wouldn't happen, I'd consider it pretty silly.
  246. gengar has left
  247. debacle has joined
  248. mabihir has left
  249. ThibG has left
  250. MattJ waqas, if you want to write your own XEP go ahead
  251. ThibG has joined
  252. waqas MattJ: Do you see the problem I'm pointing out?
  253. Guus Maybe 'silly' isn't the best classifier here.
  254. Guus > Yes, but the server was relocated to a different timezone and the admin forgot to set it to UTC do we need the XEP to account for this?
  255. j.r has left
  256. frainz has left
  257. MattJ Guus, do we need the XEP to account for any of this?
  258. frainz has joined
  259. Guus Well, if we can modify it somehow to be more resilient against data corruption, and allow for easier re-use of stanza-id, I think it'd add considerable value.
  260. j.r has joined
  261. MattJ waqas, I don't think a server that can't provide a durable store should be able to claim it does
  262. MattJ There's a simple fix for this, the XEP already has a flag to tell the client that the results are not necessarily persisted
  263. mimi89999 has joined
  264. waqas MattJ: I'm asserting that the vast majority of MAM deployments can't guarantee durability in a disk-lost scenario. Recent writes being lost is a fact of life, you can't spec your way around it without mandating things you have no way to mandate.
  265. MattJ I look forward to your PR
  266. waqas Note that I don't think the MAM XEP has to change, just the assumption that item-not-found always means MAM storage was deleted up to that item is wrong.
  267. gengar has joined
  268. MattJ So yet another hidden thing for client devs to think about
  269. frainz has left
  270. frainz has joined
  271. debacle has left
  272. waqas In a world where fsync doesn't necessarily mean data was durably stored, and SQL dbs multi-master replication defaults to async mode (and is rarely used anyway), that's reality.
  273. j.r has left
  274. jubalh has left
  275. gengar has left
  276. Guus MattJ where in the XEP is the what I called 'hack' described?
  277. Guus I was looking to see if the exact wording would make me think of hints for improval
  278. MattJ Guus, it quite possibly isn't
  279. Guus ah ok.
  280. gengar has joined
  281. vanitasvitae has left
  282. vanitasvitae has joined
  283. Guus I'd love to be able to add stanza-id's everywhere, without implying that this means that MAM is available.
  284. lumi has joined
  285. Guus but doesn't service discovery sufficiently guard against that?
  286. MattJ Adding stanza-id doesn't imply MAM is available
  287. MattJ Buf it MAM is available, it implies you can't put stanza-id on every stanza
  288. gengar has left
  289. krauq has left
  290. krauq has joined
  291. gengar has joined
  292. j.r has joined
  293. gengar has left
  294. j.r has left
  295. lskdjf has joined
  296. gengar has joined
  297. Guus I'd like be able to. Is a feasible solution one that allows the client to request the id of the most-recent MAM entry, in order to verify if it has that one in its local archive?
  298. Guus If the XEP doesn't currently define the 'store the id of the last message, assuming that it is the last ID in your server-sided archive', there might be room for a change like that?
  299. krauq has left
  300. MattJ Guus, one of the main premises of the XEP is history sync, this would break it
  301. gengar has left
  302. MattJ Forget the message purging issue for the moment
  303. MattJ If the client records the id of the last message it received, and then later uses this to query an archive, what would you propose it do if the id it happened to remember wasn't an archived one?
  304. Guus item-not-found
  305. MattJ and then what?
  306. Guus Naively (I'm not client builder): I'd see up until what date I'd have a local archive, and retrieve from there.
  307. MattJ So fetch by timestamp?
  308. Guus with some wiggle-room, but yes.
  309. MattJ That way you'll either get duplicates or miss messages
  310. MattJ And that's not hackish?
  311. gengar has joined
  312. Guus Duplicates I can de-dupe with the message ID
  313. MattJ We could have just built the whole XEP on timestamps instead of ids if we're happy with that
  314. Guus misses would be bad.
  315. MattJ It's an ugly hack
  316. Guus well, let's not rewrite everything just yet - I'm fairly certain you've put way more thoughts into this than I have 🙂
  317. MattJ This is not something I would accept a rewrite for, for certain
  318. MattJ The correct fix is to re-introduce a way for the client to know whether the message is in the server's archive or not
  319. Holger > Buf it MAM is available, it implies you can't put stanza-id on every stanza Depends on server implementation, no? The server just must be able to respond to the before/after requests.
  320. Guus so, why can't it ask for the last-recorded message id in the archive?
  321. MattJ Guus, how does that help?
  322. Guus what's my last message? do I have this? no: resync everything.
  323. MattJ Guus, that's broken
  324. MattJ Just because you don't have the last message in the archive doesn't mean you don't have the first
  325. Holger E.g. ejabberd uses timestamps as IDs, so it doesn't matter whether the queried ID is archived, before/after still does the right thing.
  326. Guus resync everything from the last one that you have, I mean.
  327. MattJ Guus, you don't know what the last one you have is
  328. MattJ Holger, multiple stanzas with the same timestamp?
  329. Holger Microsecond accuracy, if you hit that in practice then yes it breaks.
  330. MattJ Holger, what about clock drift then?
  331. Guus MattJ how don't you know what your last message is? You can order your local archive chronologically, use the last one?
  332. MattJ I'm not against using timestamps *in* the id, but it's wrong to use them as the id with no extra logic
  333. MattJ Guus, the last what? I don't know which ones the server archived
  334. Holger MattJ: Clock drift across cluster nodes? That would break as well yes.
  335. Guus Hmm, my parents just walked in. Wife is preparing for 'the stare' again.
  336. gengar has left
  337. Holger (Or do you mean clock jumping backwards? That can't happen with our clock except server restarts.)
  338. Guus Mattj, but if archiving is enabled, you can assume that the messages that you have in ... aah, I don't have the time to further discuss this now, sorry.
  339. Guus ('stare')
  340. Guus I'd love to pick this up later.
  341. MattJ Holger, using the system's monotonic clock? or something custom?
  342. Guus got to go now
  343. Holger Erlang has a thing that doesn't jump back, not sure how it's implemented.
  344. Holger Anyway yes this is not the most robust solution against such pathological cases of course (it just has other nice properties). Whatever I just wanted to say that MAM doesn't imply only archives messages have an ID per se.
  345. 404.city has left
  346. gengar has joined
  347. Holger (ejabberd doesn't actually add IDs to non-archived messages, though I keep pondering with it.)
  348. MattJ Holger, as discussed, things will break (read: get hard/impossible) for clients if you add stanza-id to non-archived stanzas
  349. MattJ which is not a good situation, and should be fixed
  350. Holger Maybe I misunderstood the breakage vector. I would've thought things will be fine as long as the server is aware how the non-archived IDs are ordered compared to the archived messages.
  351. gengar has left
  352. contrapunctus has left
  353. gengar has joined
  354. waqas has left
  355. Holger MattJ, just in case you're interested, this sounds like custom clock that (attempts to) adjusts towards OS clock by changing frequency (up to 1%) while avoiding jumps: http://erlang.org/doc/apps/erts/time_correction.html#No_Time_Warp_Mode
  356. MattJ Fun
  357. Holger (At the cost of risking incorrect offsets of course, so they warn against doing this.)
  358. MattJ Holger, the server knowing how to interpret the ids is not really relevant... unless you're saying it should not return item-not-found but quietly accept ids that don't actually exist in the archive
  359. waqas has joined
  360. MattJ That would cause weirdness with clients that try to fill holes
  361. MattJ and probably other stuff
  362. Holger > unless you're saying it should not return item-not-found but quietly accept ids that don't actually exist in the archive Ah yes that's what I'm saying. IIRC 0059 suggests doing just that (wasn't it even a SHOULD?).
  363. Holger But I'm on my phone and the sun is shining. Gonna shut up now 🙂
  364. MattJ Is it too late to start over with MAM?
  365. MattJ Not using RSM for a start
  366. MattJ Trying to use existing building blocks has just caused confusion and unintended consequences
  367. gengar has left
  368. pep. Well MAM is still experimental :-°
  369. pep. What about another bump?
  370. MattJ Everyone would love that
  371. gengar has joined
  372. pep. That's a thing I don't like in general. The XEP is still experimental but in reality it's just as if it was almost Final. If you change anything everybody is going to grump
  373. oli has left
  374. MattJ It certainly still has open issues, as a spec
  375. pep. Sure. I'm not just talking about MAM, that's how I feel about our specs in general
  376. MattJ Can't have it both ways
  377. MattJ Just this morning it was mentioned that XEP-0313 being Experimental is a reason Pidgin doesn't have support
  378. pep. I'd say that's an issue with developer expectations. If you implement it as experimental, know that it's likely going to change
  379. pep. (And even more, really, draft, even a final spec can be amended with another spec, so..)
  380. 404.city has joined
  381. pep. MattJ, isn't that just an excuse from pidgin devs? :p
  382. MattJ It's not a viewpoint I share, but I'm biased
  383. gengar has left
  384. waqas Are devs expected to implement experimental xeps?
  385. MattJ If a standard explicitly has a big red warning at the top, and warning or no warning is subject to radical change... if I had a limited amount of free time, would I want to implement it?
  386. waqas "While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch)." — https://xmpp.org/extensions/xep-0001.html#states-Experimental
  387. pep. waqas, in the meantime, it's a needed feature
  388. pep. And it's even in the compliance suite..
  389. MattJ That's the real problem (that experimental or not, it's a needed feature)
  390. pep. I'd say both these criteria (needed feature / compliance suite) put even more pressure on the XEP to go to draft/final. I'm not saying I like it
  391. andrey.g has left
  392. pep. And as you say there are still areas that need to be improved
  393. gengar has joined
  394. pep. Maybe there should be a rule that compliance suites can't recommend draft specs. In the hope that people focus/provide feedback on XEPs that are needed
  395. Zash I thought there was
  396. pep. Well if there was, MAM shouldn't be in there
  397. pep. nor carbons? (last call ended but it's still proposed)
  398. attero has joined
  399. attero has left
  400. waqas We should stop calling them "compliance" suites
  401. gengar has left
  402. krauq has joined
  403. gengar has joined
  404. andrey.g has joined
  405. gengar has left
  406. ta has left
  407. ta has joined
  408. gengar has joined
  409. rainslide has joined
  410. krauq has left
  411. gengar has left
  412. krauq has joined
  413. kokonoe has left
  414. kokonoe has joined
  415. rainslide has left
  416. debacle has joined
  417. Nekit has joined
  418. gengar has joined
  419. gengar has left
  420. gengar has joined
  421. !xsf_Martin has joined
  422. !xsf_Martin has left
  423. !xsf_Martin has joined
  424. !xsf_Martin has left
  425. !xsf_Martin has joined
  426. !xsf_Martin has left
  427. !xsf_Martin has joined
  428. rtq3 has left
  429. gengar has left
  430. alacer has left
  431. gengar has joined
  432. alacer has joined
  433. !xsf_Martin has left
  434. alacer has left
  435. alacer has joined
  436. rtq3 has joined
  437. gengar has left
  438. alacer has left
  439. alacer has joined
  440. gengar has joined
  441. gengar has left
  442. debacle has left
  443. rtq3 has left
  444. alacer has left
  445. gengar has joined
  446. alacer has joined
  447. gengar has left
  448. 404.city has left
  449. gengar has joined
  450. rtq3 has joined
  451. gengar has left
  452. 404.city has joined
  453. 404.city has left
  454. gengar has joined
  455. gengar has left
  456. 404.city has joined
  457. 404.city has left
  458. gengar has joined
  459. karoshi has left
  460. gengar has left
  461. rtq3 has left
  462. gengar has joined
  463. gengar has left
  464. Tobias has left
  465. alacer has left
  466. gengar has joined
  467. alacer has joined
  468. gengar has left
  469. j.r has joined
  470. gengar has joined
  471. valo has left
  472. j.r has left
  473. j.r has joined
  474. valo has joined
  475. j.r has left
  476. karoshi has joined
  477. igoose has left
  478. ThibG has left
  479. ThibG has joined
  480. igoose has joined
  481. rtq3 has joined
  482. Tobias has joined
  483. mikaela has joined
  484. contrapunctus has joined
  485. gengar has left
  486. gengar has joined
  487. 404.city has joined
  488. 404.city has left
  489. 404.city has joined
  490. gengar has left
  491. gengar has joined
  492. mimi89999 has left
  493. gengar has left
  494. gengar has joined
  495. gengar has left
  496. igoose has left
  497. mikaela has left
  498. mikaela has joined
  499. waqas has left
  500. gengar has joined
  501. alacer has left
  502. alacer has joined
  503. mikaela has left
  504. rtq3 has left
  505. mikaela has joined
  506. igoose has joined
  507. gengar has left
  508. moparisthebest has left
  509. rtq3 has joined
  510. ThibG has left
  511. moparisthebest has joined
  512. ThibG has joined
  513. mikaela has left
  514. mikaela has joined
  515. gengar has joined
  516. gengar has left
  517. gengar has joined
  518. kokonoe has left
  519. mimi89999 has joined
  520. flow MattJ, I am not sure if using existing building blocks caused confusion. It appears to me that not clarifying how they are intended to use and are allowed to use (think for example if <before/> and <after/> can be used in the same query) is causing confusion
  521. kokonoe has joined
  522. gengar has left
  523. j.r has joined
  524. rtq3 has left
  525. gengar has joined
  526. goffi has joined
  527. MattJ flow: they can't, the end :)
  528. flow That is what I would also say, but it is at least underspecified in XEP-RSM
  529. gengar has left
  530. mikaela has left
  531. mikaela has joined
  532. j.r has left
  533. j.r has joined
  534. gengar has joined
  535. j.r has left
  536. j.r has joined
  537. gengar has left
  538. 404.city has left
  539. gengar has joined
  540. Nekit has left
  541. igoose has left
  542. gengar has left
  543. gengar has joined
  544. igoose has joined
  545. gengar has left
  546. gengar has joined
  547. rtq3 has joined
  548. gengar has left
  549. mikaela has left
  550. mikaela has joined
  551. gengar has joined
  552. mikaela has left
  553. mikaela has joined
  554. Dele Olajide has joined
  555. kokonoe has left
  556. mikaela has left
  557. mikaela has joined
  558. gengar has left
  559. alameyo has left
  560. kokonoe has joined
  561. gengar has joined
  562. mikaela has left
  563. mikaela has joined
  564. Dele Olajide has left
  565. Dele Olajide has joined
  566. gengar has left
  567. UsL has left
  568. Dele Olajide has left
  569. Dele Olajide has joined
  570. arc has left
  571. arc has joined
  572. gengar has joined
  573. Dele Olajide has left
  574. Dele Olajide has joined
  575. debacle has joined
  576. gengar has left
  577. kokonoe has left
  578. kokonoe has joined
  579. gengar has joined
  580. gengar has left
  581. gengar has joined
  582. dele has joined
  583. gengar has left
  584. gengar has joined
  585. gengar has left
  586. Alex has joined
  587. intosi has joined
  588. gengar has joined
  589. gengar has left
  590. dele has left
  591. intosi has left
  592. Yagiza has joined
  593. mikaela has left
  594. mikaela has joined
  595. jubalh has joined
  596. gengar has joined
  597. gengar has left
  598. j.r has left
  599. j.r has joined
  600. blabla has left
  601. blabla has joined
  602. j.r has left
  603. jubalh has left
  604. intosi has joined
  605. gengar has joined
  606. j.r has joined
  607. gengar has left
  608. jubalh has joined
  609. frainz has left
  610. ThibG has left
  611. ThibG has joined
  612. frainz has joined
  613. intosi has left
  614. wurstsalat has left
  615. gengar has joined
  616. Holger has left
  617. Holger has joined
  618. gengar has left
  619. jubalh has left
  620. the other eion has joined
  621. gengar has joined
  622. moparisthebest has left
  623. gengar has left
  624. wurstsalat has joined
  625. Dele Olajide has left
  626. Yagiza has left
  627. kokonoe has left
  628. kokonoe has joined
  629. Andrew Nenakhov has left
  630. Andrew Nenakhov has joined
  631. alacer has left
  632. gengar has joined
  633. waqas has joined
  634. gengar has left
  635. gengar has joined
  636. gengar has left
  637. bowlofeggs has left
  638. bowlofeggs has joined
  639. bowlofeggs has left
  640. bowlofeggs has joined
  641. goffi has left
  642. Nekit has joined
  643. ThibG has left
  644. Nekit has left
  645. ThibG has joined
  646. andy has joined
  647. wurstsalat has left
  648. krauq has left
  649. the other eion has left
  650. eion has joined
  651. krauq has joined
  652. gengar has joined
  653. gengar has left
  654. kokonoe has left
  655. kokonoe has joined
  656. bowlofeggs has left
  657. bowlofeggs has joined
  658. igoose has left
  659. oli has joined
  660. igoose has joined
  661. moparisthebest has joined
  662. gengar has joined
  663. lovetox has left
  664. mikaela has left
  665. gengar has left
  666. ta has left
  667. ta has joined
  668. andy has left
  669. blabla has left
  670. gengar has joined
  671. gengar has left
  672. lnj has left
  673. debacle has left
  674. gengar has joined
  675. gengar has left
  676. kokonoe has left
  677. kokonoe has joined
  678. karoshi has left