XSF Discussion - 2019-07-20

  1. mimi89999 has left

  2. mimi89999 has joined

  3. mimi89999 has left

  4. mimi89999 has joined

  5. adityaborikar has left

  6. adityaborikar has joined

  7. mimi89999 has left

  8. mimi89999 has joined

  9. Douglas Terabyte has joined

  10. mimi89999 has left

  11. mimi89999 has joined

  12. mimi89999 has left

  13. mimi89999 has joined

  14. mimi89999 has left

  15. mimi89999 has joined

  16. mimi89999 has left

  17. mimi89999 has joined

  18. mimi89999 has left

  19. mimi89999 has joined

  20. david has joined

  21. lumi has left

  22. valo has left

  23. valo has joined

  24. andy has left

  25. lskdjf has left

  26. benne has left

  27. benne has joined

  28. valo has left

  29. valo has joined

  30. alacer has joined

  31. benne has left

  32. pdurbin has joined

  33. pdurbin has left

  34. neshtaxmpp has left

  35. neshtaxmpp has joined

  36. valo has left

  37. valo has joined

  38. igoose has left

  39. igoose has joined

  40. pdurbin has joined

  41. adityaborikar has left

  42. david has left

  43. david has joined

  44. patrick has left

  45. patrick has joined

  46. UsL has left

  47. patrick has left

  48. zach has left

  49. zach has joined

  50. patrick has joined

  51. waqas has joined

  52. igoose has left

  53. adityaborikar has joined

  54. adityaborikar has left

  55. pdurbin has left

  56. karoshi has joined

  57. pdurbin has joined

  58. igoose has joined

  59. alacer has left

  60. alacer has joined

  61. adityaborikar has joined

  62. igoose has left

  63. lnj has joined

  64. Mikaela has joined

  65. andy has joined

  66. goffi has joined

  67. waqas has left

  68. wurstsalat has joined

  69. lovetox has left

  70. Nekit has joined

  71. debacle has joined

  72. curen has joined

  73. valo has left

  74. mimi89999 has left

  75. valo has joined

  76. mimi89999 has joined

  77. UsL has joined

  78. Lance has left

  79. rion has left

  80. rion has joined

  81. benne has joined

  82. benne has left

  83. benne has joined

  84. debacle has left

  85. rion has left

  86. rion has joined

  87. matlag has left

  88. matlag has joined

  89. eevvoor has joined

  90. igoose has joined

  91. lskdjf has joined

  92. lskdjf has left

  93. lskdjf has joined

  94. lumi has joined

  95. Andrew Nenakhov has left

  96. Andrew Nenakhov has joined

  97. krauq has left

  98. krauq has joined

  99. Andrew Nenakhov has left

  100. curen has left

  101. Andrew Nenakhov has joined

  102. adityaborikar has left

  103. adityaborikar has joined

  104. Andrew Nenakhov has left

  105. rion has left

  106. rion has joined

  107. eevvoor has left

  108. tom has left

  109. igoose has left

  110. Lance has joined

  111. lovetox has joined

  112. APach has left

  113. APach has joined

  114. Mikaela has left

  115. Andrew Nenakhov has joined

  116. larma has left

  117. Mikaela has joined

  118. igoose has joined

  119. larma has joined

  120. pdurbin has left

  121. adityaborikar has left

  122. adityaborikar has joined

  123. eevvoor has joined

  124. igoose has left

  125. Andrew Nenakhov has left

  126. adityaborikar has left

  127. Andrew Nenakhov has joined

  128. pep.

    To what <message/> should <origin-id/> be added? All?

  129. pep.

    Now that is was ruled out that LMC must refer to the original message, does it make sense to include an origin-id tag in it? As it will most likely not be referenced. (Same applies for other payloads I guess)

  130. adityaborikar has joined

  131. alacer has left

  132. alacer has joined

  133. XSF has left

  134. balu_der_baer has left

  135. edhelas has left

  136. nyco has left

  137. madhur.garg has left

  138. edhelas has joined

  139. nyco has joined

  140. matlag has left

  141. matlag has joined

  142. DebXWoody has left

  143. DebXWoody has joined

  144. eevvoor has left

  145. pdurbin has joined

  146. pdurbin has left

  147. DebXWoody has left

  148. DebXWoody has joined

  149. rion has left

  150. rion has joined

  151. Lance has left

  152. waqas has joined

  153. dele2 has joined

  154. typikol has joined

  155. Lance has joined

  156. dele2 has left

  157. dele2 has joined

  158. DebXWoody has left

  159. DebXWoody has joined

  160. dele2 has left

  161. typikol has left

  162. Lance has left

  163. lovetox

    pep. you need origin-id not for lmc

  164. lovetox

    you need it to deduplicate your own mam messages

  165. lovetox

    hm ah i remember now

  166. pep.

    hmm, because I don't get reflected messages in 1:1, I keep the origin-id and netx time I fetch MAM I can see where I stopped?

  167. pep.

    hmm, because I don't get reflected messages in 1:1, I keep the origin-id and next time I fetch MAM I can see where I stopped?

  168. lovetox

    it was because in the MUC xep was a sentence that MUCs dont have to keep the ids that clients set

  169. lovetox

    so message-id was overwritten by muc service, so you had no chance to deduplicate with it

  170. pep.

    Well in MUC it wouldn't apply right? As there is stanza-ids? Well, when the MUC does MAM

  171. pep.

    Otherwise yeah I can use origin-id

  172. lovetox

    no you are joined in a MUC, you set a message id

  173. lovetox

    you send the message

  174. lovetox

    damn, you are right

  175. lovetox

    i forgot why we added this

  176. lovetox

    maybe i remember later, im sure there was a reason

  177. pep.

    Maybe the XEP could be clarified and add a clear motivation

  178. lovetox

    but yeah that reason is maybe gone, maybe ask Daniel i think he remembers

  179. pep.

    I have an implementation in slix, I'll wait for feedback a bit more I guess

  180. Ge0rG

    Too many ids, too much confusion.

  181. pdurbin has joined

  182. Lance has joined

  183. andy has left

  184. andy has joined

  185. Lance

    origin-id was a way to stamp without leaking your jid

  186. Lance

    since stanza-id requires a by

  187. curen has joined

  188. pdurbin has left

  189. Nekit has left

  190. DebXWoody has left

  191. DebXWoody has joined

  192. waqas has left

  193. waqas has joined

  194. kokonoe has left

  195. kokonoe has joined

  196. adityaborikar

    Is this site down, or is there anywhere else I could read this white paper https://www.isode.com/whitepapers/xmpp-constrained-bandwidth.html

  197. adityaborikar

    The link is on https://xmpp.org/about/myths.html

  198. mathieui

    adityaborikar, https://web.archive.org/web/20160310073118/https://www.isode.com/whitepapers/xmpp-constrained-bandwidth.html

  199. adityaborikar

    Thanks ๐Ÿ˜€

  200. mr.fister has left

  201. winfried has left

  202. winfried has joined

  203. eevvoor has joined

  204. COM8 has joined

  205. COM8 has left

  206. alacer has left

  207. alacer has joined

  208. benne has left

  209. alacer has left

  210. alacer has joined

  211. wurstsalat has left

  212. alacer has left

  213. alacer has joined

  214. alacer has left

  215. alacer has joined

  216. Andrew Nenakhov has left

  217. alacer has left

  218. alacer has joined

  219. wurstsalat has joined

  220. Yagiza has joined

  221. valo has left

  222. valo has joined

  223. ralphm has left

  224. ralphm has joined

  225. adityaborikar has left

  226. ralphm

    I think they replaced it with https://www.isode.com/whitepapers/low-bandwidth-xmpp.html

  227. Zash

    Cool URLs don't change!

  228. adityaborikar has joined

  229. ralphm

    But it would sure be nice if they kept URLs working.

  230. ralphm

    FWIW it seems to be a different article

  231. ralphm

    As in newer.

  232. ralphm

    I'm sure Tobias knows.

  233. moparisthebest has left

  234. moparisthebest has joined

  235. Andrew Nenakhov has joined

  236. Andrew Nenakhov has left

  237. Andrew Nenakhov has joined

  238. frainz has left

  239. frainz has joined

  240. adityaborikar has left

  241. lovetox

    pep. i think i remember again

  242. lovetox

    first everything previous to mam:2 did not inject stanza-id

  243. pep.

    yeah I assumed there was something something mam and stanza-id

  244. lovetox

    second many clients used message-ids which were not uuids

  245. lovetox

    like 1, 2, 3, 4

  246. lovetox

    so yeah if we live now in a world where most clients use uuids as message-ids, and almost every server uses mam:2

  247. lovetox

    i think you dont need origin-id

  248. alacer has left

  249. alacer has joined

  250. andrey.g has left

  251. benne has joined

  252. patrick has left

  253. larma

    message id and origin-id have different uniqueness guarantees. - XEP-0359 origin-id MUST BE globally unique (at least that's the common understanding of XEP-0359), so if everyone plays by the rules it is globally unique, otherwise it's unique per user if at least that user plays by the rules. - RFC 6120 stanza id attribute on messages can be unique within that stream or globally unique (per RFC 6120 ยง 8.1.3). There is no MUST in there, so one may argue that no uniquness guarantee is provided, but explicitly no global uniqueness. Interestingly in XEP-0045 v1.31+, there is a rule that MUCs SHOULD reflect the original message stanza id on reflected messages, which implies that there is not even a by-stream uniqueness guarantee on the message id as other MUC occupants can reuse prior message ids and thus cause a collision of message stanza id on a stream (and still be fully standards compliant).

  254. igoose has joined

  255. moparisthebest has left

  256. moparisthebest has joined

  257. larma

    Technically there is no uniqueness guarantees on <origin-id> whatsoever, only <stanza-id> are unique per generating entity (as specified in their by attribute)

  258. Yagiza has left

  259. Yagiza has joined

  260. Yagiza has left

  261. Yagiza has joined

  262. lovetox

    yes larma, but all you need is unique within an archive

  263. lovetox

    and this is guaranted by mam

  264. Nekit has joined

  265. larma

    for mam that's guaranteed through <stanza-id>, not message id or <origin-id>

  266. larma

    but there are many other use cases that use a message id (or origin/stanza id)

  267. lovetox_ has joined

  268. ralphm has left

  269. igoose has left

  270. lovetox

    yeah but they are not as important as message deduplication

  271. lovetox

    so i always thought if a client does not use unique ids, then this feature will just not work good

  272. larma

    LMC changing the wrong message?

  273. igoose has joined

  274. lovetox

    yes, of course you can implement LMC badly, then this results in very bad stuff

  275. lovetox

    but normally you have a timeframe where correction is allowed

  276. lovetox

    and even if you decide not, then you should always give the user the chance to see all corrections and original messages

  277. lovetox

    so worst is, the user sees weird stuff

  278. lovetox_ has left

  279. lovetox

    but most clients use uuids

  280. lovetox

    and if you implement some timeframe, like message is only allowed to be corrected within 5 minutes

  281. lovetox

    the chance of weird stuff happening is almost zero

  282. lovetox

    even with clients who dont use uuids

  283. larma

    I feel I don't agree with most of what you wrote...

  284. larma

    "user sees weird stuff" is literally the worst thing that can happen, after all MAM is only one utility to help not doing this

  285. ralphm has joined

  286. larma

    "message is only allowed to be corrected within 5 minutes" I'd prefer that LMC was not only for the last message and also allow very old messages (up to days are acceptable for me)

  287. larma

    And even if you allow the user to display corrections, usually users won't do that anyway...

  288. lovetox

    hey i like it to, but this would depend on a uniqunes guarantee that can never exist

  289. lovetox

    you can always only trust the other client

  290. lovetox

    and if you trust message-id

  291. lovetox

    or some other made up element

  292. lovetox

    i mean if you feel better, trust origin-id :)

  293. lovetox

    i think this is the downside of a federated protocol

  294. lovetox

    make up for it by reducing the damage wrong IDs could make

  295. lovetox

    1. timeframe, 2. give user the chance to deactivate lmc for bad contacts

  296. lovetox

    3. give full transparancy, dont hide or replace messages

  297. lovetox

    thats how i deal with this

  298. lovetox

    if you got a better idea, im very interested

  299. frainz has left

  300. larma

    origin-id should be unique at least by origin, easiest way to guarantee is to use a proper UUIDv4. If an attacker uses the same origin-id for multiple messages, the later ones can just be ignored completely, nothing to worry about as it is not possible to happen if it's not an attack and attackers are allowed to suffer from their wrongdoings.

  301. frainz has joined

  302. larma

    But, you can't do the same for message ids as they are not unique by origin, so duplicate message ids are allowed to happen

  303. lovetox

    im not following, so you plan that i can correct ANY message i ever sent you whenever i want

  304. lovetox

    what is there to attack?!

  305. lovetox

    i can already replace any message

  306. lovetox

    and just in case we are not talking about the same thing, IDs should always every matched in the database with a (jid, id) tuple

  307. frainz has left

  308. frainz has joined

  309. lovetox

    there is zero abuse potential other then your contact abuses his own messages he sent you, in that case just stop talking with this dude

  310. Yagiza has left

  311. larma

    Maybe the name "attacker" was misleading here, I meant an entity that does not correctly implement origin-id and generates the same origin-id twice. Those would suffer from degraded usability (easiest is to ignore the messages with duplicated origin-id). However a user sending the same message id twice should not suffer from degraded usability (i.e. the message should be displayed as usual) as this is perfectly standards compliant behavior

  312. lovetox

    are we still talking about LMC?

  313. lovetox

    if someone sends 2 messages with the same id, and afterwards a correction for that id

  314. lovetox

    just take the more recent one

  315. lovetox

    i dont need origin-id for that and i dont need to ignore a message

  316. larma

    There is no reason why message correction should always reference the latest instance of a message id, the user might have intended to do something different. Message correction might be a bad example as those always originate from the sender and usually the same client (though this is not necessarily the case). However if you pick other usages of ids, you'll even get more problems. Like message attaching might attach to the wrong message or something

  317. valo has left

  318. valo has joined

  319. larma

    If you use the message id for message attaching (as suggested as a fallback when there is no origin-id in the XEP) you have the risk of this happening, as a client might not be able to know where to attach that message. So best would be to not allow attaching to messages that don't have an origin-id. But now apparently everyone for some reason tries to not implement origin-id

  320. kokonoe has left

  321. lovetox

    the reason is easy, there are already 2 other ids we manage

  322. kokonoe has joined

  323. lovetox

    so if we need a third one, it should be a damn good reason

  324. larma

    There is your reason ๐Ÿ˜‰

  325. larma

    And: if you don't want to support it on the receving end, at least support it as a sender for those clients that want to use it on the receiving end

  326. larma

    If your message id is already generated using UUIDv4, you'd just have to send the origin-id as well and be done with all the work on the sending side (I assume you already store your message id, so you will be able to handle any usages of the origin-id automatically if it is the same)

  327. lovetox

    the scenarios you think up seem unrealistic

  328. lovetox

    you talk to a contact, that has a client who sends the same message id over and over

  329. lovetox

    but for some reason its still so advanced that it supports message attaching

  330. lovetox

    so the client should now add origin-id instead of just making his message-id a uuid

  331. lovetox

    why cant the XEP not just say, clients who want to support message attaching should generate unique message-id

  332. larma

    The client sending the message and the client being able to display the message attaching must not necessarily be the same

  333. pep.

    lovetox, yeah I guess that would have the same effect? (mandating that clients generate unique @id)

  334. larma

    How do you mandate legacy clients?

  335. larma

    They are already out there, we can't change it afterwards.

  336. pep.

    If they want to implement XEP-foobar, this XEP can say "if you implement me you need to do X"

  337. pep.

    In practice it's a similar solution to origin-id

  338. pep.

    I guess XEP-foobar could say "you need to implement origin-id"

  339. lovetox

    larma, i dont have a problem with legacy clients having degraded experience

  340. pep.

    Same here

  341. lovetox

    but yeah message attaching is a bit unique, i have to look into it more

  342. lovetox

    LMC is really not a problem at all, with clients that use the same ids over and over

  343. lovetox

    i wonder how i would display message attaching on the sender side

  344. lovetox

    would i also only link in my own database to the id

  345. lovetox

    or would i copy the message im attaching and adding it in some other database column

  346. zach has left

  347. zach has joined

  348. lovetox

    i think i would just copy the message into some "attached_data" column

  349. lovetox

    that way i dont even have to care about if the other client uses unique ids

  350. lovetox

    if he uses unique ids he sees the correct stuff, if not, he doesnt implement message attaching anyway and will not see it

  351. larma

    OK, completely realistic scenario: - On my desktop I am using some legacy client that does reuse message ids and does not support message attaching - On my phone I use a modern client that does support message attaching I send a message from my desktop, the recipient attaches a message to my message, I send another message from my desktop that happenns to have the same message id. I open my phone, the message attachment is attached to the wrong message. Even if the XEP of message attaching would require a unique message id, that would not apply to the legacy client, because it doesn't implement the XEP and the recipient does not know if the message id is unique, so can only guess. If the XEP would require origin-id, it would be missing from the legacy client and thus the recipient would be unable to attach to their message

  352. lovetox

    larma i agree origin-id would solve this case

  353. larma

    We could also replace origin-id by an empty <origin-id /> to signal that the message id was unique, but we need this information to be transported in the message.

  354. lovetox

    just upgrading your desktop client would also

  355. lovetox

    hm actually i like that idea, to add an empty element

  356. larma

    The desktop client is allowed to not send a unique id as long as they don't implement a XEP that does require them to. And I am pretty certain there are still a lot of clients that don't do unique ids

  357. larma

    Maybe we want to add this as on option to XEP-0359

  358. larma

    Make 'id' optional on <origin-id> if the id of the surrounding stanza already provides the uniqueness guarantees for <origin-id>

  359. Lance

    empty element would reintroduce the problem the origin-id is there to mitigate: MUCs rewriting the message ids. you'd lose the original id iagain n that case

  360. lovetox

    Lance, but this was fixed in the MUC XEP

  361. larma

    Lance, true for MUCs, but for non-MUCs the 'id' could still be optional

  362. larma

    lovetox, it's an optional feature of MUCs

  363. larma

    to keep the ID when reflecting

  364. Lance

    let me know when the jdev follows the latest MUC XEP

  365. Lance

    let me know when the jdev room follows the latest MUC XEP

  366. Lance

    unfortunately :/

  367. lovetox

    Im not sure what your argument is, we have to stay compatible with old outdated software only because it is compliant with some XEP

  368. larma

    Introducing new requirements in a MUC is not really possible, there will always be legacy servers, only way would be to not connect to those anymore

  369. lovetox

    i couldnt care less about jabber.org

  370. lovetox

    if users tell me Gajim doesnt work with jabber.org, i tell them, go use another server

  371. lovetox

    not rewrite Gajim

  372. larma

    lovetox, > The service SHOULD reflect the message with the same 'id' that was generated by the client, to allow clients to track their outbound messages. If the client did not provide an 'id', the server MAY generate an 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]).

  373. alacer has left

  374. lovetox

    im fine with indicating with origin-id that a client uses a unique id

  375. lovetox

    i think thats a fine use for origin-id

  376. lovetox

    if you want to change your behavior on that, fine, i think would not have the motiviation

  377. lovetox

    and fyi Gajim sets origin-id since forever :)

  378. larma

    I wasn't talking about Gajim, I was talking about you suggesting pep. not to do it

  379. lovetox

    yes, message attaching is to new, i didnt look into it

  380. lovetox

    i stand by my opinion that for all other XEPs, like LMC you dont really need this

  381. lovetox

    and i think, all clients who support mam, support unique ids

  382. lovetox

    and you would never use a client without mam in a multi client setup

  383. larma

    You don't need it for LMC, but need it as soon as it becomes MC without L

  384. lovetox

    so yeah i agree there are edge cases like the one you told, but im not sure we should put to much effort into supporting these

  385. lovetox

    but adding <origin-id/> to indicate unique ids, is not that much effort :)

  386. larma

    I doubt pep. intention was to actually use a different ID for message @id and <origin-id>

  387. lovetox

    what i really would like to prevent is adding another db column "origin-id"

  388. larma

    I understand your point from a dev perspective ๐Ÿ˜‰

  389. lovetox

    omg, jabber.ru does not send the muc subject on join

  390. lovetox

    if no subject is set

  391. lovetox

    do i interpret this correctly

  392. lovetox


  393. lovetox

    that a room subject MUST be sent, even if there is none?

  394. Zash


  395. lovetox

    i guess users will not join mucs without subject anymore with the next Gajim version :D

  396. Zash

    Prosody didn't send empty subjects in some earlier version but it's been fixed for some time. Not sure about other implementations.

  397. madhur.garg has joined

  398. rion has left

  399. rion has joined

  400. eevvoor

    Why does jabber.ru not send it? Is is due to the server they use? I thought it is a client issue, so how does it affect jabber.ru lovetox?

  401. Steve Kille has joined

  402. lovetox

    i think jabber.ru uses some very old ejabberd version

  403. lovetox

    so they dont profit from bugfixes

  404. lovetox

    eevvoor, the MUC xep mandates that a subject has to be sent, and gajim waits for it

  405. lovetox

    and if it never comes, the joining process is never completed

  406. ralphm

    That's silly. I've seen Gajim have more issues like that.

  407. eevvoor

    ah thus not the server sw is the prob but the missing updates :D. Reminds me of the so beloved ccc server. Badly administrated ...

  408. lovetox

    ralphm, whats silly about it?

  409. lovetox

    should we expect servers not following xeps now or what

  410. eevvoor

    yes lovetox you should support backcompatibility forever!!!elven111! XD

  411. ralphm

    lovetox: I agree servers must send it, but waiting on it, even if other stuff for the room comes in, seems silly

  412. lovetox

    so i guess self presence is has 110 status code is also silly?

  413. lovetox

    i mean if there is other stuff coming in, no need for that

  414. lovetox

    subject is the line between history messages, and live messages

  415. lovetox

    its the order of events, it indicates that history messages is complete and the join is full completed

  416. lovetox

    that means i can tell the user, now you can send messages

  417. ralphm

    I understand what it is for

  418. lovetox

    and not in between a history message fetch

  419. eevvoor

    so it carries kin of semantics, lovetox, in your opinion.

  420. eevvoor

    so it carries kind of semantics, lovetox, in your opinion.

  421. ralphm

    What I don't understand is that it stays in limbo forever

  422. eevvoor

    But of course it is nice if the client is robust and works well if the xep is not met, ralphm ?

  423. eevvoor

    So to avoid limbo?

  424. lovetox

    ralphm, of course i could add a timeout

  425. lovetox

    but all clients have to add this workaround

  426. eevvoor

    also not nice, in case it is just delayed ...

  427. lovetox

    or one server can just send a subject

  428. lovetox


  429. eevvoor

    many combinations to be considered ...

  430. ralphm

    lovetox: this is what I mean. A timeout would take care of not keeping the user in limbo in the face of broken servers

  431. eevvoor

    Hm but timeouts can result in strange bugs.

  432. ralphm

    Another example: when Slack still had an XMPP gateway, it didn't respond to the iq for private storage. This would also hang Gajim indefinitely.

  433. ralphm

    I manually patched Gajim to work around this.

  434. eevvoor

    dining philosophers ...

  435. lovetox

    working around servers that dont answer IQs, ok

  436. ralphm

    Why? That's a MUST too

  437. igoose has left

  438. lovetox

    but you still accept it

  439. lovetox

    and worked around it

  440. lovetox

    i mean answering IQs is one of the most basic rules in all of XMPP

  441. lovetox

    if we cant depend on that anymore ..

  442. ralphm

    I am more of the 'expect failure' variety.

  443. lovetox

    its a fine line

  444. ralphm

    And this example was extra tricky, because it is part of the Gajim connect sequence, not a random iq that is sent amongst other things.

  445. igoose has joined

  446. ralphm

    Of course I also reported it as a serious bug with Slack.

  447. ralphm

    And not getting a response for private storage shouldn't block the UI to look like the connection is not ready.

  448. ralphm

    So a timeout would have been a better approach, or async handling.

  449. lovetox

    yes i agree, its not anymore btw, requesting bookmarks is now independent of connection process

  450. lovetox

    only server disco info, roster, and roster delimiter iqs are now in the connection process

  451. ralphm


  452. Mikaela has left

  453. Lance has left

  454. goffi has left

  455. frainz has left

  456. frainz has joined

  457. eevvoor has left

  458. Lance has joined

  459. andy has left

  460. lovetox_ has joined

  461. lovetox_ has left

  462. waqas has left

  463. andy has joined

  464. igoose has left

  465. igoose has joined

  466. lnj has left

  467. lovetox has left

  468. benne has left

  469. benne has joined

  470. andy has left

  471. andy has joined

  472. andy has left

  473. andy has joined

  474. igoose has left

  475. igoose has joined

  476. igoose has left

  477. UsL has left

  478. UsL has joined

  479. Lance has left

  480. igoose has joined