XSF logo XSF Discussion - 2017-03-16

  1. vurpo has left
  2. vurpo has joined
  3. vurpo has left
  4. vurpo has joined
  5. Zash has left
  6. Mancho has left
  7. ThurahT has joined
  8. moparisthebest has joined
  9. efrit has joined
  10. vurpo has left
  11. vurpo has joined
  12. vurpo has left
  13. vurpo has joined
  14. vurpo has left
  15. vurpo has joined
  16. vurpo has left
  17. vurpo has joined
  18. intosi has left
  19. vurpo has left
  20. vurpo has joined
  21. vurpo has left
  22. vurpo has joined
  23. ralphm has left
  24. jere has joined
  25. mimi89999 has left
  26. suzyo has left
  27. Tobias has joined
  28. kaboom has left
  29. uc has left
  30. kalkin has left
  31. nyco has joined
  32. kaboom has joined
  33. sezuan has left
  34. Tobias has joined
  35. uc has joined
  36. ralphm has left
  37. uc has left
  38. uc has joined
  39. waqas has left
  40. ralphm has left
  41. ralphm has left
  42. nicolas.verite has joined
  43. Tobias has joined
  44. Ge0rG has left
  45. Ge0rG has left
  46. sezuan has joined
  47. Mancho has joined
  48. Ge0rG has left
  49. smitb has joined
  50. smitb has left
  51. jere has joined
  52. nicolas.verite has left
  53. sezuan has left
  54. Arc has left
  55. moparisthebest has joined
  56. Ge0rG Am I the only one to be baffled by the Yes-Yes-Yes-No-Yes order of questions in the Last Call emails, every single time?
  57. arc has left
  58. Guus has left
  59. Guus has joined
  60. Valerian has joined
  61. vurpo has left
  62. vurpo has joined
  63. ralphm has left
  64. nicolas.verite has joined
  65. Tobias has joined
  66. Guus has left
  67. nicolas.verite has left
  68. Guus has joined
  69. Tobias yes you are
  70. Ge0rG Tobias: how can you know? :D
  71. efrit has joined
  72. nyco has joined
  73. Tobias aww...multi-client support in major IM apps, "WhatsApp is open on another computer or browser. Click “Use Here” to use WhatsApp in this window."
  74. nicolas.verite has joined
  75. Ge0rG Tobias: And you have also stored XSS vulnerabilities in WhatsAppWeb
  76. Ge0rG Tobias: And you have also stored-XSS vulnerabilities in WhatsAppWeb
  77. Tobias what web app doesn'T have XSS vulnerabilities, that's their feature, isn't it?
  78. vurpo has left
  79. Guus has left
  80. Guus has joined
  81. Ge0rG Last time I audited a web app, I was able to type HTML/JavaScript right into the "Send message to admin" input box. Instant root!
  82. vurpo has joined
  83. moparisthebest has left
  84. moparisthebest has joined
  85. Guus has left
  86. Guus has joined
  87. intosi has joined
  88. efrit has joined
  89. efrit has joined
  90. rion has joined
  91. rion has left
  92. ralphm has left
  93. suzyo has joined
  94. nyco has joined
  95. Tobias jonasw, am I missing something or does xmpp.org already show the data based on your JSON system?
  96. jonasw no, I think it does
  97. Valerian has left
  98. jonasw https://github.com/xsf/xmpp.org/pull/278 cc @ Ge0rG (who wants to write the announcement mail for software developers) A bit of manual cannot hurt for the renewal thing.
  99. Tobias jonasw, nice..and expiration also works as soon as last_renewed is set
  100. jonasw there is also that deadline hardcoded in pelicanconf.py, we should adapt this once the mail is sent out
  101. jonasw after that deadline anything without renewal disappears magically
  102. jonasw https://github.com/xsf/xmpp.org/blob/master/pelicanconf.py#L58
  103. Tobias so yeah...an annoucement mail would be nice to tell people to create PRs that set the last_renewed value for their project to a value in the past and that after a months or so, all entries without a last_renewed set will be removed
  104. jonasw we can set this to date_of_mail + 1 month when the mail is sent out.
  105. jonasw no need to modify the last renewal of projects for us.
  106. jonasw ah, nevermind, I misunderstood you. disregard the last one, it was unrelated.
  107. nicolas.verite has left
  108. jonasw (true, but unrelated)
  109. arc has joined
  110. Tobias jonasw, could the config also be relative? like today - 13 months or so
  111. jonasw not sure what you mean
  112. Ge0rG https://op-co.de/tmp/deprecation-mail.txt draft email with PR link
  113. jonasw there are two reasons to kick an entry from the list in the code (aside from date parsing issues): 1. if they have no renewal timestamp set, they are kicked after the date in STRICT_RENEWAL_DEADLINE has passed 2. if they *have* a renewal timestamp set, they are kicked if it is more than ENTRY_LIFETIME in the past (currently set to 365 days)
  114. Tobias jonasw, ahh..so it does more than I thought :) good
  115. Ge0rG jonasw: ENTRY_LIFETIME should be ~13 months to provide for a grace period
  116. jonasw it does everything that was asked I think :-)
  117. jonasw Ge0rG: fine with me. make a PR ;-)
  118. Tobias right...I thought we'd just delete projects with no date set after the deadline, but your STRICT_RENEWAL_DEADLINE config already does this :)
  119. Tobias has joined
  120. Tobias does this = has the same effect
  121. Ge0rG jonasw: -ETOOMANYPENDINGPRS
  122. jonasw Ge0rG: your email footnotes have two times [2] in them
  123. Ge0rG jonasw: damn off-by-ones. Fixed.
  124. jonasw Ge0rG: it might be better to link to the commit rather than to the PR
  125. jonasw the PR does a lot of unrelated stuff
  126. jonasw it might be even better to link to the README
  127. jonasw (and we can update the readme with a link to the example commit once the branch is merged)
  128. Ge0rG jonasw: but I did link to the commit. It was just relative to the PR and not in the xsf repo.
  129. jonasw argh
  130. jonasw I cannot read urls
  131. jonasw sorry
  132. Tobias jonasw, right...maybe we should add a section to https://xmpp.org/software/ how authors can add new software and update the date
  133. Ge0rG jonasw: URLTLDR
  134. jonasw Tobias: might be wise, yes
  135. Ge0rG Tobias: maybe we should add it to some README and link it from https://xmpp.org/software/
  136. Tobias why not have the readme at https://xmpp.org/software/ ?
  137. jonasw https://github.com/xsf/xmpp.org/pull/278/commits/73cd247e4af6624e60ac29bf33c3f4bf46677786#diff-ac579daf3602a0a4ea57b5fdd7f73dd8 like this readme?
  138. jonasw Tobias: because it’s long and technical. If we want normal users to use the software directory there, we shouldn’t have that information on it
  139. Tobias yeah..that what you linked to looks qutie long..linking to it sounds sensible
  140. jonasw I thought I’d rather make it too detailed than too shallow.
  141. Ge0rG Yay. I've been reading 0369 for the last two hours, and I only managed to get to 6.1.6
  142. jonasw Ge0rG: you are in luck! it appears that prefer hidden is going to be broken out of that XEP. so less to read next time ;-)
  143. jonasw (which I think is a good idea, I also thought that might make sense to break out into an add-on)
  144. Ge0rG jonasw: yeah, I actually had three remarked about prefer-hidden that I already deleted.
  145. jonasw :)
  146. Tobias Ge0rG, you should order the audiobook version read by helen mirren
  147. jonasw thanks for going through it :)
  148. jonasw there is one? :-O Tobias
  149. Tobias there should be one
  150. Ge0rG Tobias: but I want the one read by Morgan Freeman('s German lipsync voice).
  151. Tobias https://youtu.be/zmeF2rzsZSU?t=2m19s :)
  152. Tobias Ge0rG, you mean Nelson Mandela?
  153. Guus has left
  154. vurpo has left
  155. vurpo has joined
  156. Guus has joined
  157. Valerian has joined
  158. Tobias jonasw, but yeah..nice work you did there...thanks :)
  159. jonasw no problem :-)
  160. jonasw you’re welcome
  161. jonasw (I need to get used to using "you’re welcome" in en locales)
  162. Tobias de nada
  163. vurpo has left
  164. vurpo has joined
  165. nicolas.verite has joined
  166. nicolas.verite has left
  167. Guus has left
  168. Guus has joined
  169. vurpo has left
  170. vurpo has joined
  171. nyco has joined
  172. Zash has joined
  173. pep. has joined
  174. Yagiza has joined
  175. jubalh has joined
  176. Ge0rG resolved my XMPP action items for today.
  177. Ge0rG When is the next council meeting due?
  178. Tobias Ge0rG, they usually happen on a weekly basis
  179. goffi has joined
  180. Ge0rG So "yesterday"
  181. nyco has joined
  182. Tobias Ge0rG, which reminds me to write up minutes for yesterdays meeting...nothing is more exciting than yesterday news
  183. Ge0rG Tobias: was there an exciting discussion of #436?
  184. Bunneh Tobias: XEP-0045: Add <x/> tag to MUC-PMs #436 https://github.com/xsf/xeps/pull/436
  185. Tobias i don't remember discussions about that
  186. Ge0rG has joined
  187. Ge0rG It looks like my train is arriving. I'm looking forward to read minutes.
  188. Tobias http://logs.xmpp.org/council/2017-03-15/
  189. Tobias shoo shooo
  190. vurpo has left
  191. vurpo has joined
  192. jonasw huh
  193. jonasw is there any update on my protoxep?
  194. jonasw (I’m not familiar with the process, so please don’t mind me asking.)
  195. jonasw ah
  196. jonasw I am too stupid to search
  197. Tobias jonasw, it's awaiting votes...council members have two weeks to vote
  198. sonny has joined
  199. jonasw ah, I see
  200. jonasw didn’t know that "two weeks" detail
  201. Holger Ge0rG: It was mentioned last week http://logs.xmpp.org/council/2017-03-08/#16:32:52 (and then on the list) but maybe you mean a follow-up discussion?
  202. Ge0rG Holger: yes. I've done what was asked from me and hoped it would get discussed again
  203. Holger Ah ok.
  204. Ge0rG Looks like adding things to the PR wasn't enough. Need to bother someone to add it to trello.
  205. sonny has joined
  206. Tobias Ge0rG, yup..what's not in trello isn't discussed :)
  207. jonasw mail to council@?
  208. Ge0rG Tobias: can you add it please?
  209. Tobias sure
  210. Tobias Ge0rG, seems there are pending votes on https://trello.com/c/wF37u9DJ/169-vote-on-approve-xep-0045-changes-proposed-by-georg
  211. Tobias one of which is mine...will review that now then :)
  212. Ge0rG Tobias: it might need a revote (is that a thing), because I changed the PR based on council feedback
  213. sonny has joined
  214. Tobias Ge0rG, i'll put it on the agenda to discuss this next meeting
  215. Steve Kille has left
  216. Steve Kille has left
  217. Ge0rG Tobias: thanks very much! Is there anything I can do to accelerate the process, so that there is no more 1-week latency in the feedback loop?
  218. Ge0rG Or even 2-week in this case
  219. Steve Kille has joined
  220. Tobias Ge0rG, get dwd to vote on it
  221. jonasw Ge0rG: have you sent the deprecation announce already?
  222. Ge0rG jonasw: to board? Yes.
  223. jonasw with the link to the commit?
  224. Ge0rG jonasw: yes
  225. jonasw hm, then I’ll make sure that the commit ID doesn’t change :)
  226. Tobias seems i already voted on Ge0rG's PR, just forgot to mark it in Trello...now reviewing caps2
  227. jere has joined
  228. jonasw has left
  229. Ge0rG jonasw: it has a todo note
  230. sonny has joined
  231. mhterres has joined
  232. suzyo has left
  233. suzyo has joined
  234. nicolas.verite has joined
  235. nicolas.verite has left
  236. jonasw Ge0rG: what has?
  237. Martin has joined
  238. Ge0rG jonasw: the URL
  239. jonasw ah okay
  240. nicolas.verite has joined
  241. Holger Tobias, dwd: > <Tobias> Dave Cridland, well..p1 implemented it [MIX] too, not? > <Dave Cridland> Tobias, They implementing grouchat over pubsub; not quite the same thing. They implemented both.
  242. Holger (Well, an early revision of MIX.)
  243. nicolas.verite has left
  244. dwd Holger, That's actually the one I was referring to. The thing they said was early MIX was a brief discussion; it didn't, for example, handle <presence/> or <message/> stanzas in the traditional way, a design feature that lasted all of a week or so and was contentious at the time.
  245. vurpo has left
  246. nyconyco has joined
  247. Holger Yeah whatever, just wanted to clarify that there's two totally unrelated pieces of code, so you were both right :-)
  248. vurpo has joined
  249. nicolas.verite has joined
  250. nicolas.verite has left
  251. Holger Oh.
  252. nicolas.verite has joined
  253. nicolas.verite has left
  254. Holger Sorry you were referring to mod_mix, finally got that now.
  255. Holger While at it, personally I think if there's any chance to move non-essential functionality out of the core MIX spec into separate XEPs, that should be strongly considered.
  256. dwd Holger, I agree. I'm not sure what remains to be removed.
  257. nyconyco has left
  258. Holger I can totally see use cases for anonymous chat, but they don't seem to be the common me, so it would be nice if implenting that would be optional (esp. on the client side_.
  259. Holger *implementing
  260. Tobias Holger, indeed...it's quite an amount to review
  261. MattJ To be honest I'm not sure that MIX should even attempt to compete with use-cases that MUC already covers
  262. MattJ but maybe it's too early in the morning to be so controversial
  263. jonasw which use-cases does MUC actually cover?
  264. dwd Holger, Anonymity seems very fundamental to operations, though.
  265. dwd Holger, And crucial where it arises.
  266. dwd jonasw, Being shit on mobile?
  267. dwd No, seriously, MUC covers >90% of what anyone needs for pure synchronous ephemeral chat. I don't think it's hard to make MIX cover that, too, but I think MIX can and should spread its wings wider, at least in potential.
  268. MattJ dwd, because?
  269. MattJ (to your comment about mobile)
  270. Steve Kille dwd: +1
  271. dwd MattJ, The tie between your session and your participation, WRT mobile. It can be worked around to some degree, though, but it's a bit of a pain.
  272. MattJ Right
  273. MattJ Maybe it is a bit of a pain, but here comes a whole new spec that isn't exactly trivial either
  274. dwd MattJ, I suspect that most servers will find it *easier* to implement than we have done do far in Openfire.
  275. dwd MattJ, Due to the architecture, we couldn't reuse any of the MAM code, nor PubSub code, nor even the MUC code.
  276. dwd Not that any of that code is bad, it's just either in the wrong place, or highly focussed to what it does.
  277. Tobias like the s2s code? :)
  278. dwd Tobias, The S2S code is just very old, basically. We've updated it a considerable amount over the past few years, including fixing a bunch of security issues.
  279. Mancho has left
  280. Tobias still can't recursively disco igniterealtime.org
  281. dwd Tobias, The MUC code, and the pubsub code, both have near-complete, all-options, implementations of '45 and '60 respectively, with full clustering.
  282. Mancho has left
  283. dwd Tobias, Sure - I've not fixed the issue you found yet. It's a hang-up of Openfire originally assuming that x.domain.example could always be reached at domain.example; that assumption has entered code in a large number of cases.
  284. Guus no-one is arguing that that s2s bug should be fixed, Tobias. Daytime jobs and all.. :)
  285. Tobias Guus, dwd, yeah i know..just nitpicking :)
  286. Guus interop problems are annoying
  287. Guus you should simply switch to Openfire and be done. :)
  288. Guus ducks, runs
  289. Tobias Guus, and you are 100% sure that openfire would not have that issue :P
  290. Guus (I'm somewhat in a defiant optimistic mood now that it turns out i'm not living in the newest populist-governed country)
  291. dwd Tobias, Actually yes, because the assumption operates bidirectionally.
  292. dwd Guus, As you should be.
  293. Tobias dwd, i wonder if there could be a security issue there
  294. dwd Tobias, Actually, I suspect this case is due to authenticating domains individually rather than authorizing as domain-pairs. So no security issue.
  295. Tobias dwd, didn't you propose some standard for that once? bidi or dwd?
  296. Guus Tobias: yes.
  297. Guus also, what he said
  298. Guus (eww, lag)
  299. dwd Tobias, No. Those still operate on pairs.
  300. Tobias but it was a practice gtalk was doing right? reusing a s2s connection for all their domains?
  301. dwd Tobias, That's different... Piggybacking is fine. But you still have to authorize pair-wise.
  302. Tobias ok
  303. Valerian has left
  304. nyco hey, are you aware? https://www.erlang-solutions.com/blog/21-xmpp-use-cases-and-the-best-ways-to-achieve-them.html sorry, looks like a shameful ad...
  305. Flow has joined
  306. nyco it is interesting, as we discussed that many many times
  307. nyco how to read the massive amounts of XEPs
  308. nyco how to triage the massive amounts of infos that are behind each XEP
  309. arc has left
  310. arc has joined
  311. nyco do it give ideas on how to present our XEP list or feature list?
  312. sonny has left
  313. Mancho has left
  314. Ge0rG Wow, a burst of discussion. I think that the fact it takes multiple hours to read and understand MIX might indeed mean we won't see IM MIXes any time soon.
  315. Ge0rG While MUC is really broken in some regards, it can be fixed with a bunch of undocumented hacks.
  316. jubalh has joined
  317. kalkin has joined
  318. jonasw has left
  319. Valerian has joined
  320. kalkin has left
  321. Tobias it's all a matter of having the right abstraction in your software...and if you then already have pubsub and MAM in place, i don't think MIX is that mich work, at least a minimal version
  322. Ge0rG Tobias: I've tried to read the XEP (admittedly I also did some light editing along the way), and I managed to read ~40% in 2 hours.
  323. Ge0rG Tobias: if you have the right abstractions in your software, it still takes multiple hours to understand how to stack them
  324. Tobias sure
  325. Ge0rG I'm not sure if it would help to refactor the XEP into "Client Developers Read This", and the same for Server Devs and Service Devs.
  326. Tobias mostly it covers so many things...i mean user experiences like whatsapp group chats, doesn't require 4 different affilations/roles, etc.
  327. daniel has left
  328. Ge0rG Tobias: yes, it attempts to be everything to everyone.
  329. daniel has joined
  330. Ge0rG If history is repeating itself, we'll have a MIX-Light in five years that is a one-man-show slim rework of MIX, similar to what MAM is to Message Archiving, PEP is to PubSub and Blocking Command is to Privacy Lists.
  331. Ge0rG ...and http-upload is to Jingle FT
  332. Ge0rG Tobias: btw, you intended to update https://wiki.xmpp.org/web/XEP_and_RFC_Remarks/RFC_6121:_XMPP-IM with that one corner case you were talking about yesterday
  333. Tobias somewhere I have a tab open about that, yes
  334. Tobias opens a new tab for it :)
  335. Flow has left
  336. Guus that makes three rows of tabs, right?
  337. Tobias chrome can't do mulit rows
  338. Tobias but there's a nice plugin that removes duplicate tabs :)
  339. Valerian has left
  340. Valerian has joined
  341. vurpo has left
  342. vurpo has joined
  343. kalkin has joined
  344. sonny has joined
  345. Arc has joined
  346. Arc Amazon Smile is donating 10% of purchases to your chosen charity today
  347. Arc so if you've selected XMPP as your charity on smile.amazon.com be sure to make purchases ;-)
  348. mathieui if you’re in the US
  349. Ge0rG Arc: XMPP is a charity?
  350. Tobias Ge0rG, sure...feeding the hungry in africa
  351. kaboom has joined
  352. sonny has left
  353. sonny has joined
  354. Ge0rG Xenophobics' Money for Poor People?
  355. Ge0rG I'm sure it's a SCAM.
  356. Tobias Ge0rG, they probably delegated the chairity part to paypal..they are experts at this
  357. intosi Super Cool Automatic Messenger?
  358. jubalh has left
  359. Vinilox has left
  360. nicolas.verite has joined
  361. nicolas.verite has left
  362. dwd I should put MIX onto dave.cridland.net, shouldn't I? Are any [other] client developers wanting to play?
  363. jonasw dwd: yes
  364. jonasw not this month, but yes
  365. dwd jonasw, What library?
  366. jonasw aioxmpp
  367. Valerian has left
  368. dwd jonasw, Ah, heh. We nearly put MIX support into that, before deciding to base our test suite around Java instead.
  369. jonasw aw pity
  370. dwd jonasw, We have partial implementation, so far, only in stanza.io. I'm awaiting confirmation that'll all be offered upstream (I can't imagine why not).
  371. nicolas.verite has joined
  372. nicolas.verite has left
  373. nicolas.verite has joined
  374. nicolas.verite has left
  375. arc has left
  376. arc has joined
  377. Tobias has joined
  378. nyco has joined
  379. Mancho has joined
  380. Valerian has joined
  381. Valerian has left
  382. nyco has joined
  383. jere has joined
  384. nicolas.verite has joined
  385. Ge0rG dwd: any chance you can have a look at https://trello.com/c/wF37u9DJ/169-vote-on-approve-xep-0045-changes-proposed-by-georg and maybe provide feedback if action is required from my side, regarding repairing the MUC protocol?
  386. Tobias Ge0rG, btw: just added the text to the wiki page
  387. Ge0rG Tobias: thanks. Any ideas on how to fix that? Let server push a presence change to the other clients?
  388. Tobias with full to and from attributes, yeah
  389. dwd Ge0rG, FWIW, I'm a little uncomfortable with "SHOULD" here, given you're adding a normative requirement post-facto. But I suppose this is probably as good as it gets, so I'm not going to block.
  390. Yagiza has joined
  391. Ge0rG Tobias: I also noticed some multi client weirdness when *accepting* a subscription request, have you looked into that as well?
  392. Tobias Ge0rG, with accepting clients should receive a roster push, not?
  393. Tobias Ge0rG, also...i thought you were planning to replace the SHOULD with a MAY?
  394. Tobias "TLDR either change the wording to MAY or add a sentence that implementations MUST NOT rely on it." <--- regarding that
  395. Ge0rG dwd: thanks for the feedback. I think that we should be able to change our specifications over time, or we will end up with multiple generations of imperfect XEPs attempting to solve the same problem, evolving over the years
  396. kaboom has left
  397. Ge0rG Tobias: I added the sentence
  398. dwd Ge0rG, I don't disagree. I don't think that ought to involve simply declaring everything non-conformant. I don't see much of an option in this case, but that doesn't mean I'm happy with it.
  399. Ge0rG dwd: IMHO, this approach has two benefits. First, it provides a clear path for new implementors to do the right thing. Second, it provides a bit of leverage to get existing implementations fixed.
  400. dwd Ge0rG, But they weren't broken...
  401. dwd Ge0rG, Not from a standards point of view.
  402. dwd Ge0rG, The actual protocol seems fine. My concern is with establishing the case that conformance isn't acheivable, or important.
  403. Ge0rG dwd: they were compliant to an imperfect specification. One *could* consider this as broken
  404. dwd Ge0rG, Nothing is perfect. What we want is interoperable.
  405. dwd Ge0rG, And if things aren't interoperable, I'd rather they weren't despite following the specification rather than because they didn't.
  406. dwd Ge0rG, To put it another way, the pattern of declaring existing conformant implementations non-conformant isn't a pattern I'd like to see continue.
  407. Ge0rG dwd: the two largest server implementations already exhibit the new behavior.
  408. dwd Ge0rG, That's irrelevant.
  409. dwd Ge0rG, I'm not saying the protocol change is bad - I've explicitly said it seems the right solution.
  410. dwd Ge0rG, I'm saying the choice of how the change has been made is not something I want to see ever again.
  411. jere has joined
  412. vurpo has left
  413. vurpo has joined
  414. Valerian has joined
  415. intosi has left
  416. nicolas.verite has left
  417. Ge0rG dwd: I don't see a better way to change MUC, except for a hard fork. And I think we all agree that that would not really be better.
  418. waqas has joined
  419. Ge0rG TBH, I'd like to also add more explicit words to 0045 regarding repeated join presences from the same full JID, and also do another take on the message ID stability for reflected messages.
  420. dwd Ge0rG, I agree this is the best of a bad bunch. I'm just saying that introducing new normative requirements to an existing specification is a problem.
  421. dwd Ge0rG, For repeated joins: I think there's consensus on the approach now, but it's not clear that we could put this in as anything more than an implementation note nonetheless. But Openfire, M-Link, and possibly others do it the "right" way.
  422. dwd Ge0rG, For message id stability, there's really no chance. I've changed my mind on that one over the years, but there's no universally-agreed "right" way. It is, however, "fixed" in MIX.
  423. dwd Ge0rG, Mind you, a note saying that implementations differ on message id stability would be good if you want to pen one.
  424. Ge0rG dwd: my reading of rfc 2119 is more flexible, and I tend to accept "this was not part of the XEP when I implemented it" as a valid exception to a SHOULD.
  425. dwd Ge0rG, But that would suggest nobody would ever need to implement it... Which I don't think you really mean.
  426. jonasw dwd: to be frank, as a relative newcomer to XMPP, this kind of stance is annoying. If there is a consensus on how something should be done, that should be written in the XEPs. Yes, during the transition period, some implementations won’t get it right. If that’s any better, we can make it a MAY first and after a year or so make it a SHOULD. But if you only make it an implementation note, I as a developer *cannot* at all rely on that behaviour, and it doesn’t look as if I ever can, so it is often useless to me.
  427. Ge0rG dwd: MAY is completely optional. SHOULD at least provides direction in how to do it best
  428. MattJ As far as I'm aware there was only ever one implementation that rewrote ids on messages, and it tripped up everyone when it appeared
  429. dwd jonasw, I get that. The protocol can and should change. And if the specification says "SHOULD", you really should be able to rely on it. If we abuse that by introducing *new* normative languages into *existing* protocol, you can't.
  430. jonasw dwd, Ge0rG: at the same time, when such changes are made, it is important to keep a hint on that this was changed "recently" inside the text. The list of versions below is not really discoverable, and finding important changes among the long list of changes is often hard (if the list of changes is even complete). Otherwise, one might be confused by implementation which do not handle this correctly; although that can be mitigated by making that (nothing) -> MAY -> SHOULD transition.
  431. jonasw dwd: what about that MAY -> SHOULD transition?
  432. sonny has left
  433. jonasw new implementations will see where the journey is going and there is something to point existing implementations to to achieve change
  434. jonasw MattJ: I think daniel mentioned some gateways (Slack?) which did that, too
  435. nicolas.verite has joined
  436. nicolas.verite has left
  437. dwd jonasw, I don't think introducing new normative requirements to existing protocol is *ever* the ideal path. I think we want to add new *protocol*, and then add this to the requirements for a given compliance level.
  438. Kev jonasw: Spec versions (by protocol) should be interoperable.
  439. Kev If I see feature X offered, I should know that I will interoperate with it if I implement the spec.
  440. Kev Not that I might or might not interoperate with it based on the age of the implementation.
  441. jonasw okay, can we add a <feature/> then?
  442. dwd Or that I might not interoperate with it next week.
  443. jonasw that would work for "I am not rewriting message IDs" for example
  444. Kev Where we want to break things such that that isn't true, we do it by changing the negotiated feature (by our faux-versioning scheme).
  445. dwd jonasw, Sure, and we can certainly do that.
  446. Kev The issue here is that we're trying to avoid bumping the namespace version in MUC for obvious reasons.
  447. dwd Kev, We can also add new features.
  448. Kev dwd: Different issue if you're adding a new feature, in a sense :)
  449. Kev But yes.
  450. dwd Kev, MAM's recent :1 -> :2 transition could have done that, and it's somewhat frustrating that it hasn't.
  451. dwd Kev, But behavioural differences can be expressed as a new feature almost always.
  452. Kev dwd: If thre's a better way, you could suggest rolling back to :1 with additional features.
  453. devnull has left
  454. Kev Given I doubt anyone implements :2 (and if it's true that it just needs new features, that might be smart).
  455. MattJ Prosody implements :2
  456. Ge0rG Maybe we should entirely abandon the version bumping thing for new features and only use it for breaking changes.
  457. MattJ and iirc Conversations (but not 100% sure)
  458. Kev Oh. 0.10 or something?
  459. Kev Or are we on 0.11 now?
  460. MattJ 0.10
  461. jonasw Ge0rG: +1
  462. nicolas.verite has joined
  463. dwd MattJ, The MAM protocol itself is entirely unchanged on the wire. When used with MIX, nothing changes at all. Aside from everything, due to bumping the namespace/
  464. nicolas.verite has left
  465. dwd Ge0rG, Well, of course. That was *always* the intent.
  466. dwd Ge0rG, See XEP-0053, §4, point 2.
  467. Kev Yes, new features that don't break the existing stuff should be by additional feature negotiation, not by bumping the namespace.
  468. Ge0rG dwd: so it would be perfectly OK with you if I added the stable ID thing into MUC with an additional feature?
  469. dwd Ge0rG, You can't. :-) Otherwise I would have suggested it.
  470. Ge0rG dwd: what's wrong with it?
  471. dwd Ge0rG, But you've done this by - quite rightly - allowing either clients or servers to add the PM marker.
  472. dwd Ge0rG, You could have a feature that indicated the server would do this for you. Perhaps you should.
  473. Ge0rG dwd: I'm not talking about <x>, I'm talking about keeping the message ID on reflection
  474. Kev The thing you can't do is say that servers SHOULD or MUST implement such a new feature. The point of upgrades-through-features is that they might not happen :)
  475. dwd Ge0rG, Oh that. Yes, sure.
  476. Kev No reason a server can't advertise a feature saying "I'll keep ids stable".
  477. arc has left
  478. arc has joined
  479. Ge0rG dwd: though I could imagine adding a <feature> for <x> as well, I'm just not sure what that would give in that specific case.
  480. Kev What you can't then do is say servers SHOULD or MUST implement this.
  481. vurpo has left
  482. vurpo has joined
  483. Ge0rG Kev: as I wrote earlier, I consider "SHOULD" to be the appropriate wording for such things, because it indicates the purpose and intent of our Great Master Plan. Foregoing that for the sake of backwards compatibility to the year 2002 is just not right
  484. Ge0rG Kev: It's the right thing to RECOMMEND server implementations to do these awesome new things nobody thought of in 2002, and to have a <feature> advertising that.
  485. Ge0rG Kev: actually, those two are almost completely orthogonal aspects of a protocol change.
  486. Ge0rG (at least in my eyes)
  487. Kev I know you consider that. I just don't think that's the appropriate reading of SHOULD.
  488. dwd Ge0rG, And I strongly believe you to be wrong. Not because recommending people implement something new is wrong, but because RECOMMENDing people do something new is wrong.
  489. Kev ^
  490. Ge0rG RFC 2119 does not provide approrpiate wording to go with the time.
  491. dwd Ge0rG, You can strongly encourage. You can advise. But if you RECOMMEND, you are changing the past.
  492. Kev I think Dave's spot on here.
  493. Ge0rG dwd: I see what you mean.
  494. dwd Ge0rG, You *can*, though, say that for XMPP Server 2018 conformance, your new thing is REQUIRED.
  495. Ge0rG "Server implementations created in the year 2017 or later SHOULD add an <x> tag to PMs. All other implementations are strongly encouraged to do so."
  496. Kev Ge0rG: Which isn't needed for interop. So just go with 'strongly recommended' and MAY :)
  497. dwd Ge0rG, Sorta. We have XEPs specifically designed to do what you want. I RECOMMEND you help work on those. ;-)
  498. Kev It doesn't matter whether it's a new implementation that doesn't do it or an old one, an entity has to cope regardless.
  499. Kev Sorry, 'strongly suggested', senior moment.
  500. Ge0rG I'm still not really convinced though. IMO our main goal is to have clear normative language that corresponds to the state of affairs as it is now, if only to attract new people to XMPP and to make implementors' lives as easy as possible. I'm okay with changing the past to achieve that, and people who feel betrayed by that can still dig up the old version of the XEP as their motivation to violate the new RECOMMENDation.
  501. bjc has left
  502. bjc has joined
  503. nicolas.verite has joined
  504. nicolas.verite has left
  505. Kev If you implement the current version of a spec, and get weird interop problems with something else that looks like it's the same version, you've had your life made difficult, not easier.
  506. Ge0rG really, sentences like this are frightening in a network protocol specification: "The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules."
  507. suzyo has left
  508. Kev Terrifying. I can scarcely sleep at night.
  509. intosi has joined
  510. Ge0rG Kev: everybody has their own nightmares, I suppose.
  511. Ge0rG Kev: re "get weird interop problems with something else", my reading of SHOULD in 2119 is that no other party may actually rely on it anyway, because you might always have a reason not to follow the RECOMMENDation
  512. MattJ I read it the other way: if you break a SHOULD, you have to deal with potential interop problems from that
  513. Kev What MattJ says.
  514. Kev Otherwise SHOULD is no different to MAY.
  515. Ge0rG So there is nothing in between SHOULD and MAY that conveys "do it this way, but if you don't then the others have to cope with it"
  516. moparisthebest isn't MUST the word where breaking it makes interop problems happen?
  517. Ge0rG I suppose this actually was a wise design decision on behalf of the Elders of the Internet
  518. Kev moparisthebest: No, SHOULD is.
  519. Kev Ge0rG: If others have to cope with it, it's MAY.
  520. moparisthebest then how do MUST and SHOULD differ Kev ?
  521. Kev From an interoperability point of view - which is what 2119 language cares about
  522. Kev moparisthebest: For SHOULD, you might understand how one can not implement it without affecting interop.
  523. Ge0rG Kev: yes, on re-reading 2119 this became apparent to me now. Thanks to you and Dave and Matt for being patient with me
  524. Kev But generally, in a spec a SHOULD should be matched with 'except when...'
  525. Ge0rG So effectively I MUST NOT change the normative language of an XEP without either making it conditional on a new feature or bumping the namespace.
  526. vurpo has left
  527. vurpo has joined
  528. Kev SHOULD NOT, except where you can mitigate interop considerations in some manner, yes.
  529. Kev :)
  530. Ge0rG Kev: heh :P
  531. moparisthebest yea I need to re-read 2119 it's been too long, thanks :)
  532. Ge0rG However, the question remains what is the most elegant way to convey a new intent (like in the case of <x/>) and to make it a SHOULD eventually
  533. Valerian has left
  534. Guus has left
  535. Yagiza has left
  536. Valerian has joined
  537. vurpo has left
  538. vurpo has joined
  539. goffi has left
  540. waqas has left
  541. suzyo has joined
  542. kaboom has left
  543. Guus has left
  544. uc has left
  545. SamWhited ralphm: Ping, reminder to create me a trello board and add me to the XSF organization if possible
  546. Tobias and check if the board board and the council board belong to the XSF org
  547. SamWhited the board board does, the council board doesn't; we should probably fix that.
  548. Tobias right
  549. Ge0rG board the board board?
  550. Valerian has left
  551. Valerian has joined
  552. Valerian has left
  553. nicolas.verite has joined
  554. nicolas.verite has left
  555. Kev I can fix the Council Board once Ralph makes me as XSF admin.
  556. uc has joined
  557. nicolas.verite has joined
  558. nicolas.verite has left
  559. Guus has left
  560. jere has joined
  561. ralphm has left
  562. nicolas.verite has joined
  563. nicolas.verite has left
  564. ralphm has joined
  565. Yagiza has left
  566. nicolas.verite has joined
  567. nicolas.verite has left
  568. waqas has joined
  569. Ge0rG has left
  570. Tobias has joined
  571. kaboom has left
  572. vurpo has left
  573. vurpo has joined
  574. vurpo has left
  575. vurpo has joined
  576. vurpo has left
  577. vurpo has joined
  578. Ge0rG has left
  579. Flow has joined
  580. vurpo has left
  581. vurpo has joined
  582. vurpo has left
  583. vurpo has joined
  584. vurpo has left
  585. vurpo has joined
  586. suzyo has left
  587. suzyo has joined
  588. Ge0rG has left
  589. vurpo has left
  590. vurpo has joined
  591. vurpo has left
  592. vurpo has joined
  593. nicolas.verite has joined
  594. nicolas.verite has left
  595. vurpo has left
  596. vurpo has joined
  597. waqas has left
  598. Ge0rG has left
  599. bjc has left
  600. suzyo has left
  601. bjc has joined
  602. suzyo has joined
  603. Ge0rG has left
  604. Yagiza has joined
  605. jonasw has left
  606. Mancho has left
  607. vurpo has left
  608. vurpo has joined
  609. vurpo has left
  610. vurpo has joined
  611. Valerian has joined
  612. vurpo has left
  613. vurpo has joined
  614. vurpo has left
  615. vurpo has joined
  616. Arc has left
  617. Yagiza has left
  618. Yagiza has joined
  619. Ge0rG has left
  620. ralphm Kev: looking right now
  621. Tobias has left
  622. ralphm Kev: do you already have an Trello identifier?
  623. ralphm SamWhited: you, too?
  624. SamWhited ralphm: yup, it's just my name, same as my nick
  625. SamWhited I think I'm already on the board trello, but not in the organization so it shows up in my "Personal boards"
  626. ralphm and now?
  627. SamWhited yup, that did it
  628. SamWhited Excellent; I can create an editor board now too. Thanks.
  629. Tobias has left
  630. ralphm SamWhited: who owns the Council board, and can he/she initiate a transfer or something?
  631. SamWhited ralphm: Let me check; I think it's Kev.
  632. SamWhited Kev, Lance, and Tobias are admins; not sure if that's the same as owner or not.
  633. Ge0rG has left
  634. nicolas.verite has joined
  635. nicolas.verite has left
  636. ralphm There should be a 'change team' in the setting of the board
  637. ralphm Hmm. I'm not the owner of the Board board. Only bear and Laura.
  638. ralphm eh, admin
  639. Yagiza has left
  640. ralphm Even though I am admin of the team, I cannot change that
  641. SamWhited Board board appears to already be on the team, I think?
  642. dwd I've nudged Laura, but she seems to be busy.
  643. SamWhited oh, you just want to be an admin; nevermind, makes sense.
  644. Laura has joined
  645. ralphm SamWhited: it is either a documentation bug, or an implementation bug. I filed a ticket.
  646. kaboom has left
  647. Ge0rG has left
  648. jere has joined
  649. Laura hello…
  650. dwd Laura, ralphm was after the Trello board ownership.
  651. kaboom has left
  652. ralphm Yeah, so it turns out I am admin of the team, not the Board Meetings board.
  653. Laura The trello Board board?
  654. kaboom has left
  655. ralphm yes
  656. Laura Fixed
  657. kaboom has left
  658. Guus has left
  659. Ge0rG has left
  660. Laura has left
  661. Ge0rG has left
  662. mimi89999 has joined
  663. Vinilox has joined
  664. Vinilox has left
  665. Vinilox has joined
  666. uc has left
  667. uc has joined
  668. Guus has left
  669. nicolas.verite has joined
  670. mhterres has left
  671. nicolas.verite has left
  672. nicolas.verite has joined
  673. nicolas.verite has left
  674. nicolas.verite has joined
  675. nicolas.verite has left
  676. nicolas.verite has joined
  677. nicolas.verite has left
  678. nicolas.verite has joined
  679. jonasw has left
  680. nicolas.verite has left
  681. nicolas.verite has joined
  682. nicolas.verite has left
  683. nicolas.verite has joined
  684. nicolas.verite has left
  685. nicolas.verite has joined
  686. nicolas.verite has left
  687. nicolas.verite has joined
  688. nicolas.verite has left
  689. ralphm Link Mauve: thanks!
  690. ralphm Laura: thanks!
  691. nicolas.verite has joined
  692. nicolas.verite has left
  693. nicolas.verite has joined
  694. nicolas.verite has left
  695. Valerian has left
  696. nicolas.verite has joined
  697. nicolas.verite has left
  698. nicolas.verite has joined
  699. nicolas.verite has left
  700. nicolas.verite has joined
  701. dwd Does MAM on MIX archive the outgoing message or the incoming one?
  702. Ge0rG would assume that archiving happens on the pubsub node, so only for messages reflected by the MIX
  703. bra has left
  704. Kev dwd: You mean pre-or-post unspecified munging, or something else?
  705. dwd That.
  706. Kev What you get out should be what would be sent to you.
  707. Kev So if you had a pastebin running, I'd expect to get the munged URL from MAM, not the paste that I submitted.
  708. dwd So is the from attribute set to the MIX on the forwarded message? Does it have <jid/>? (That's what I thought... But the only example is 52 and shows the opposite).
  709. Yagiza has joined
  710. Steve Kille Kev: yes
  711. Steve Kille I will sort the text
  712. Kev dwd: The from is always the MIX for MIX messages isn't it?
  713. dwd Kev, Yes. See Example 52.
  714. mimi89999 has joined
  715. Kev by looks right to me, and from looks like a typo.
  716. Kev Is that consistent with your reading?
  717. dwd Yup. Ta.
  718. Zash Are the to/from attributes even needed in MIX-MAM?
  719. Kev Zash: Not really needed, but it's how MAM works, so there doesn't seem huge value removing them.
  720. Kev The <jid xmlns='urn:xmpp:mix:0'>coven+123456@mix.shakespeare.example</jid>, which is always the proxy JID, needs to be in the archived messages to say who it's really from.
  721. Kev That's 123456#coven@mix... now, of course :)
  722. Ge0rG Steve Kille, Kev: what about using 12345%coven@mix? It might be more in line with existing transports, that encode transported IDs by replacing @ with %
  723. Kev Ge0rG: That was exactly my motivation for *not* using it (same as \), I didn't want any confusion when conflating it with existing stuff.
  724. Ge0rG Not that I'd oppose "#", it's also used by transport JIDs (e.g. for irc: `#channel%irc.server.net@irc-transport.xmpp`)
  725. dwd Can we have non-numeric proxy jidlets, too? (As in, in the examples - I assume it's legal)
  726. Ge0rG Kev: that's a great point
  727. Kev Ge0rG: Yeah. I realised that, but it seems like the least bad option from what Steve and I discussed earlier. I'm not tied to the octothorp, other than loving the name.
  728. vurpo has left
  729. vurpo has joined
  730. Ge0rG what about using UUIDs? *ducks&runs*
  731. Kev dwd: That'd probably be sensible.
  732. Kev Ge0rG: What, 123456<uid>coven@mix...? :)
  733. Ge0rG Kev: I had to look up into the example to determine what an octothorp is.
  734. Kev Ah, 'hashtag' to you youngsters.
  735. Ge0rG Kev: no, `#<uuid>+<uuid>@uuid.server.xmpp/<uuid>/<uuid>`
  736. Zash BRÄDGÅRD
  737. Ge0rG Kev: I'm part of the generation that associates "#" with channels, actually
  738. Ge0rG Kev: so having `#channel` in the JID rings a bell with me
  739. Kev Well, Twitter hashtags came from IRC. IRC users started using them to associate messages informally, them actually being a 'thing' came later.
  740. Ge0rG personally, I liked '+' and was surprised by its demise.
  741. Zash I thought it was meant as an inverse channel?
  742. jere has joined
  743. Kev Ge0rG: I liked it, but + in local parts has a definite semantic from email. I felt that reversing the semantic would be confusing.
  744. Kev But your arguments about proxypart coming first seemed compelling.
  745. Ge0rG yay!
  746. Kev So, changing the separator seemed sensible.
  747. Ge0rG Kev: I'm not sure if we are going to expose the proxy JIDs at all to non-tech users, and we are going to realize it's not an email anyway
  748. Kev End users are probably less likely to recognise the + notation than devs. It was confusing devs that I was worried about.
  749. Ge0rG So my vote goes to '+', with '%' a remote second.
  750. moparisthebest + isn't really an email standard anyway, iirc sendmail used +, and qmail or something used -
  751. moparisthebest I have my postfix configured to accept +, -, or . as that seperator :)
  752. Ge0rG what about using a slug of the user's nickname to create the proxy JIDlet?
  753. Zash What if they change it?
  754. Ge0rG Zash: keep it as-is. Also if somebody tries to collide, obviously, use a different JIDlet
  755. Kev Ge0rG: I think we leave choice of proxy JID parts up to the service.
  756. Kev So if they wanted to do that, they could.
  757. Ge0rG Kev: but we could RECOMMEND something. It's not too late! :D
  758. vurpo has left
  759. Zash I'd also like to say that I don't think structured data belongs in jid parts, but I haven't manged to read all of MIX yet so I don't know if there's a good enough reason.
  760. Ge0rG Zash: pseudonymity combined with routability.
  761. Kev Zash: I agree, in principle, but it also doesn't seem harmful, and is beneficial in this case.
  762. Ge0rG Zash: the MIX needs to provide JIDs for all resources of all participants, in a way that prevents you from obtaining their real identity
  763. vurpo has joined
  764. vurpo has left
  765. vurpo has joined
  766. vurpo has left
  767. vurpo has joined
  768. vurpo has left
  769. vurpo has joined
  770. vurpo has left
  771. Kev Right, the Council Trello board is now in the XSF org.
  772. vurpo has joined
  773. Kev ralphm: Thanks for the team stuff.
  774. jere has joined
  775. sezuan has joined
  776. Lance has joined
  777. vurpo has left
  778. vurpo has joined
  779. SamWhited Yey! Thanks Kev and ralphm
  780. vurpo has left
  781. vurpo has joined
  782. uc has left
  783. uc has joined
  784. goffi has left
  785. vurpo has left
  786. vurpo has joined
  787. ralphm has left
  788. vurpo has left
  789. vurpo has joined
  790. vurpo has left
  791. Martin has left
  792. vurpo has joined
  793. ralphm has left
  794. vurpo has left
  795. sezuan has left
  796. vurpo has joined
  797. sonny has joined
  798. vurpo has left
  799. vurpo has joined
  800. SamWhited I just discovered that Trello has "due dates". I haven't used this before. ♡
  801. nyco has left
  802. nicolas.verite has left
  803. nicolas.verite has joined
  804. Steve Kille has left
  805. Steve Kille has left
  806. nicolas.verite has left
  807. arc has left
  808. arc has joined
  809. waqas has joined
  810. kalkin has left
  811. waqas has left
  812. waqas has joined
  813. vurpo has left
  814. vurpo has joined
  815. vurpo has left
  816. vurpo has joined
  817. vurpo has left
  818. vurpo has joined
  819. Steve Kille has joined
  820. arc has left
  821. Ge0rG has left
  822. vurpo has left
  823. vurpo has joined
  824. arc has joined
  825. jonasw Guus: you wanted me to write a blogpost. I cannot recall what it was about
  826. jubalh has joined
  827. tim@boese-ban.de has joined
  828. tim@boese-ban.de has joined
  829. moparisthebest how about the meaning of life
  830. Zash 42?
  831. Guus jonasw: anything xmpp related? :)
  832. jonasw Guus: I cannot recall.
  833. vurpo has left
  834. vurpo has joined
  835. Guus ah, it was pretty obvious, actually: http://logs.xmpp.org/xsf/2017-03-13/#11:59:19
  836. vurpo has left
  837. vurpo has joined
  838. jonasw oh right
  839. Ge0rG has left
  840. vurpo has left
  841. Steve Kille has left
  842. vurpo has joined
  843. nicolas.verite has joined
  844. nicolas.verite has left
  845. nicolas.verite has joined
  846. nicolas.verite has left
  847. vurpo has left
  848. vurpo has joined
  849. kalkin has joined
  850. nicolas.verite has joined
  851. Lance has left
  852. vurpo has left
  853. vurpo has joined
  854. nyco has left
  855. nicolas.verite has left
  856. Yagiza has left
  857. Zash Was there someone asking why the mam:2 namespace bump was needed?
  858. Zash IIRC MattJ said things about security considerations that sounded reasonable. Integration with stanza-ids, and stuff.
  859. MattJ I think dwd was arguing that we should have had a "stanza-ids-are-mam-ids" feature instead of bumping the main namespace
  860. efrit has joined
  861. MattJ There were some other changes though (though not as many as I originally had in the doc when we decided to bump the namespace)
  862. dwd I couldn't *find* any other changes... Might well have been textual ones.
  863. jere has joined
  864. goffi has joined
  865. uc has left
  866. jere has joined
  867. Lance has joined
  868. winfried has left
  869. ralphm has joined
  870. SamWhited has left
  871. nicolas.verite has joined
  872. nicolas.verite has left
  873. iiro.laiho has joined
  874. jonasw has left
  875. daniel has left
  876. nyco has joined
  877. Martin has joined
  878. Martin has left
  879. blipp has left
  880. blipp has joined
  881. nicolas.verite has joined
  882. mimi89999 has left
  883. Guus has left
  884. nyco has joined
  885. iiro.laiho has left
  886. ralphm has left
  887. Flow has left
  888. jubalh has left
  889. nyco has left
  890. vurpo has left
  891. vurpo has joined
  892. vurpo has left
  893. vurpo has joined
  894. vurpo has left
  895. vurpo has joined
  896. nicolas.verite has left
  897. moparisthebest has joined
  898. nicolas.verite has joined
  899. kalkin has left
  900. kalkin has joined
  901. nyco has joined
  902. ralphm has left
  903. blipp has left
  904. blipp has joined
  905. nyco has left
  906. nicolas.verite has left
  907. nyco has joined
  908. boothj5 has joined
  909. arc has left
  910. arc has joined
  911. efrit has joined
  912. nicolas.verite has joined
  913. Tobias has left
  914. nicolas.verite has left
  915. nicolas.verite has joined
  916. Guus has left
  917. Flow has joined
  918. nyco has joined
  919. nicolas.verite has left
  920. kalkin has left
  921. Guus has left
  922. sezuan has left
  923. daniel has joined
  924. kaboom has left
  925. Zash has left
  926. boothj5 has left
  927. ralphm has left
  928. Lance has left
  929. Mancho has joined
  930. Ge0rG has joined
  931. Mancho has left