jdev - 2021-04-05


  1. esil has joined
  2. omighty has left
  3. omighty has joined
  4. Ge0rG has left
  5. Kiwi has left
  6. omighty has left
  7. omighty has joined
  8. asterix has left
  9. asterix has joined
  10. omighty has left
  11. omighty has joined
  12. Yagizа has joined
  13. lovetox has left
  14. lovetox has joined
  15. paul has joined
  16. lovetox_ has joined
  17. lovetox_ has left
  18. lovetox_ has joined
  19. lovetox_ has left
  20. DebXWoody has joined
  21. DebXWoody has left
  22. DebXWoody has joined
  23. DebXWoody has left
  24. DebXWoody has joined
  25. omighty has left
  26. DebXWoody has left
  27. DebXWoody has joined
  28. DebXWoody has left
  29. kikuchiyo has left
  30. kikuchiyo has joined
  31. DebXWoody has joined
  32. paul has left
  33. oibalos has joined
  34. paul has joined
  35. DebXWoody has left
  36. DebXWoody has joined
  37. xecks has left
  38. xecks has joined
  39. omighty has joined
  40. Freddy has joined
  41. tiaod has left
  42. tiaod has joined
  43. omighty has left
  44. omighty has joined
  45. wurstsalat has joined
  46. goffi has left
  47. goffi has joined
  48. goffi has left
  49. goffi has joined
  50. FireFly has left
  51. FireFly has joined
  52. pulkomandy has left
  53. pulkomandy has joined
  54. paul has left
  55. paul has joined
  56. flow has joined
  57. debacle has joined
  58. pulkomandy has left
  59. pulkomandy has joined
  60. fade123 has left
  61. fade123 has joined
  62. mikeye has joined
  63. mikeye has left
  64. pulkomandy has left
  65. pulkomandy has joined
  66. FireFly has left
  67. FireFly has joined
  68. kikuchiyo has left
  69. kikuchiyo has joined
  70. pulkomandy has left
  71. pulkomandy has joined
  72. pulkomandy has left
  73. pulkomandy has joined
  74. pulkomandy has left
  75. pulkomandy has joined
  76. Kiwi has joined
  77. pulkomandy has left
  78. mikeye has joined
  79. pulkomandy has joined
  80. lovetox about xep393
  81. lovetox it shows a example, which should not be styled, *not \n strong*
  82. lovetox what rule does this violate
  83. lovetox im not able to find it in the document
  84. Sam Spans cannot cross block level things and linea are blocks
  85. Sam lines, even
  86. lovetox where can i read that in the document?
  87. lovetox i read the text about blocks and spans now 4 times, it does not mention anything about new lines or lines
  88. Sam > Spans are always children of blocks and may not escape from their containing block. It's in the definition of spans. That's not a good place for it though, I should move it inti tge description
  89. lovetox a block is a chunk of text, so including new lines
  90. lovetox and a span can not escape this block does not mean for me it cant have newlines
  91. Sam > Individual lines of text that are not inside of a preformatted text block are considered a "plain" block. Plain blocks are line by line
  92. Sam See also Example 2
  93. Sam The entire concept of a plain block was just to make writing a parser more logical, but it's just confusing. Maybe that was a mistake.
  94. lovetox i dont know im reading such a styling doc the first time, maybe its just me
  95. mikeye has left
  96. lovetox actually i want to write a parser, so im looking exactly for those rules :)
  97. Sam For the first one about spans not crossing blocks you're definitely right, I'll make a PR for that right now. It should be in the section describing spans, not the glossary. That's just confusing.
  98. pulkomandy has left
  99. pulkomandy has joined
  100. lovetox and for writing a parser, it should first identify blocks, and then if the block allows it go line for line inside the block and identify spans
  101. Sam Depends on the block, but in general yes. You can recurse down into blocks, and then do spans.
  102. Sam I sort of handle it differently in my implementation and don't consider "plain" spans or blocks to be a thing at all, but the rules I use come out to be the same I think.
  103. Sam Also pre-formatted blocks are special, those you just consume everything until the end because they can't have children.
  104. FireFly has left
  105. FireFly has joined
  106. pulkomandy has left
  107. pulkomandy has joined
  108. xecks has left
  109. xecks has joined
  110. mikeye has joined
  111. pulkomandy has left
  112. pulkomandy has joined
  113. Sam lovetox: if you want some tests by the way I have a ton I can export as JSON or something.
  114. Sam I keep meaning to figure out somewhere to put them.
  115. lovetox yeah would be great
  116. fade123 has left
  117. flow Sam, how "compatible" would a CommonMark parser be with 393?
  118. Sam flow: not at all.
  119. Sam Like 3 styles would be the same and the others would be different.
  120. Sam And the parsing is different IIRC, so some text would look different even if you only used styles they both share.
  121. marmistrz has joined
  122. fade123 has joined
  123. Sam lovetox: https://github.com/xsf/xeps/pull/1049 in case you want to review and see if that makes things easier to comprehend, sorry about the glossary/business rules mixup. I immediately looked for it in the business rules too.
  124. Sam lovetox: here are some tests. They make take some work to adapt depending on how your parser works, but basically there's a test name, some input, and a list of different styles that should be output: https://gist.github.com/SamWhited/55e35347a7eb6df60c0b1df67db76f05
  125. lovetox ok thanks Sam, text looks good
  126. pulkomandy has left
  127. pulkomandy has joined
  128. mikeye has left
  129. paul has left
  130. paul has joined
  131. xecks has left
  132. pulkomandy has left
  133. pulkomandy has joined
  134. pulkomandy has left
  135. pulkomandy has joined
  136. pulkomandy has left
  137. pulkomandy has joined
  138. FireFly has left
  139. FireFly has joined
  140. pulkomandy has left
  141. pulkomandy has joined
  142. pulkomandy has left
  143. pulkomandy has joined
  144. debacle has left
  145. FireFly has left
  146. FireFly has joined
  147. FireFly has left
  148. FireFly has joined
  149. FireFly has left
  150. FireFly has joined
  151. kikuchiyo has left
  152. omighty has left
  153. kikuchiyo has joined
  154. kikuchiyo has left
  155. kikuchiyo has joined
  156. pasdesushi has joined
  157. xecks has joined
  158. pulkomandy has left
  159. pulkomandy has joined
  160. kikuchiyo has left
  161. pasdesushi has left
  162. xecks has left
  163. xecks has joined
  164. Sam It's that time of the week again! This week for the XMPP Office Hours we have "Cryptographic Identity: Conquering the Fingerprint Chaos" by Paul Schaub (vanitasvitae) on Tuesday, 6 April 16:00 UTC
  165. Freddy has left
  166. Sam See you tomorrow
  167. marmistrz has left
  168. esil has left
  169. kikuchiyo has joined
  170. pulkomandy has left
  171. pulkomandy has joined
  172. kikuchiyo has left
  173. marmistrz has joined
  174. pasdesushi has joined
  175. pasdesushi has left
  176. marmistrz has left
  177. kikuchiyo has joined
  178. Freddy has joined
  179. goffi has left
  180. asterix has left
  181. asterix has joined
  182. debacle has joined
  183. goffi has joined
  184. paul has left
  185. FireFly has left
  186. FireFly has joined
  187. paul has joined
  188. paul has left
  189. paul has joined
  190. mac has joined
  191. paul has left
  192. paul has joined
  193. mac has left
  194. goffi has left
  195. goffi has joined
  196. FireFly has left
  197. FireFly has joined
  198. FireFly has left
  199. FireFly has joined
  200. lovetox Sam, *asd _sad* asd_
  201. lovetox this should only match a bold span
  202. Zash Aahahhahah
  203. lovetox as i understand it spans can have childs, but they cannot overlap in that way
  204. lovetox and because we are parsing lazy left to right, bold gets precedencse
  205. lovetox is that correct ?
  206. FireFly has left
  207. FireFly has joined
  208. FireFly has left
  209. FireFly has joined
  210. Sam Yes, that's correct
  211. Zash Someone™ needs to build an equivalent to https://babelmark.github.io/?text=**foo+*bar**+baz*
  212. Sam Zash: this was kind of a joke, but if you just want to see how something will be formatted it works well enough: https://fosstodon.org/web/statuses/105990119687587415
  213. lovetox Sam, i know you really like 393, but all we do here with impl parsers for that, is to get the information that in 394 is already provided by the sending client
  214. Sam I have an HTML version in the examples in the docs too, though neither is complete.
  215. lovetox meaning start end positions of styling directives.
  216. lovetox so this feels like an extra step
  217. Sam I don't especially like 393, but I think it avoids all the impossible problems of 394 while being "good enough".
  218. FireFly has left
  219. FireFly has joined
  220. Sam I don't like references for various reasons that have already been discussed way too much, or having multiple bodies that in theory say the same thing but maybe don't. I do like Zash's idea of having an alternative body that just has a simple XML language, but as always I don't know how the fallback works except also having a plain body, and that feels bad (in the same way that most HTML/Plain emails end up being borken for me)
  221. Zash Sam, I don't want to see how mellium behaves. I want to have side-by-side comparisons of 𝐞𝐯𝐞𝐫𝐲 implementation!
  222. Sam Zash: oh, gotcha, yah, that would be helpful
  223. Zash And that was probably the 12th time I typed out an xep 457 implementation in a Lua REPL
  224. Sam I do wish we could have come up with something regular. I thought this parser would be simple enough, but I was wrong on that I think. A number of people have told me they have trouble with it.
  225. Zash 71
  226. Zash xep71bis when?
  227. Sam 71 had the opposite problem. It was too easy so everyone just imported a library and called it a day and then acted shocked when the giant security model of the web was broken in the default case.
  228. kikuchiyo has left
  229. Zash The mistake we made was to let the web ruin everything.
  230. kikuchiyo has joined
  231. Zash 71 wasn't broken, the web is
  232. Sam Yes, and 71 uses the web, therefore by the transitive property 71 was broken IMO
  233. Sam I mean, you're right, technically 71 was safe, but we have to think about how people will implement things and it should have been obvious that this would be broken (just like every other thing that uses HTML this way)
  234. Sam Not to mention that 71 let you do stupid things like change font color. If I ever receive another email/IM with yellow text because the senders backgorund is dark and mine isn't it will be too soon.
  235. Zash 393 getting confused with Markdown, a HTML superset, doesn't make me think we fixed anything
  236. Sam As far as I know there was only 1 time that's ever been confused and it got caught and fixed.
  237. Sam So it seems to be doing its job. Someone noticed it just wasn't working and wasn't the same thing, and changed it.
  238. Zash No, *I* noticed and yelled at them.
  239. Sam Exactly, it worked.
  240. Sam (I didn't actually remember that it was you, but thanks for that)
  241. Zash At least I was there to panic about it.
  242. Sam But still, I'm not saying it's perfect, if we can distinguish it more in some way I'm glad to do so. It just doesn't seem to be a widespread problem like it was with literally every web client I tried that implemented XHTML-IM.
  243. Zash I'm still waiting for someone to explain or exploit this in everything else that's using HTML embedded in JSON for formatting. (ie Matrix, MastodonPub, more I forget)
  244. Sam I'm also not against it just being a front end and having a better backend, I just don't think 0394 is it.
  245. mac has joined
  246. Zash *explain how it's not broken in ...
  247. Sam I have found these sorts of things in multiple other non-XMPP products too, FWIW. It is possible to hire a good web dev that knows what they're doing and come out with a roughly safe product too, so I'm sure not everything is. I'm just saying that all the XMPP clients I tried were vulnerable, and that seems like a problem. Pretending its not just seems dangerous.
  248. mac has left
  249. mac has joined
  250. omighty has joined
  251. fade123 has left
  252. fade123 has joined
  253. omighty has left
  254. Alacer_dsrt has joined
  255. Alacer_dsrt has left
  256. alacer has joined
  257. alacer has left
  258. alacer has joined
  259. omighty has joined
  260. mac has left
  261. asterix has left
  262. asterix has joined
  263. alacer has left
  264. pasdesushi has joined
  265. selurvedu has left
  266. pasdesushi has left
  267. asterix has left
  268. asterix has joined
  269. oibalos has left
  270. oibalos has joined
  271. nad200 has joined
  272. Yagizа has left
  273. Kiwi has left
  274. nad200 has left
  275. mac has joined
  276. nad200 has joined
  277. mac has left
  278. nad200 has left
  279. omighty has left
  280. omighty has joined
  281. asterix has left
  282. asterix has joined
  283. mac has joined
  284. mac has left
  285. tiaod has left
  286. lovetox Sam, im not understanding the result of one testcase
  287. lovetox 3 unmatched directives
  288. lovetox ***
  289. lovetox why is that not allowed, its a non-zero-width span
  290. lovetox and has valid start and end
  291. lovetox does this sentence forbid it
  292. lovetox Matches of spans between two styling directives MUST contain some text between the two styling directives, otherwise neither directive is valid
  293. lovetox means if i match ** and see no text i have to ignore both?
  294. Sam Sorry, I tried to clarify this recently but the rules are still confusing, but you've got it right.
  295. Sam We lazily match the first one, then there's nothing between them so neither directive is valid.
  296. Sam That's arguably still wrong, I get confused every time I read the rules too, but I never could find a way to write them that was clear and unambiguous.
  297. Sam That's my own fault for being a bad technical writer.
  298. lovetox but i wonder why this rule exists that way
  299. lovetox this means i can make * bold
  300. lovetox why on finding an empty span, just ignore the end directive
  301. lovetox and search further
  302. lovetox *cant
  303. lovetox *cant make bold
  304. lovetox *cant make * bold
  305. lovetox omg i should go to bad, letters missing, words missing
  306. lovetox i hope you can decipher that
  307. Sam No, there still have to be two styling directives, otherwise there are too many false positives
  308. Sam We don't want someone writing "just multipley x*y and then…" to make the rest of the line bold, for example.
  309. Sam It's not perfect, but it does a pretty good job avoiding them in my experience.
  310. Sam Or doing a correct, some people use * for that.
  311. Sam *multiply, for example, since I Just typoed that :)
  312. lovetox Sam, im not sayin we need only one directive
  313. lovetox im saying ignore the second of the 3
  314. lovetox its still a start and an end
  315. Sam But we lazily match, so we hit the second first
  316. lovetox yeah, then we determine its invalid because zero width span, and ignore it
  317. lovetox the same we hit a invalid end with withspace in front
  318. lovetox we dont dismiss the start
  319. lovetox or do we?
  320. Sam Yes, we do, but in this case it specifically says that if it's empty both are invalid
  321. lovetox oh
  322. lovetox ok then its at least consistent
  323. Sam 0I thought, now I can't find it.
  324. lovetox yeah it says it
  325. Sam oh, first sentence, yah
  326. lovetox thats why i thought this is special
  327. lovetox and normally we dont dismiss both
  328. Sam This is still confusingly worded though, sorry about that. I've tried to clean it up several times and it always still ends up being confusing. I shoud rewrite this whole section as a bulleted list of rules instead.
  329. Sam Sort of. In the other case the thing just isn't a directive at all. In this case it is but it's specifically invalid because there's nothing between them.
  330. lovetox oh wait
  331. lovetox so i was right first but for the wrong reason
  332. Sam Eg. in the message "*not strong *" the second thing just isn't a directive at all because close directives can't have a space.
  333. Sam In "**" they *would* be a directive except for that first rule which says to disregard both of them.
  334. lovetox *strong *strong*
  335. lovetox so here everything should be strong
  336. lovetox because the middle is ignored because not a directive
  337. Sam Yes, I think so.
  338. lovetox hm but its a valid start directive
  339. lovetox just not a valid end directive
  340. Sam Hmm, my library doesn't do that how I would expect, unsure if bug there or in the text. I'll have to look.
  341. lovetox i guess if we declare it useless to nest bold inside bold
  342. lovetox hm wow, i only know if this is start or end until i have the whole string
  343. lovetox ..
  344. Sam Yes, you have to pull the entire styling directive into memory, sadly. If I were designing something from scratch it would be a requirement not to do this, but we'll have max-message limits anyways so in practice it's not an issue.
  345. lovetox so what is it now, this example is inconclusive for me
  346. lovetox there are arguments for both stylings, the second strong can be bold
  347. lovetox but also the whole thing can be bold
  348. lovetox depends on how you interpret that middle *
  349. Sam I'm not actually sure, I'll have to look later. This could be a mistake in the text
  350. lovetox as start directive or end directive
  351. lovetox ok thanks
  352. lovetox ping me once you have an update :)
  353. Sam I'll try to remember
  354. goffi has left
  355. Syndace has left
  356. Syndace has joined
  357. nad200 has joined
  358. nad200 has left
  359. nad200 has joined
  360. Sam Okay, rereading the text I am sure that entire thing would be strong.
  361. Sam Specifically because of " Characters that would be styling directives but do not follow these rules are not considered when matching and thus may be present between two other styling directives."
  362. Sam My implementation treats the middle one as a close styling directive, which is just wrong, so I've got a bug somewhere. I'll add that to the tests.
  363. lovetox ok Sam, but the middle one follows the rules
  364. lovetox whitespace + sd = start directive
  365. Sam Oh right
  366. lovetox its kind of arbitrary that you decide its a close one
  367. Sam I think the intent was you parse a full directive, then parse children, so this would be a start without a closing diretive and therefore invalid. But I'm not sure if this actually says that or not.
  368. Sam Yah, this looks like a bug, we mention how to parse blocks but not how to parse spans. Good find.
  369. Sam I could go either way on this, I guess we'll have to think about whether one way or the other has a benefit and write another update.
  370. lovetox hm i think this is one of the situation where any way is wrong for someone
  371. lovetox we could look to other messengers
  372. lovetox to be consistent with them
  373. Sam Yah, this spec is definitely always going to have problems with some messages, it was designed to be a "good enough" solution by just copying what watsapp and slack were doing (more or less). I'll see what Slack is doing, that's the only other messenger I have
  374. Sam I suspect shorter is better and we should do that instead of the whole thing, but that's just an initial impression.
  375. Sam (Slack just makes the second part strong)
  376. lovetox yeah if i had to decide know i would also lean towards the shorter one
  377. lovetox but i dont have a good reason
  378. Sam Me neither.
  379. Sam I'm curious, let me naively fix the bug in my library where we're not checking for the space before * properly and see what it does afterwards :)
  380. Sam I vote we go with whatever it does so I don't have to change it more :)
  381. asterix has left
  382. asterix has joined
  383. asterix has left
  384. asterix has joined
  385. Sam If I fix my library to include the check for if the previous thing was a space it makes the whole thing strong.
  386. belong has left
  387. Sam I think this actually makes parsing easier (not just because I have to change less stuff), but I'm not sure yet.
  388. omighty has left
  389. lovetox hm yes, its a bit nicer now
  390. lovetox i now have only 2 paths
  391. lovetox is_valid_start_span is_valid_end_span
  392. Sam Actually, no, I say that but I'm sort of wrong.
  393. Sam It's just do you keep a stack of span start tokens and match them to span end tokens, or do you scan for an end token, then do child spans. The first would be more efficient, but I'm not sure that it matters since this is for messages that even in the worst case are going to be relatively short.
  394. lovetox the order is important now, i have to first check if its a valid start, and if yes, then dont check anymore if its also valid end
  395. omighty has joined
  396. lovetox i use a stack
  397. Sam Oh right, I was about to say "wait, I use a stack, how is it getting this result?" but my order is backwards
  398. lovetox yes the order is now important
  399. Kiwi has joined
  400. Sam I do some weird stuff to scan for child spans though, I should rewrite this both ways and just see which one is simpler.
  401. lovetox i have only one scan
  402. lovetox this is if i encounter a pre
  403. lovetox then i scan ahead, so i dont have to parse all kind of childs which i afterwards have to ignore
  404. lovetox my parser can only detect spans right now
  405. lovetox so no blocks yet
  406. belong has joined
  407. oibalos has left
  408. mac has joined
  409. omighty has left
  410. marmistrz has joined
  411. theTedd has joined
  412. theTedd this old thing, again
  413. theTedd "*strong *strong*" would be "{*strong *strong*}"
  414. Sam theTedd: maybe. lovetox has a good point though: is the middle one a valid start styling directive or an invalid end styling directive? I don't think the current rules tell you what to do there.
  415. Sam Ie. do we start parsing outwards and move inwards, or parse in order.
  416. mac has left
  417. theTedd it's a valid start, but it doesn't match because you already have your start, so only a valid close can match the start you already have
  418. theTedd you parse left-to-right; whether you happen to implement that in a nested way is your problem
  419. Sam I think that's only true if we assume that a span can't be nested inside of another identical span. This makes sense, but I don't think the rules say that.
  420. theTedd spans can't be nested - they're spans
  421. Sam They can be nested. The document says so.
  422. theTedd sorry, yes
  423. Sam Eg. _*test*_ is a valid span.
  424. theTedd lazy matching means take the first and find a close, not look for another open so you can throw the first away
  425. Sam If we assume **span** is a nested strong span (not that that makes sense) then we could interpret this as starting from the left and finding a possible opening directive, moving right and finding another opening directive, moving right and finding a close. Which one was closed?
  426. theTedd except ** fails
  427. Sam I *think* I agree. But at best it's confusing in the document and at worst it's ambiguous. Needs some text changed either way.
  428. Sam ** doesn't matter, that's a separate special case.
  429. Sam oh yah, I mean, the **span** example I gave is bad, fair enough.
  430. asterix has left
  431. asterix has joined
  432. Sam I'd be curious how whatsapp handles "*strong *strong*" if anyone has it and can test it.
  433. theTedd right, so this is essentially a "dangling-else" problem, you have to specify one way or the other
  434. Sam I think so, yes
  435. Sam Slack only makes the second one strong, FWIW.
  436. theTedd nearest wins, makes the most sense with being 'lazy'
  437. theTedd so it's {*strong {*strong*} and the first has no matching close, so it's invalid
  438. theTedd I mean to write the ABNF at some point (don't hold your breath too long)
  439. Sam I'm pretty sure ABNF is impossible or at least incredibly long for something like this. It's not really meant for this sort of thing, but that would be awesome if you can do it.
  440. Sam We could add text along the lines of "Once scanning for an end directive any opening directives identical to the previous opening directive are no longer valid" which would result in {*strong *strong*} or we could add something like "Opening directives are scanned from the beginning of the byte stream to the end and can be nested even inside identical opening directives" which would result in "{*strong {*strong*}}". I'm honestly not sure which is better or if it makes a difference.
  441. Sam The first means more scanning. The second means we have to do weird stuff and possibly throw away state after the fact when we decide that the initial strong isn't actually a directive.
  442. kikuchiyo has left
  443. theTedd the second is more consistent with nesting different kinds of directives; you have to be able to throw away the first directive in the case there isn't a matching close anyway
  444. kikuchiyo has joined
  445. moparisthebest I propose language like the following: > Do whatever you want, users really don't care about edge cases here.
  446. lovetox i also think the nesting thing is nicer
  447. lovetox the code must allow parsing nested directives anyway
  448. kikuchiyo has left
  449. lovetox its more work to make an exception for identical directives
  450. lovetox then just treating them like all the others
  451. wurstsalat has left
  452. lovetox than just treating them like all the others
  453. Sam moparisthebest makes a good point. It's not likely to ever matter in practice.
  454. kikuchiyo has joined
  455. theTedd just erase the entire spec and replace it with "do whatever YOLO!"
  456. Sam I think he meant that as long as *this* works it's fine.
  457. Sam I still don't fully get how I'm getting "{*strong {*strong*}}". I need to re-learn how my own parser works I guess.
  458. theTedd for users, that's fine; for implementers, they need to know which way to take it, otherwise the same text looks different on different screens
  459. theTedd it's not a huge issue, but it's easily cleaned up by defining them as nesting and matching with the nearest
  460. lovetox has left
  461. Kev Matching with the *nearest*?
  462. theTedd in terms of a dangling-else
  463. Kev So *this*, *message* has just a comma bold in it?
  464. theTedd I meant in this specific case, not as a complete set of rules
  465. Kev I’ll read the summary on standards@ in the morning ;) GN.
  466. theTedd night
  467. theTedd Sam, you may be matching the final * twice as a result of taking substrings
  468. Sam I hope not, but it's quite possible I have an off-by-one somewhere and am still matching it.
  469. nad200 has left
  470. nad200 has joined
  471. Sam *whew* my implementation does handle Kev's example correctly at least (or what I think is correctly where the ", " is plain and everything else is strong)
  472. Sam But that one doesn't show this problem, so I guess I shouldn't have been scared that it wouldn't work
  473. kikuchiyo has left
  474. lovetox has joined
  475. nad200 has left
  476. kikuchiyo has joined
  477. marmistrz has left
  478. kikuchiyo has left
  479. kikuchiyo has joined
  480. kikuchiyo has left
  481. tiaod has joined
  482. kikuchiyo has joined
  483. theTedd has left
  484. kikuchiyo has left
  485. selurvedu has joined
  486. moparisthebest > otherwise the same text looks different on different screens Yes, and users don't care
  487. belong has left
  488. kikuchiyo has joined
  489. debacle has left
  490. mac has joined
  491. kikuchiyo has left
  492. larma has left
  493. larma has joined
  494. kikuchiyo has joined
  495. nad200 has joined
  496. nad200 has left
  497. mac has left
  498. mac has joined