XMPP Council - 2017-03-08

  1. moparisthebest has left

  2. moparisthebest has joined

  3. Lance has joined

  4. Lance has left

  5. Tobias has left

  6. Tobias has left

  7. daniel has left

  8. daniel has joined

  9. daniel has left

  10. daniel has joined

  11. jere has joined

  12. Zash has left

  13. jere has left

  14. Zash has left

  15. SamWhited has left

  16. ralphm has left

  17. moparisthebest has joined

  18. daniel has left

  19. daniel has joined

  20. daniel has left

  21. daniel has joined

  22. daniel has left

  23. daniel has joined

  24. Flow has joined

  25. ralphm has left

  26. daniel has left

  27. daniel has joined

  28. Kev has joined

  29. Tobias has left

  30. Tobias has left

  31. daniel has left

  32. daniel has joined

  33. Zash has joined

  34. daniel has left

  35. daniel has joined

  36. daniel has left

  37. daniel has joined

  38. daniel has left

  39. daniel has joined

  40. daniel has left

  41. daniel has joined

  42. jere has joined

  43. jere has left

  44. jere has joined

  45. daniel has left

  46. daniel has joined

  47. daniel has left

  48. daniel has joined

  49. daniel has left

  50. daniel has joined

  51. Tobias has left

  52. Tobias

    I won't be able to make it to todays council meeting. Would be great if someone else could chair the meeting this time.

  53. jere has left

  54. jere has joined

  55. daniel has left

  56. Tobias

    or we postpone it to next week if there's nobody else to chair

  57. SamWhited

    I'll do it

  58. SamWhited

    Unless someone else wants too; but happy to so that we can have a meeting

  59. Tobias

    great, ta. Will read the logs tomorrow then.

  60. ralphm has left

  61. jere has left

  62. jere has joined

  63. daniel has left

  64. peter has joined

  65. Flow has joined

  66. Zash has left

  67. Tobias has joined

  68. Zash has joined

  69. Flow has joined

  70. peter has left

  71. Flow has joined

  72. SamWhited

    The time is come.

  73. SamWhited

    Who's here?

  74. daniel


  75. Link Mauve

    Me too.

  76. SamWhited

    I see no Dave

  77. SamWhited

    But we can muddle through

  78. SamWhited

    1. Minutes Taker?

  79. daniel

    since JC isn't here I can do it

  80. SamWhited


  81. SamWhited

    2. Entity Caps 2 ProtoXEP https://xmpp.org/extensions/inbox/ecaps2.html

  82. SamWhited

    Any discussion before we vote?

  83. daniel


  84. SamWhited

    I'll be on list

  85. daniel

    SamWhited, do you think there is something that should be discussed?

  86. daniel

    regarding just updating entity caps 1?

  87. SamWhited

    daniel: Not in particular; I still need to read it again, I only briefly scanned it

  88. Link Mauve

    daniel, whether we accept it as a new XEP or as an update to 0115, mostly.

  89. SamWhited

    Since 0115 is already in draft and this is radically different in some ways (I think?) I'm inclined to think this needs to be a new XEP personally.

  90. SamWhited

    But since it's only the three of us, maybe we should save that for list discussion along with the outstanding votes?

  91. daniel


  92. Link Mauve

    I am of the same opinion, other XEPs currently “depending” on 0115 should be updated to say something like “use 0030, or any caching mechanism like ecaps2.”

  93. Kev

    I maintain that I think a new XEP here is more trouble than it's worth :)

  94. Kev

    I don't think it's conceptually any different to 115, is it?

  95. Link Mauve

    It’s not.

  96. SamWhited

    Let's discuss on list since so many people aren't here. Link Mauve: will you create a thread for this in response to the minutes being sent out?

  97. Link Mauve


  98. SamWhited


  99. SamWhited

    3. LC for XEP-0333

  100. SamWhited

    The LC has ended, but I think Daniel wants to submit changes before we vote?

  101. daniel

    SamWhited, just let it fall out of LC back to experimental again. i need more time than a week or so

  102. SamWhited

    Will do; moving to the editors column.

  103. daniel

    i guess we can formally vote -1 if necessary

  104. Link Mauve


  105. SamWhited

    If the author (or steward) says it's not ready that sounds like enough to me personally :)

  106. SamWhited

    4. Vote on advancing XEP-0233 version 0.5.1 to Draft

  107. Holger has left

  108. SamWhited

    I'm +1

  109. daniel


  110. Link Mauve

    I’m +1 too.

  111. SamWhited

    Others to vote on list; excellent.

  112. SamWhited

    5. Several PRs relating to CSI/Carbons state after SM resumption

  113. SamWhited


  114. SamWhited

    I think the PRs listed on this card need our attention

  115. SamWhited

    I'm not sure that there's anything to do but mention that they exist

  116. SamWhited

    Only the 0198 one needs council, if I understand this correctly

  117. ralphm has left

  118. daniel

    i'm not sure that's a good idea

  119. SamWhited

    Which one? Maybe I should have broken this up

  120. daniel

    by adding that you are basically forcing the carbons ns bump

  121. daniel

    the one about 0198

  122. daniel

    by delegating the responsibilty to the individual XEPs you requrie namespace bumps on those xeps

  123. SamWhited

    I'm unsure if I think it helps or hurts, but I sort of think the 0198 change is unnecessary either way.

  124. daniel

    i'm not even sure where the idea that a carbon state or a csi state is undefined after a resumption comes from. is it really?

  125. daniel

    did this ever cause unexpected behaviour in real life?

  126. daniel

    or a dissagreement between server developers?

  127. Link Mauve

    This sounds more of a design problem of nonza than something that needs to be specified that way, actually.

  128. SamWhited

    I'm not sure if it's ever actually caused problems, but I do think it's undefined (and we should probably not leave behavior undefined)

  129. Kev

    I'm not entirely sure I understand why this is an issue at all.

  130. Kev

    Sure you're resuming everything in the same state it was in before?

  131. Kev

    The point of 198 resumption is to pick up where you left off.

  132. Kev


  133. SamWhited

    That was always my assumption

  134. daniel

    but you enable feature X (csi, carbons what ever) for a *stream*. and then you resume a s*stream*

  135. daniel

    why would that be gone after a resume?

  136. Kev

    Surely this is a one-line editorial fix in 198 to make this clearer, if it's possible to misread it if you squint hard?

  137. daniel

    so i don't agree with the notion that this is undefined behaviour

  138. daniel

    or what Kev that

  139. SamWhited

    I think I agree with Kev; do we want to vote on the 198 changes in their current form today (even if we're all on list) and then consider an alternative if necessary later?

  140. daniel

    but it should be up to the carbons or csi xeps

  141. daniel

    SamWhited, we are talking about #429 right?

  142. daniel

    just to be sure

  143. SamWhited

    Yes, sorry

  144. Holger

    The CSI state has to be reset because the CSI nonzas cannot be acknowledged.

  145. daniel

    *but it should NOT be up to the (in case that wasn't clear from the context)

  146. Holger

    So if a CSI nonza was sent before resumption, the client wouldn't know whether the server processed it.

  147. SamWhited

    ah right, that makes sense

  148. Holger

    This was the reasoning for resetting the CSI state on resumption.

  149. Zash

    Is the CSI state attached to the TCP-bound stream or the resource/long lived session?

  150. daniel

    Holger, but that's an orthogonal problem

  151. moparisthebest

    how can you *ever* be sure the server got the nonza and enabled CSI though? if you go down that rabbit hole do you just have to continually send it every minute or something?

  152. SamWhited

    That still sounds like a 1 line change to CSI saying "after resumption, update the state since we're not sure if it stuck"

  153. Link Mauve

    moparisthebest, the next stanza you send will be acked, and then you know the csi one got sent.

  154. daniel

    Zash, i think in general CSI applies to the stream. the fact that you can't be sure if the server got the active/inactive is a different problem

  155. daniel

    that will basically force you to resent it every time

  156. moparisthebest

    Link Mauve, so then only re-set it after stream resumption if you didn't get an ack for your next message?

  157. SamWhited

    I thihnk that makes #427 wrong, even though the behavior is correct. It explicitly says that the CSI state is *not* restored: https://github.com/xsf/xeps/pull/427/files

  158. SamWhited

    If there was a next message at all

  159. Holger

    moparisthebest: That's completely weirdo.

  160. Holger

    It must be reset.

  161. daniel

    SamWhited, yes i think it is wrong

  162. daniel


  163. Holger

    If you don't want that use stanzas instead.

  164. moparisthebest

    sounds like nonza's in general are completely wierdo Holger :)

  165. SamWhited

    So, action items thus far:

  166. moparisthebest

    kinda like using UDP when you want TCP guarantees... anyway

  167. SamWhited

    1. Comment on the CSI PR (#427) and say we think it needs work (although it's actually between the author and whomever made the PR)

  168. Holger

    moparisthebest: They might be the wrong choice for CSI (some argue this way), yes. But as long as we stick to them the CSI state must be reset.

  169. SamWhited

    Daniel: Can you comment there and mention this, or maybe bring it up for discussion if there's disagreement?

  170. daniel

    SamWhited, on the #427 one?

  171. SamWhited

    daniel: yes

  172. daniel

    yes i can do that

  173. Link Mauve

    SamWhited, 2. review the CSI discussion for nonza vs. stanza, and potentially switch to stanza?

  174. SamWhited

    Link Mauve: Yah, that might be where that discussion goes, but for now we can get the quick fix of just tweaking that PR and merging it

  175. Link Mauve


  176. SamWhited

    2.1: Vote on #429 (even if we're all just on-list)

  177. daniel

    i'm fine with voting right now. i'm going -1 on that

  178. SamWhited

    I'm also -1

  179. Link Mauve

    -1 too.

  180. SamWhited

    cool, that only leaves #428 from that discussion. Do we actually want (or need) to discuss it?

  181. daniel

    i think we already did discuss this?

  182. SamWhited

    Did we? Oops, in that case, we can probably move on.

  183. Link Mauve

    428 is basically “this is a stanza, no problem here”.

  184. SamWhited

    5 (I think). Add <x/> tag to MUC-PMs: https://github.com/xsf/xeps/pull/436

  185. SamWhited

    I do not fully understand this yet, but it appears to bump the carbons version in expectation of that carbons PR being merged

  186. Link Mauve

    Didn’t we already vote on that last week?

  187. daniel

    i honestly have no hard feelings either way. I've personally given up on MUC

  188. SamWhited

    Link Mauve: Did we? I really can't keep track of this stuff, it was just listed in the Trello…

  189. Link Mauve

    Let me check.

  190. SamWhited

    oh no, I'm sorry, this does not change the carbons namespace, ignore me.

  191. SamWhited

    I wasn't even looking at the right PR.

  192. Link Mauve

    SamWhited, section 2) of the previous minutes.

  193. daniel

    the thing is that #436 removes one side effect and introduces another

  194. daniel

    (arguably minor one?)

  195. daniel

    i actually don't think MUC can be fixed

  196. SamWhited

    cool, so it's apparently still just missing a few votes. I'll vote on list, apologies for the confusion.

  197. SamWhited

    Does anyone else want to vote (looks like we didn't vote, just said we'd vote next week)

  198. SamWhited

    Except for Link Mauve, he's ahead of the game :)

  199. Link Mauve

    (I just fixed that on trello.)

  200. SamWhited

    Perfect; official vote. I'm on list. daniel?

  201. daniel

    i don't know. i'm really torn. i think i should maybe block this... i'll vote on list

  202. SamWhited


  203. Zash has left

  204. SamWhited

    This was put on the agenda, but I'm not sure why: https://mail.jabber.org/pipermail/standards/2017-February/032328.html

  205. Zash has joined

  206. SamWhited

    Since we just voted on ecaps2, I guess moving on?

  207. SamWhited

    Or maybe we are supposed to come up with a migration plan for SHA-1 in general (although it's worth noting that it doesn't really affect anything yet, or XMPP possibly at all)

  208. SamWhited

    (that's 6. I guess)

  209. SamWhited

    Let's call it mentioned and move on unless anyone objects

  210. SamWhited

    I'm hearing crickets.

  211. SamWhited

    7. IEEE IoT email

  212. daniel

    no objections

  213. Link Mauve

    I have on my TODO list to start reviewing every usage of SHA-1 we have, but haven’t done anything yet.

  214. Link Mauve

    (Sorry, re 6.)

  215. SamWhited

    Link Mauve: Perfect, let's call that an action item for you then: SHA-1 review and migration plan. Thanks!

  216. Zash

    Link Mauve: Like https://xmpp.org/extensions/xep-0300.html#existing ?

  217. Link Mauve

    SamWhited, what is this email about?

  218. Link Mauve

    Zash, right.

  219. SamWhited

    RE 7: A motly crew of random people got CCed on an email from the IEEE IoT working group (or something) asking us to fast track the IoT XEPs which are currently deferred. Arc apparently had coffee with the person who sent the email, and it was decided that we should probably interact with their WG

  220. SamWhited

    since they're using XMPP for all IoT things, but don't actually have any XSF members

  221. SamWhited

    Dave suggested we assign a council liason to the IEEE

  222. Link Mauve

    Wasn’t that the purpose of the IoT SIG already?

  223. SamWhited

    and the board requested that we work with Rikard and the IoT SIG to come up with a strategy for the current IoT work

  224. SamWhited

    yes, I think the idea was just to get council involved.

  225. SamWhited

    I think since no one's here, we should just send out an email about this and discuss on list, unless anyone wants to suggest a specific plan or volunteer to work with the IoT SIG?

  226. SamWhited

    Either way I'm happy to write that email

  227. SamWhited

    Any volunteers?

  228. SamWhited

    (I'm happy to write the email, I am not volunteering to be the IoT liason)

  229. Link Mauve

    Didn’t we already elect stpeter as the representative of the council to the SIG?

  230. SamWhited

    I think we did, but since then Peter has gotten busy and not really involved right now, I don't think we can actually burden him with more work (and he's not on the council)

  231. SamWhited

    I'll send out an email to council@ and we can discuss specific plans (or we can discuss again next time we're all here). I'm not 100% sure what Dave et al. had in mind, so we can wait for their feedback before addressing this.

  232. SamWhited

    8 (maybe). Date of Next

  233. Link Mauve

    I won’t be here at all next week, fyi.

  234. SamWhited

    Same time next week?

  235. daniel


  236. SamWhited

    2017-03-15 1600Z it is

  237. SamWhited

    9. AOB

  238. SamWhited

    I have some, but it's brief and can be last

  239. daniel

    i don't have any

  240. Link Mauve

    Me neither.

  241. SamWhited

    Cool, mine is just pending vote reminders:

  242. SamWhited

    XEP-0368 to draft: Link Mauve, SASL2: Link Mauve, IBR2: Link Mauve, Daniel. Please vote; thanks!

  243. SamWhited


  244. Link Mauve

    Thank you.

  245. SamWhited

    Thanks everybody

  246. daniel

    thank you

  247. moparisthebest

    I think XEP-0368 to draft times out to day anyway

  248. moparisthebest

    I think XEP-0368 to draft times out today anyway

  249. SamWhited

    yah, I thihnk you're right

  250. SamWhited

    Link Mauve: You have until EOB central time when I'm going to put my editor hat on and call it :)

  251. moparisthebest

    or times in, but that sounds odd

  252. Link Mauve

    Alright, I’ll take a few more minutes off work to handle that then!

  253. moparisthebest

    now that meeting is over, so Holger what I'm asking is with a nonza how can I be sure the server *ever* got it, even not counting stream resumption now?

  254. Holger

    moparisthebest: You have this guarantee (as Link Mauve or someone mentioned): https://xmpp.org/extensions/xep-0352.html#in-order-processing

  255. Holger

    moparisthebest: You no longer have that if the stream is resumed after sending a CSI element and before a following stanza was acknowledged by the server.

  256. moparisthebest

    so then as horrible as it sounds, why not mark csi as 'acked' in the client when you recieve the next 'ack' for your next stanza?

  257. SamWhited

    Link Mauve: Thanks! Don't forget the 0115/ecaps2 email too (not that that has to happen right away). Also reminder to me: I'm going to go draft one about the IEEE IoT stuff.

  258. moparisthebest


  259. Holger

    moparisthebest: The server would have to know whether the client has marked this as 'acked' in order to decide whether to reset the CSI state :-)

  260. Link Mauve

    SamWhited, ok.

  261. moparisthebest

    but yea in general, nonzas sound like they are useful for here is this but I don't care whether you get it or not, and not in any way appropriate for modifying state on either side, or keeping state in sync

  262. Holger

    moparisthebest: Just reset it or use stanzas. I agree that resetting the state doesn't feel elegant, but I think that's a purely academic issue, I don't see the problem in practice. If protocol elegance is what you're after, you should not be doing XMPP :-)

  263. moparisthebest

    so what your saying is we should all re-invent the wheel with our own json over http protocols?

  264. moparisthebest

    so what you're saying is we should all re-invent the wheel with our own json over http protocols?

  265. Holger

    If you want elegance, yes. I find compatibility way more important, which is why I'm doing XMPP rather than Matrix.

  266. moparisthebest

    what is the history for using a nonza there in the first place?

  267. moparisthebest

    I feel like I'm missing some context

  268. SamWhited

    I think it just makes sense; it's a thing you only ever need to send to the server, so it doesn't need to be routable, and it's not mission critical, so fire-and-forget is fine.

  269. SamWhited

    It matches the nonza use case perfectly, I think.

  270. moparisthebest

    it modifies state though? and is mission critical if your mission is please don't murder my phone battery

  271. Holger

    moparisthebest: Find a room where both Ge0rg and Flow are joined, prepare yourself with some popcorn, mention the topic, and you'll have the context.

  272. Zash

    Holger: What have you done!

  273. moparisthebest

    I'll wait for flow to join prosody and have at it haha

  274. Kev

    SamWhited: Actually, I think it's telling the server to do something on your behalf, so an iq to your bare JID (no to=) is probably pretty sensible too.

  275. Kev

    Stanzas are the building blocks of XMPP. Investing new top level elements is possible, of course, but there are implications (see the current discussion on interactions with 198).

  276. SamWhited

    Kev: Yah, that makes sense too, I just don't see the need for an ack, and I like it when things aren't routable.

  277. Kev

    I don't know what my opinion was in the past, but right now I think my opinion is largely that this should have been an iq.

  278. Holger

    I agree, but I'm not sure switching to stanzas now is worth the trouble.

  279. Kev

    I think 'not routable' isn't really much of an argument. If it's an iq to your bare JID, your server already understands how to deal with it. If it's a new element type, that means new code paths (probably, maybe, potentially, depending on server design).

  280. SamWhited

    If it is routable, but not intended for anyone else but the server, that's a chance for an XMPP library to break in unexpected ways

  281. SamWhited

    (to break in unexpected ways when I try to send them a CSI IQ even though technically they shouldn't ever get one as a client, for instance)

  282. SamWhited

    I generally just like keeping the scope of things as limited as possible

  283. SamWhited

    But I agree, it's not likely to be an issue in this case

  284. Holger

    CSI elements don't need to be routed but I do see need for an ACK, so we don't have a perfect fit for this.

  285. Kev

    SamWhited: I don't buy that, really. Receiving stuff you don't expect is kinda a core part of extensibility.

  286. SamWhited

    Yah, but that doesn't mean we can't limit that possibility on the server as much as possible if it doesn't cause any other problems

  287. SamWhited

    Which I think it doesn't in this case, but obviously others disagree

  288. moparisthebest

    good call Holger , that's a perfect fit for a nostanza

  289. moparisthebest

    which doesn't get routed, but does get ACKd

  290. Holger

    Given limited manpower, I think we should try to distinguish between real problems and cosmetic issues and concentrate on the former as long as we have those :-)

  291. moparisthebest

    nonstanza maybe, I'm not married to the name, everyone wants a new top level element right? :P

  292. moparisthebest

    but yea about the issue at hand it seems fairly clear CSI needs to be a stanza, or re-sent on session resumption if something didn't get acked after it was sent before, or something, yuck

  293. moparisthebest

    or you just re-send it on every session resumption and call it a day

  294. Kev

    FWIW, I don't think there'd be significant pain in migrating to iqs instead of non-stanza elements.

  295. Holger

    I'd rather avoid spamming the code of implementations with both solutions for no good reason.

  296. Lance has joined

  297. Kev

    I think that's fair.

  298. Kev

    It's Experimental though, right? :)

  299. Holger

    I'm in the Council room so I was expecting this response :-)

  300. SamWhited

    Yah, but it's one of those experimental XEPs that we left until everyone was using it; at that point it's practically defacto draft and we should be careful with changes, I think (I'm not saying we should treat it exactly like draft, but we should be careful not to leave stuff in experimental this long until it's so widely used)

  301. Holger

    Yes looking at such issues from a practical perspective rather than blindly applying formal rules sounds like a great idea to me :-)

  302. Holger goes AFK and therefore stops trolling, have a nice evening everyone.

  303. Holger has left

  304. Kev

    I think a line saying "Look, this should have been a stanza (take note future authors), but it's not, so we need to reset it on a new stream just in case" is probably not daft.

  305. SamWhited

    Yah, I don't think that would be a problem

  306. SamWhited

    Although I also disagree that it should have been a stanza; but mentioning that you may need to send it again on stream restart seems fine.

  307. Kev

    I think that this discussion shows that in practical terms pretty much everything needs to be a stanza, so that 198 works.

  308. SamWhited

    198 does work; if the server got the CSI thing, then the stream state will remain the same and no reset is necessary. If it didn't, then it's exactly the same as if it didn't get it and the stream wasn't resumed: the state just never got changed (which I think is fine in this case)

  309. daniel

    SamWhited, +1

  310. Kev

    Yes, it works in the sense of it will not be broken.

  311. Kev

    But in terms of you needing to resend it after a restart because you don't know whether it was received isn't exactly 'working'.

  312. jere has left

  313. jere has joined

  314. SamWhited

    I just don't think that's a problem; however, if it is, the fix is easy: just always send it after a restart. I don't think it's necessary, but I also don't think it's a problem. It's an easy fix.

  315. Kev

    Changing to something much less bikesheddish:

  316. Kev


  317. Kev

    Surely we can't merge that?

  318. Kev

    It renders existing implementations non-compliant, and poses a potential interop problem.

  319. daniel

    you said *less* bikesheddish?

  320. SamWhited

    It is a SHOULD, not a MUST (but I'm leaning that way too)

  321. Kev

    Yes, this is a real issue, rather than cosmetic.

  322. Kev

    SamWhited: A SHOULD means you can rely on it, pretty much, because anyone not doing it made a deliberate decision.

  323. SamWhited

    Kev: What I heard there is "you can't rely on it" :)

  324. Kev

    SamWhited: Then it should be MAY.

  325. daniel

    we could just bump the muc namespace :-)

  326. Kev

    SHOULD means you can rely on it.

  327. Kev

    At the least it needs text saying that while a service/client SHOULD attach it, receiving entities can't assume that it'll be present, because $REASONS.

  328. Kev

    If we really do want to make it either SHOULD or MUST without further explanation, then yes, you're needing a namespace bump.

  329. Kev

    I suggest a namespace bump would be ludicrously stupid, and instead we need wording that doesn't introduce interop concerns.

  330. SamWhited

    yah, I agree; if it requires a namespace bump I'm absolutely -1

  331. SamWhited

    But I'm also fairly convinced that we should take MUC out behind the chemical shed and shoot it (and by that I meant that MUC is always going to be a bad experience, and there is nothing we can do about it, so we shouldn't bother)

  332. SamWhited

    But we definitely shouldn't make it *worse* (which a namespace bump would do)

  333. Kev

    I think that an additional sentence saying something approximately "Note that this requirement was added late in MUC's life, when implementations were already stable, and thus clients MUST NOT rely on receiving this element".

  334. Kev

    would probably be sufficient to get this text in there, while not breaking anything.

  335. SamWhited

    yah, that seems sane

  336. daniel

    i think everyone (including the author of the PR) will probably be fine with MAY

  337. SamWhited

    or that

  338. Kev

    MAY would not introduce an interop concern, so I'm far less opposed to it.

  339. Kev

    But I think better would be to make it clear that it's a good idea to do it.

  340. daniel

    can someone create a comment on the PR basically pasting the last couple of lines

  341. daniel

    because i really agree with SamWhited that MUC needs to die already and we shouldn't spend hours discussing these things

  342. SamWhited

    (I can't copy/paste easily from mcabber or I would)

  343. daniel


  344. Kev

    I suggest someone Council does it, but I'll do it if not.

  345. daniel

    ok i'll do it

  346. Kev


  347. Kev

    I think my suggested text is the best option, but I'm far fewer Fs about that than about not merging the PR as-is.

  348. daniel has left

  349. daniel has left

  350. Holger has left

  351. daniel has left

  352. Kev has left

  353. daniel has left

  354. Lance has left

  355. daniel has left

  356. Lance has joined

  357. daniel has left

  358. daniel has left

  359. daniel has left

  360. Tobias has left

  361. daniel has left

  362. daniel has left

  363. daniel has left

  364. daniel has left

  365. daniel has left

  366. daniel has left

  367. Lance has left

  368. daniel has left

  369. daniel has left

  370. daniel has left

  371. daniel has left

  372. daniel has left

  373. daniel has left

  374. Lance has joined

  375. daniel has left

  376. daniel has left

  377. daniel has left

  378. moparisthebest has joined

  379. Tobias has left

  380. moparisthebest has left

  381. moparisthebest has joined

  382. moparisthebest has joined

  383. moparisthebest has joined

  384. SamWhited has left

  385. daniel has left

  386. jere has joined