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


  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


  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


  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


  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


  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


  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