XMPP Council - 2020-09-30


  1. paul has left
  2. SouL has left
  3. Wojtek has left
  4. stpeter has joined
  5. stpeter has left
  6. kusoneko has left
  7. kusoneko has joined
  8. adityaborikar has left
  9. adityaborikar has joined
  10. moparisthebest has left
  11. SouL has joined
  12. Tobias has joined
  13. paul has joined
  14. sonny has left
  15. sonny has joined
  16. sonny has left
  17. sonny has joined
  18. sonny has left
  19. sonny has joined
  20. sonny has left
  21. sonny has joined
  22. sonny has left
  23. sonny has joined
  24. sonny has left
  25. sonny has joined
  26. sonny has left
  27. sonny has joined
  28. sonny has left
  29. sonny has joined
  30. sonny has left
  31. sonny has joined
  32. sonny has left
  33. sonny has joined
  34. paul has left
  35. paul has joined
  36. adityaborikar has left
  37. adityaborikar has joined
  38. debacle has joined
  39. sonny has left
  40. sonny has joined
  41. sonny has left
  42. adityaborikar has left
  43. adityaborikar has joined
  44. sonny has joined
  45. sonny has left
  46. sonny has joined
  47. sonny has left
  48. neox has joined
  49. sonny has joined
  50. sonny has left
  51. debacle has left
  52. sonny has joined
  53. sonny has left
  54. sonny has joined
  55. sonny has left
  56. adityaborikar has left
  57. adityaborikar has joined
  58. sonny has joined
  59. adityaborikar has left
  60. adityaborikar has joined
  61. debacle has joined
  62. adityaborikar has left
  63. adityaborikar has joined
  64. neox has left
  65. neox has joined
  66. neox has left
  67. neox has joined
  68. neox has left
  69. neox has joined
  70. Syndace has left
  71. sonny has left
  72. sonny has joined
  73. stpeter has joined
  74. moparisthebest has joined
  75. sonny has left
  76. sonny has joined
  77. sonny has left
  78. stpeter has left
  79. sonny has joined
  80. sonny has left
  81. sonny has joined
  82. sonny has left
  83. sonny has joined
  84. sonny has left
  85. sonny has joined
  86. sonny has left
  87. sonny has joined
  88. sonny has left
  89. sonny has joined
  90. Syndace has joined
  91. sonny has left
  92. sonny has joined
  93. sonny has left
  94. sonny has joined
  95. adityaborikar has left
  96. adityaborikar has joined
  97. sonny has left
  98. sonny has joined
  99. sonny has left
  100. adityaborikar has left
  101. sonny has joined
  102. stpeter has joined
  103. sonny has left
  104. sonny has joined
  105. sonny has left
  106. sonny has joined
  107. Ge0rG I don't think I'll make it, but I'm +1 on the CS2021 XEP
  108. Ge0rG And on-list for the other items
  109. dwd has joined
  110. jonas’ 1) Roll Call
  111. Zash Here
  112. daniel Hi
  113. dwd Hello
  114. jonas’ Hi everyone
  115. jonas’ Ge0rG sent apologies, so moving on
  116. jonas’ 2) Agenda Bashing
  117. jonas’ Assuming nothing
  118. jonas’ 3) Editor’s Update
  119. jonas’ - New ProtoXEP: Compliance Suites 2021 - LC for XEP-0411 extended until 2020-10-14 after the original extension got lost in the void.
  120. jonas’ yeah, no idea what went wrong with that email, this one seems to have passed through
  121. jonas’ 4) Items for Voting
  122. jonas’ (sorry for being terse today)
  123. jonas’ 4a) PR#986: XEP-0277: pubsub#type MUST be set in bare PubSub URL: https://github.com/xsf/xeps/pull/986
  124. jonas’ I am on-list, I didn’t have the chance to read into what pubsub#type even is :)
  125. Zash I saw daniel comment that this is Experimental and thus not our thing to approve
  126. daniel what Zash said what I said
  127. Zash (actually Deferred, but still)
  128. jonas’ right, so this is not an item for vote, but an AOB
  129. jonas’ since pep. explicitly asked for guidance
  130. jonas’ let’s move it there and discuss it then, thanks for the hint
  131. Zash ack
  132. jonas’ 4b) PR#988: XEP-0060: Add integer-or-max datatype to use with Data Forms Validation URL: https://github.com/xsf/xeps/pull/988 Note: The idea behind is to formally define the behaviour of the max-items field in PubSub.
  133. pep. !
  134. daniel As I said on the list; I'd be willing to +1 this unless someone really wants to put this somewhere 60-agnostic
  135. daniel but i'm not even fully sure that 122 is a better place
  136. Zash Assuming the schema magic is sane, +1. It would be nice if the registry was working ;)
  137. jonas’ '122 wouldn’t be a better place either
  138. jonas’ '122 wouldn’t be a better place I think
  139. jonas’ '60 is "fine by me", though not excellent
  140. Zash New XEP?
  141. daniel so the only way to make it it agnostic is a brand new XEP?
  142. jonas’ Zash, seems like overkill if I ever saw one
  143. daniel which is overkill. so 60 it is?
  144. pep. I did think about making it a new XEP just to define the type, and then edit 0060 to use it :/
  145. jonas’ I’m on-list nevertheless, I want to understand if that schema stuff is right first
  146. pep. Not sure what's best
  147. jonas’ I got the gut feeling that it isn’t
  148. Zash jonas’: oh glob
  149. daniel anyway have my official +1
  150. pep. jonas’, got it from https://www.w3.org/TR/xmlschema-2/#union-datatypes
  151. daniel and then have someelse block it if they feel like it
  152. jonas’ I would’ve expected dwd to have a strong opinion here (subtle ping)
  153. dwd pep., Your thought is that it needs an edit to '60 either way? I think that's probably right, so we might as well have the registration there too.
  154. dwd On the schema, it looks right to me.
  155. pep. yeah 0060 needs editing in any case I'd say. Because I need to give meaning to the type
  156. pep. For each field using it
  157. Zash If you want it Generic, shouldn't it have a 'min' enum too?
  158. dwd pep., Yes, seems right.
  159. dwd Zash, Is min not equivalent to zero in any case?
  160. Zash dwd: only if it's unsigned
  161. pep. Zash, not against adding it, but yeah I'd say it's likely to be 0
  162. pep. right..
  163. Zash Is it?
  164. dwd Oh.
  165. pep. 'integer' is
  166. pep. signed.
  167. pep. Sorry
  168. dwd Is there an unsigned integer type?
  169. daniel I can’t think of a use case for 'min' and I rather not add something unless we have an explicit use
  170. pep. and infinite..
  171. pep. dwd, we can make one
  172. pep. But I'd think there is one already
  173. dwd Ugh.
  174. Zash And the semantics here is that 'max' is always whatever the acutal max is, even if you reconfigure it in the thing defining it?
  175. pep. daniel, if I split the thing into its own XEP I guess it might make sense
  176. daniel Zash yes
  177. dwd This feels like the sort of grinding down in detail that would be best done on the list. But anyway, I'm +1, but if you find improvements that's also good.
  178. daniel which is actually what I like about that
  179. jonas’ Zash, want to cast a vote?
  180. Zash +1
  181. dwd I'm also fine with this not needing a "min". If we want to expand later we can by having an integer-or-min-or-max or something.
  182. jonas’ let’s move on then
  183. jonas’ 4c) Proposed XMPP Extension: Compliance Suites 2021 URL: https://xmpp.org/extensions/inbox/cs-2021.html Abstract: ... you know it ...
  184. jonas’ +1
  185. daniel +1
  186. dwd (I apologise for not having the strong opinions jonas’ hoped for).
  187. dwd +1
  188. Zash +1
  189. jonas’ swift
  190. jonas’ 5) Pending Votes
  191. jonas’ a few on #983 from last week
  192. jonas’ me including, but then again, two people vetoed already
  193. jonas’ any need for discussion about that one?
  194. jonas’ oh, it’s the URI one
  195. adityaborikar has joined
  196. jonas’ the author agreed in the meantime that URI encoding should be used and we’re done
  197. jonas’ 6) Date of Next
  198. dwd You effectively pre-veto'd it.
  199. jonas’ +1w wfm
  200. daniel let me check
  201. dwd +1 to +1w wfm.
  202. jonas’ dwd, and by that you can see how awake I am today :D
  203. Zash +1w wfm
  204. pprrks has left
  205. daniel +1w wfm
  206. jonas’ neat
  207. jonas’ 7) AOB
  208. pprrks has joined
  209. neox has left
  210. jonas’ let’s insert the PR#986
  211. jonas’ -> https://github.com/xsf/xeps/pull/986
  212. jonas’ my stance doesn’t change (I need to read into this before I can provide guidance), but maybe someone else can
  213. Zash Opinion: This is good.
  214. daniel as I already said in the comments. _seems_ good to me. but i'm not an expert on microblogging. maybe someone else out there is using this on a different node for reasons?
  215. daniel it should really be left to the authors imho
  216. jonas’ note that pubsub#type is *not* the node ID
  217. jonas’ most of the authors I haven’t seen much around here lately
  218. pep. Yeah that's on purpose. The node ID is generally set to a UUID I think in Movim and/or Sàt
  219. dwd I think it's maybe a SHOULD and not a MUST. But I'd be curious as to what the authors say, as well as the Movim guys who (I think) use this heavily.
  220. pep. When not on PEP
  221. Zash edhelas seemed to approve: https://logs.xmpp.org/xsf/2020-09-30?p=h#2020-09-30-030be57f8039269d
  222. Zash and pep. said goffi did too
  223. dwd Oh, that's good then.
  224. daniel right. yes. just shows how not of an expert on microblogging I am
  225. daniel but if the two only implementors agree…
  226. Zash The #type field isn't super-well-defined tho
  227. dwd But experimental, so if those who want this want it this way, that's fine by me.
  228. jonas’ what is the benefit of using the pubsub#type?
  229. pep. Zash, true
  230. jonas’ is that something you can filter on when finding pubsub nodes?
  231. dwd jonas’, Discovery I guess.
  232. pep. The only thing that's normative about pubsub#type is "payload type"
  233. pep. The rest is somewhere in an example
  234. Zash AIUI it's meant to be an URI / namespace representing the payload type
  235. pep. jonas’, I don't think so, it's just that there might be multiple nodes using microblog on the same pubsub component
  236. pep. So you can't set them all to the same value
  237. jonas’ … to the same node ID
  238. jonas’ makes sense
  239. jonas’ but how does it help any entity then?
  240. Zash Theoretical filtering abilitity?
  241. jonas’ right
  242. jonas’ and maybe for showing stuff in a pubsub node directory or something
  243. Zash jonas’: microblog support for search.jabber.network !
  244. jonas’ of course :)
  245. daniel in that case a SHOULD should be fine?
  246. dwd If we ever did disco#search, it'd be useful.
  247. Wojtek has joined
  248. jonas’ yeah, so, I have little idea about microblogging. we’ll have to ping the authors anyway, but if the implementors agree, that’s already a good thing
  249. Zash Yeah, RFC 2119 expert comment on the MUST plz
  250. jonas’ daniel, any concrete reason why a MUST would not be desirable?
  251. pep. daniel, I feel that if it's a SHOULD in microblog, it makes this change moot. I said to Zash earlier "the XEP becomes unusable without the MUST the second another spec uses pubsub + atom"
  252. dwd Well, is it an absolute requirement for interoperability?
  253. pep. (because no, microblog is not just pubsub+atom)
  254. jonas’ how about we delegate that MUST/SHOULD debate to the authors?
  255. pep. hah
  256. daniel jonas’, i got the impression that it is a discovery/search thing? so if i don’t need it to be found
  257. dwd I mean, my gut feeling is SHOULD, but I'm not the expert here, and if those who are think if this is missing there's concrete interop harm then MUST it is.
  258. daniel but i'm really what ever on that
  259. Zash jonas’: sounds reasonable
  260. dwd daniel, I'm thinking if it's on the well-known node ID then it probably doesn't add value.
  261. daniel dwd, yes
  262. jonas’ then I’d like to move on to 7b
  263. dwd But I susp[ect this is bikeshed.
  264. jonas’ dwd, daniel, note that the text says that it’s not needed if on the well-known node ID
  265. jonas’ only if it isn’t
  266. jonas’ either way
  267. jonas’ pinging authors, moving on
  268. dwd I'm right then in my previous assertion. :-)
  269. daniel there might be other well knowns
  270. jonas’ 7b) Message Styling It was not advanced and the author disagrees with Council. What to do next?
  271. pep. daniel, not defined in microblog
  272. jonas’ formally, we should Reject it, right?
  273. daniel which one is message styling again? :-)
  274. jonas’ the one from Sam
  275. dwd Was Sam an outlier on this on the list, and did the community feel that the Council proposal was reasonable?
  276. jonas’ the one by Sam
  277. jonas’ unclear
  278. pep. daniel, 393
  279. Zash https://xmpp.org/extensions/xep-0393.html
  280. jonas’ there was lots of discussion I was not in the mood for reading *again* yesterday
  281. dwd Yeah, fair.
  282. jonas’ I think we should do sometihng about the status of '393
  283. jonas’ it is dangling in LC for a while now, and I’d like it if next council wouldn’t have to formally re-call it
  284. daniel sorry I wasn’t prepared to have that discussion
  285. dwd So, in general terms, our documents are meant to match our consensus as a group (not just Council, but everyone).
  286. jonas’ at the same time, I don’t feel like I can take it to go through that right now, so it’d be good if someone else was available to take that task
  287. daniel can someone share a link to the thread?
  288. daniel or the name/date
  289. jonas’ daniel, one second
  290. jonas’ it’s a minutes thread
  291. jonas’ [Standards] Council Minutes 2020-05-27
  292. jonas’ link in another second
  293. daniel thanks that's probably enough
  294. jonas’ https://mail.jabber.org/pipermail/standards/2020-May/037495.html
  295. jonas’ nice, pipermail doesn’t let you click next on that one
  296. jonas’ https://mail.jabber.org/pipermail/standards/2020-June/037496.html this may do
  297. dwd So if Sam, as author, is in the rough here, then he gets to say "I told you so", and not much else. But if there's no clear(ish) consensus, rough or otherwise, from the group on the way forward then that's not much help.
  298. Zash Because it goes into June
  299. daniel right. if I recall that thread correctly there wasn’t a clear community consensus
  300. daniel some (rightfully) hate the xep a lot for not being xhtml-im
  301. daniel but it also doesn’t try to be
  302. jonas’ quick question: can we extend by +10min to bring this to a more useful ending?
  303. daniel i personally probably would not vote to reject it
  304. daniel yes
  305. Zash shure
  306. Kev (Interjecting) ISTR there were some quite sensible suggestions made to make this a better imperfect solution to an impossible problem, which should probably have serious thought. Around opt-ins and the like.
  307. Kev returns to his corner
  308. jonas’ hands Kev some cookies
  309. daniel right. those changes (if we want them to) could be made by simply taking the XEP over instead of rejecting it
  310. pep. I also wasn't ready for this :P
  311. jonas’ pep., nobody ever is for a re-iteration of message {styling,theming,formatting}
  312. pep. Iirc even the opt-in/out mechanisms wouldn't really help
  313. daniel not making an argument for or against those signaling/opt-in/opt-out changes
  314. jonas’ daniel, yes
  315. Kev pep.: IIRC, the mechanisms couldn't make this a perfect solution to the impossible problem.
  316. Kev But did solve some of the issues.
  317. Kev But I don't have this swapped in at the moment, sadly.
  318. jonas’ nobody has
  319. eta one thing not addressed is "how do I have both a styled version and a fallback without adding ugly * everywhere"
  320. eta for example, spectrum2-discord currently makes user @mentions bold with xhtml-im
  321. jonas’ eta, this is not about completely re-doing Styling
  322. eta right
  323. jonas’ we have about one month left to properly bring this to a close.
  324. eta I mean as an informational document '393 is pretty good
  325. Kev Oh, that's an interesting thought.
  326. jonas’ the best way forward I can come up with is if everyone of us (council) wades through that thread and tries to extract the community consensus and then we act on the mean of that
  327. jonas’ the Informational track has been proposed before for '393
  328. pep. eta, I want to disagree :p
  329. Kev Sorry, I'm forgetting things in my old age.
  330. jonas’ I do not recall who strongly opposed that though; might’ve been sam, might’ve been me.
  331. jonas’ (which really says something)
  332. pep. I'd rather have that somewhere hidden / locked-away never to be seen again
  333. Kev I think I've aged about a decade in the last 6 months (I suspect I'm not alone)
  334. daniel I think someone said we can’t change tracks
  335. eta I mean it is a hack
  336. jonas’ hands more 🍪 to Kev
  337. eta but it's a relatively okay one
  338. daniel but i'd be fine with keeping it informational and roughly as is
  339. eta like vcard-temp
  340. jonas’ daniel, we can do everything, if we ask board for a '1 override (and they grant it)
  341. Zash eta: oh no u didn't!!1
  342. dwd I honestly don't know that there's community consensus, even rough, to do anything at all. Including doing nothing.
  343. daniel i mean we can try to go through the thread again. but something something vocal miniority and haters gonna hate and stuff
  344. daniel so at some point we probably just have to decide something
  345. Kev Oh, it looks like <unstyled/> has already made it in. Which, again, I'd forgotten. That improves things significantly, I think.
  346. daniel or let the next council deal with it :-)
  347. jonas’ OK, so, I’ll set up a bunch of votes for next week: 1. Should we find a way to move '393 to Informational and keep it there? 2. If the previous vote should fail, should we take ownership from Sam and rewrite '393 with a mandatory and explicit opt-in? 3. If the previous vote should fail, should we accept '393 as-is? 4. If the previous vote should fail, should we reject '393 as is or accept it as Draft?
  348. daniel > Oh, it looks like <unstyled/> has already made it in. Which, again, I'd forgotten. That improves things significantly, I think. +1
  349. dwd I don';t think there was consensus for explicit opt-in, actually.
  350. jonas’ can we agree on that list? and also on everyone swapping this in so that we can bring it to a close?
  351. Zash Gonna need to stock up on 🍪
  352. daniel yes
  353. pep. dwd, there wasn't indeed :/
  354. dwd Also popcorn.
  355. jonas’ I’m not sure if the positive response is to popcorn or my list
  356. daniel my 'yes' was regarding your list
  357. dwd I *think* there might be (very) rough consensus to have it with an explicit opt-out, and publishing it. Though whether as Informational or Standards Track, I don't know.
  358. jonas’ I put the votes on next week’s agenda
  359. Kev (Don't want to derail the meeting, so ignore this for the moment, but I think there is a strong argument for having a this-is-marked-up, which is not necessarily used for opt-in, because it allows you to strip the formatting, knowing that's what it is, ending up with something more $OTHER_MESSENGER (and more useful, I believe) - maybe not a hill to die on, but I think there isn't a reason it would be bad to tell people it's marked up)
  360. jonas’ and now I’d like to step away from this, and I also think that we can’t find a solution right now and here
  361. jonas’ any other AOB?
  362. pep. Kev, yes, and an argument for opt-in
  363. dwd Kev, https://mail.jabber.org/pipermail/standards/2020-June/037506.html I found reasonably compelling.
  364. Kev dwd: I *think* he's looking at using an opt-in, there, which has pros and cons, as opposed to simply an announcement that something is marked up?
  365. jonas’ I’m taking this as a no
  366. jonas’ 8) Ite Meeting Est
  367. jonas’ thanks everyone
  368. daniel Thank you jonas’
  369. pep. There were questions in #988, but I guess I'll poke people on xsf@ later on
  370. Kev Ah, no, he does address the third state towards the end.
  371. pep. Re datatype prefix
  372. Kev dwd: But he's not addressing it from a point of view of it being a known state. Maybe if I called it <strippable/> it would make the point for clearly. So you have three possible states of <strippable/>, <unstyled/> and nowt.
  373. Kev dwd: But he's not addressing it from a point of view of it being a known state. Maybe if I called it <strippable/> it would make the point more clearly. So you have three possible states of <strippable/>, <unstyled/> and nowt.
  374. pep. I guess I'm less annoyed about the XEP but more about its adoption. Devs thinking this is actually a good solution
  375. dwd Kev, A point you indeed raised in the thread.
  376. Kev Oh, did I? How refreshing for me to be consistent :)
  377. jonas’ move that to xsf@ maybe?
  378. daniel pep.: isn't the adoption one client
  379. pep. yours?
  380. daniel And one client that copy pasted the code
  381. dwd Kev, I'm basically finding myself on the same rollercoaster I suspect I was on when I first read the thread.
  382. dwd Kev, And also, June feels like years ago.
  383. Kev What the ... that was THIS YEAR?
  384. daniel Which is actually slightly frustrating because Dino and Gajim render it slightly different
  385. daniel But not different enough
  386. jonas’ Time flies like an arrow (fruit flies like a banana, though).
  387. daniel (unless either of them 'fixed' this recently)
  388. dwd daniel, IIRC, Psi implemented (basically) this about a decade ago.
  389. daniel With emphasis on _basically_
  390. pep. You mean yet another variant?
  391. eta XHTML-IM wasn't that bad
  392. eta ducks
  393. Kev I think Psi was the first XMPP client to do this.
  394. Zash Gajim also had something like this since time immemorial
  395. dwd pep., Part of Sam's intent here was to unify the variants, in fairness.
  396. Kev eta: That's the upsetting thing, XHTML-IM *wasn't* that bad.
  397. daniel The idea is the same. But the exact implementations vary
  398. daniel Which can be annoying in certain cornor cases
  399. dwd eta, The problem with XHTML-IM was that virtually every implementation had security flaws.
  400. Kev https://mail.jabber.org/pipermail/standards/2020-June/037514.html I think the point I made there still stands, basically, although I had no idea it was only two months ago I raised it.
  401. Kev https://mail.jabber.org/pipermail/standards/2020-June/037514.html I think the point I made there still stands, basically, although I had no idea it was only three months ago I raised it.
  402. pep. dwd, I think my bitterness about 393 is mostly due to the fact that this came up right after XHTML-IM was "killed", and proposed as some kind of replacement that it isn't
  403. daniel I don't recall the time line being in that order
  404. Zash And the irony in literally everything else (outside XMPP) uses something like XHTML-IM, but embedded in JSON
  405. pep. yeah
  406. eta yeah exactly
  407. Kev Zash: Ah, although with one major difference, I think.
  408. eta dwd: this is only because people just shoved the XHTML into a webview or something stupid
  409. Kev Zash: Not duplicating the body (maybe that's only a concern for us, but it's a major concern when you have two different representations that could have completely different content, shown to different users)
  410. eta like if you tree walk the XHTML you don't have this problem
  411. Zash Kev: Matrix duplicates the body.
  412. Kev eta: I think it's more than that. You can be trying quite hard to not be stupid, and still fall foul of things.
  413. Zash And also tripples it if you make a correction iirc.
  414. daniel I think the fault here is that xhtml-im was too broad and invited doing exactly that (putting it in a web view)
  415. pep. daniel, too broad? there's a nice whitelist there
  416. daniel Or more limited scope (same feature set as 393) could have prevented that
  417. eta Kev: yeah, okay, stupid is an unnecessarily caustic word :)
  418. dwd eta, Yes, but while we know what people are meant to do, and even designed XHTML-IM to support same, nobody did it that way at first.
  419. daniel pep.: it has css
  420. Zash daniel: tbf, the css also has a whitelist
  421. pep. CSS1 yeah
  422. daniel But I'm not gonna write an css parser
  423. eta but something that is actually XML based instead would be bettee
  424. eta r*
  425. jonas’ I strongly suggest to move this to xsf@
  426. eta like even if it's <bold>whatever</>
  427. daniel When the alternative of putting it an a web view is so easy
  428. pep. jonas’, I'd just try to kill the chat :p
  429. jonas’ pep., I could, but it’d take down xsf@ with it :>
  430. pep. *disband*
  431. pep. (both!)
  432. debacle has left
  433. sonny has left
  434. sonny has joined
  435. sonny has left
  436. sonny has joined
  437. sonny has left
  438. sonny has joined
  439. neox has joined
  440. Lance has joined
  441. sonny has left
  442. sonny has joined
  443. sonny has left
  444. sonny has joined
  445. kusoneko has left
  446. kusoneko has joined
  447. sonny has left
  448. kusoneko has left
  449. kusoneko has joined
  450. kusoneko has left
  451. kusoneko has joined
  452. sonny has joined
  453. sonny has left
  454. debacle has joined
  455. sonny has joined
  456. sonny has left
  457. sonny has joined
  458. sonny has left
  459. sonny has joined
  460. sonny has left
  461. sonny has joined
  462. sonny has left
  463. Tobias has left
  464. Wojtek has left
  465. Wojtek has joined
  466. sonny has joined
  467. sonny has left
  468. sonny has joined
  469. sonny has left
  470. sonny has joined
  471. stpeter has left
  472. debacle has left
  473. stpeter has joined
  474. sonny has left
  475. Wojtek has left
  476. sonny has joined
  477. sonny has left
  478. sonny has joined
  479. sonny has left
  480. neox has left
  481. SouL has left
  482. sonny has joined
  483. sonny has left
  484. sonny has joined
  485. stpeter has left