XSF Discussion - 2019-09-25

  1. mukt2 has joined
  2. zach has left
  3. zach has joined
  4. Mikaela has left
  5. Douglas Terabyte has left
  6. Chobbes has left
  7. Chobbes has joined
  8. lumi has left
  9. matkor has left
  10. matkor has joined
  11. mukt2 has left
  12. Douglas Terabyte has joined
  13. UsL has left
  14. UsL has joined
  15. krauq has left
  16. krauq has joined
  17. testtt has joined
  18. pdurbin has left
  19. kokonoe has left
  20. testtt has left
  21. pdurbin has joined
  22. kokonoe has joined
  23. pdurbin has left
  24. karoshi has left
  25. lskdjf has left
  26. pdurbin has joined
  27. vanitasvitae has left
  28. vanitasvitae has joined
  29. zach has left
  30. zach has joined
  31. neshtaxmpp has left
  32. neshtaxmpp has joined
  33. Chobbes has left
  34. Chobbes has joined
  35. Chobbes has left
  36. mukt2 has joined
  37. UsL has left
  38. UsL has joined
  39. Daniel has left
  40. Daniel has joined
  41. mukt2 has left
  42. Daniel has left
  43. Daniel has joined
  44. gav has left
  45. gav has joined
  46. matkor has left
  47. matkor has joined
  48. UsL has left
  49. pdurbin has left
  50. kokonoe has left
  51. kokonoe has joined
  52. xalek has left
  53. andy has joined
  54. matkor has left
  55. matkor has joined
  56. matkor has left
  57. zach has left
  58. zach has joined
  59. LNJ has joined
  60. matkor has joined
  61. Douglas Terabyte has left
  62. Douglas Terabyte has joined
  63. Nekit has joined
  64. Tobias has joined
  65. Yagiza has joined
  66. LNJ has left
  67. j.r has left
  68. j.r has joined
  69. lorddavidiii has joined
  70. Douglas Terabyte has left
  71. zach has left
  72. zach has joined
  73. Mikaela has joined
  74. lorddavidiii has left
  75. lorddavidiii has joined
  76. wurstsalat has joined
  77. Douglas Terabyte has joined
  78. jcbrand has joined
  79. Douglas Terabyte has left
  80. zach has left
  81. zach has joined
  82. emus has joined
  83. kokonoe has left
  84. kokonoe has joined
  85. goffi has joined
  86. COM8 has joined
  87. COM8 has left
  88. COM8 has joined
  89. jubalh has joined
  90. zach has left
  91. zach has joined
  92. j.r has left
  93. Douglas Terabyte has joined
  94. COM8 has left
  95. aj has joined
  96. Mikaela has left
  97. aj has left
  98. Mikaela has joined
  99. jubalh has left
  100. alameyo has left
  101. alameyo has joined
  102. zach has left
  103. zach has joined
  104. mukt2 has joined
  105. jubalh has joined
  106. mimi89999 has left
  107. mimi89999 has joined
  108. pdurbin has joined
  109. mukt2 has left
  110. APach has left
  111. APach has joined
  112. zach has left
  113. zach has joined
  114. Mikaela has left
  115. pdurbin has left
  116. Mikaela has joined
  117. COM8 has joined
  118. Nekit has left
  119. Nekit has joined
  120. jubalh has left
  121. remko has joined
  122. zach has left
  123. zach has joined
  124. pdurbin has joined
  125. COM8 has left
  126. pdurbin has left
  127. lorddavidiii has left
  128. lorddavidiii has joined
  129. matkor has left
  130. matkor has joined
  131. zach has left
  132. zach has joined
  133. j.r has joined
  134. waqas has left
  135. j.r has left
  136. mimi89999 has left
  137. zach has left
  138. zach has joined
  139. pep. jcbrand: looking at the updates. I'm on the phone though so I'll do github things later on.
  140. jcbrand pep. Thanks no rush!
  141. jcbrand The moderation XEP is still WIP
  142. jcbrand So don't look at that 😛
  143. pep. A message with* full certainty
  144. jcbrand Thanks
  145. pep. Do XEPs using 422 also have to talk about 359 btw?
  146. jcbrand I guess sub-dependencies don't need to be explicitly mentioned
  147. pep. Say tomorrow we say "no more 359, let's use 765"
  148. pep. We'd only have to change 422. I'm not sure that's practical but..
  149. karoshi has joined
  150. Daniel has left
  151. mukt2 has joined
  152. kokonoe has left
  153. Douglas Terabyte has left
  154. Daniel has joined
  155. Mikaela has left
  156. kokonoe has joined
  157. mimi89999 has joined
  158. Mikaela has joined
  159. debacle has joined
  160. Douglas Terabyte has joined
  161. pep. jcbrand: do you think we can loosen the restriction on the fulljid?
  162. pep. For retractions
  163. pep. Just like we did for LMC
  164. Zash `muc ? full_jid : bare_jid`
  165. winfried has left
  166. winfried has joined
  167. pep. For retractions, yeah I guess
  168. Douglas Terabyte has left
  169. Zash Maybe it would be good to have a XEP discussing JID based access / authorization like this
  170. Zash Could have the matching rule from privacy lists / blocking command there too
  171. jcbrand pep. Where do you see a restriction concerning full JID? Is it implicit in one of the examples?
  172. pep. > MUST only be processed when both the original message and retraction request are received from the same full-JID.
  173. pep. > A retraction MUST only be processed when both the original message and retraction request are received from the same full-JID.
  174. Steve Kille has left
  175. pep. I guess that's an artifact of the protoXEP not being new
  176. Martin has joined
  177. Martin At https://xmpp.org/software/clients.html profanity links to profanity.im but the new website is https://profanity-im.github.io/. Right now profanity.im should forward but they were already considering ditching the domain, so you should better change that to prevent linking to a domain squatter in the future.
  178. Zash But ... why
  179. Martin I don't know.
  180. Zash Martin: It's a matter of updating a JSON file via Github PR
  181. LNJ has joined
  182. jcbrand pep. Thanks, will update.
  183. Martin Zash, if you point me to that repo I will create an MR. :)
  184. Martin s/M/P
  185. jonas’ fear not for I have returned
  186. Zash Martin https://github.com/xsf/xmpp.org/tree/master/data
  187. Ge0rG jonas’! Are you okay!?
  188. Zash You were gone?
  189. Martin 3 days in a cave?
  190. Martin Sorry for not realizing, but the girls sobbing in front of that cave were not heared in munich.
  191. Steve Kille has joined
  192. Zash Emerges as 🤖 ?
  193. winfried has left
  194. winfried has joined
  195. winfried has left
  196. winfried has joined
  197. dele has joined
  198. jonas’ Ge0rG, I was just on vacation :D
  199. jonas’ and I wasn’t able to use XMPP for reasons I don’t understand
  200. jonas’ and I had nothing there to debug
  201. jonas’ quite frustrating
  202. Ge0rG jonas’: no VPN? no mobile?
  203. jonas’ Ge0rG, mobile data coverage was too bad to use
  204. Ge0rG even for XMPP? eww!
  205. murabito has left
  206. jonas’ except with the congstar thing which doesn’t have my credentials and just 32kbit/s
  207. murabito has joined
  208. jonas’ Ge0rG, yeah, once I started to use the link it broke down :)
  209. Douglas Terabyte has joined
  210. Martin Really? I was able to use xmpp on a train ride where I was not able to open any website.
  211. winfried has left
  212. winfried has joined
  213. jonas’ Martin, "broke down" as in "No coverage"
  214. jonas’ like, not even for calls
  215. jonas’ and the wifi there probably filtered DNS heavily
  216. jonas’ or maybe ports
  217. jonas’ but Conversations said "Server not found", so I guess they filtered DNS
  218. Martin has left
  219. dele has left
  220. dele has joined
  221. UsL has joined
  222. jubalh has joined
  223. dele has left
  224. Dele (Mobile) has joined
  225. zach has left
  226. zach has joined
  227. Mikaela has left
  228. Mikaela has joined
  229. winfried has left
  230. winfried has joined
  231. larma has left
  232. j.r has joined
  233. Martin has joined
  234. larma has joined
  235. debacle has left
  236. winfried has left
  237. winfried has joined
  238. Dele (Mobile) has left
  239. Mikaela has left
  240. COM8 has joined
  241. Mikaela has joined
  242. mukt2 has left
  243. pdurbin has joined
  244. dele has joined
  245. jubalh has left
  246. COM8 has left
  247. pep. jcbrand: hmm, maybe use wording similar to https://xmpp.org/extensions/xep-0308.html#nt-idm46554800195296 ? Not just "JID"
  248. pep. I guess you can also mention relying on occupant id optionally
  249. kokonoe has left
  250. Dele (Mobile) has joined
  251. kokonoe has joined
  252. jubalh has joined
  253. winfried has left
  254. winfried has joined
  255. j.r has left
  256. debacle has joined
  257. Dele (Mobile) has left
  258. pdurbin has left
  259. jonas’ Ge0rG, regarding that self-ping failure: the issue is twofold. first, the pinger interprets remote-server-not-found as "client was removed from the room" as per XEP-0410. second, it does not auto-rejoin after being removed (or maybe the rejoin fails because remote-server-not-found and it doesn’t re-try)
  260. jonas’ I don’t think that remote-server-not-found should be interpreted as "client has been removed from the room"
  261. Ge0rG jonas’: that's an interesting point.
  262. Ge0rG jonas’: it might be a network outage or a server outage.
  263. jonas’ exactly
  264. jonas’ I think it should be treated like a timeout
  265. jonas’ (especially since a re-join is not likely to succeed anyways)
  266. jcbrand pep. Done. I already mentioned that the occupant id should be checked in MUCs, clarified that further.
  267. pep. No SHOULD right? I know some people are not particularly happy with occupant-id, (because de-pseudonimisation, which is the goal), even though they haven't expressed that clearly yet.
  268. flow jonas’, it looks like I can't find the context of "that self-ping failure". Would you be so kind and point me to it?
  269. zach has left
  270. zach has joined
  271. jonas’ flow, https://github.com/horazont/aioxmpp/issues/312
  272. jonas’ Ge0rG, and even on server outages, the room state may still be persistent on the server an the client might not have actually been removed.
  273. lskdjf has joined
  274. jonas’ so I’m very confident that assuming that r-s-n-f means "you got removed" is wrong.
  275. jubalh has left
  276. Ge0rG jonas’: good point. Wanna send a PR to the XEP? ;)
  277. jonas’ after auditing RFC 6120 for more error conditions of that type, yes
  278. jonas’ remote-server-timeout is another one
  279. Ge0rG if only we had a practically useful error scheme.
  280. jonas’ I think we do, we just don’t use it well
  281. pep. jcbrand: I guess that's fine like that for the protoXEP. I'd probably relax the dependency on occupant-id though
  282. jcbrand Why? It's necessary IMO
  283. pep. It's useful for better UX yeah
  284. pep. Not especially necessary
  285. jcbrand It's necessary to prevent impersonation
  286. Nekit has left
  287. pep. A client not implementing occupant-id (or a future equivalent?) would probably just ignore retractions when they can't validate the identity of the sender
  288. kokonoe has left
  289. larma pep., I'd say it's SHOULD (without retractions won't work in many cases) but not a MUST 😉
  290. pep. larma: yeah, SHOULD would be fine
  291. jcbrand pep. that's why it's a requirement, a client that doesn't support occupant-id can't support retractions
  292. Nekit has joined
  293. pep. jcbrand: why not?
  294. jcbrand because it can't validate the identity of the sender
  295. pep. For all other cases it works
  296. Ge0rG jcbrand: you can validate the sender without occupant-id, just in a more limited manner
  297. jcbrand Ge0rG: How? AFAIK you can determine whether don't know it's the same sender, but you can't always determine that you DO know it's the same sender.
  298. jcbrand Ge0rG: How? AFAIK you can determine whether you don't know it's the same sender, but you can't always determine that you DO know it's the same sender.
  299. Ge0rG jcbrand: as long as both you and the sender are joined to the MUC, you can know it's the same sender
  300. jcbrand yes but that's not always the case, hence the requirement
  301. Ge0rG jcbrand: it was good enough for LMC
  302. jcbrand It's a huge issue and not good enough IMO
  303. Ge0rG jcbrand: it's a minor issue, because it only affects public semi-anon MUCs and you can't rely on user identity in those anyway.
  304. Ge0rG jcbrand: I might be Ge0rG, a Council member, or Ge0rG, a russian troll bot.
  305. jcbrand At least I would know that a retracted message was by the same entity
  306. Ge0rG so there is not much difference between the authenticity of the things I say now vs. the things I say after a leave & rejoin
  307. jcbrand There is, because I know it's the same entity
  308. Ge0rG only if you require occupant-id
  309. jcbrand which I do
  310. larma jcbrand, I know you didn't touch that from the previous protoXEP, but I really don't like the tombstones thing: It changes the meaning of a messages UID in a non-backwards compatible fashion. This will most likely lead to different or even perceivably random behavior within clients that implement MAM but don't implement retractions...
  311. jcbrand at least in this XEP
  312. jonas’ Ge0rG, https://github.com/xsf/xeps/pull/834#issue-321176452
  313. Yagiza has left
  314. Yagiza has joined
  315. Ge0rG jonas’: 👍
  316. jcbrand Ge0rG: You and I both are of the opinion that it makes sense to try and "fix" MUCs as much as possible instead of putting our hopes on some future migration/rewrite. Requiring occupant id is a very good step in that direction.
  317. Ge0rG jcbrand: I'm not sure I agree.
  318. Ge0rG jcbrand: I'm not sure I disagree, either.
  319. kokonoe has joined
  320. Ge0rG jcbrand: my point is: occupant-id is a significant change of user identity exposition in semi-anon MUCs, and this step shouldn't be taken lightly.
  321. Ge0rG jcbrand: there is no _technical_ requirement on occupant-id in either LMC or Retractions.
  322. jcbrand It's security related
  323. larma jcbrand, (also regarding tombstones) shouldn't the logic of how to apply fastenings in MAM be part of fastening and not part of every individual XEP? I expected that to be the main reason why we'd want a generic fastening XEP, no?
  324. jonas’ oh look at how awake I am
  325. jonas’ I didn’t even realise that Ge0rG is in Council.
  326. Ge0rG jonas’: it will be a very interesting discussion on whether that change mandates a namespace bump.
  327. Ge0rG jonas’: therefore I explicitly only approved the XEP with my author hat on.
  328. Ge0rG puts on his robe and author hat
  329. jonas’ "yes, but..."
  330. jcbrand larma: I think we should have a way to actually remove the message from the archive and not just append a hint that it shouldn't be shown. Most fastenings will be append only I presume.
  331. Ge0rG jcbrand: you can't actually remove a message from MAM, merely remove its payload.
  332. jcbrand Ge0rG: "removal" means tombstoning
  333. Ge0rG Ah, okay
  334. jcbrand This is another security issue IMO. It's better to not send certain messages to clients, even if a retraction will be sent afterwards
  335. larma > However a server that wishes to remove messages from the middle of an archive, e.g. to remove accidentally transmitted sensitive information may omit the <message> stanza from inside the <forwarded> element
  336. jcbrand The retraction is only for currently connected clients who already received the offending message
  337. Ge0rG Can't we already just implement a distributed chat history database synchronization protocol, instead of adding one quirk on top of another over unreliable message transport stream semantics?
  338. jcbrand larma: I'm not sure what you're point with that quote is. The point of tombstoning is to not remove the original message
  339. jcbrand larma: I'm not sure what you're point with that quote is. The point of tombstoning is to remove the original message
  340. jcbrand Sorry... there was a "not" in there
  341. Kev Ge0rG: I don't know, can we?
  342. jubalh has joined
  343. Ge0rG Kev: you tell me
  344. larma jcbrand, the MAM XEP suggests that you probably want to remove the <message> from the <forwarded> (and optionally replace it with a <retracted>) instead of adding <retracted> inside <message>
  345. larma at least that's how I read it
  346. jcbrand larma: Look at the example, the <retracted> element is inside the <message> element.
  347. Ge0rG Kev: I've recently thought a bit about one of the aspects of that: https://gist.github.com/ge0rg/5ae3365196a0c046fc596bbf707fdc15
  348. jcbrand larma: Are you looking at my PR? Or where are you reading this?
  349. jubalh has left
  350. larma jcbrand, yes your PR has <retracted> inside <message> inside <forwarded> but 313§2.1 suggests that you shouldn't do that and instead remove <message> from <forwarded> and optionally replace it with an appropriate placeholder (like <retracted> directly inside <forwarded>)
  351. Kev Ge0rG: that's what bind2's trying to help with, I think? (The (4) part at least).
  352. Ge0rG Kev: yes, but bind2 will only do a very small subset of #4
  353. Kev Probably.
  354. jcbrand larma: Then you don't know who the retracted message was from
  355. Kev Ge0rG: Or, rather, probably needs to be extended to cover them.
  356. larma jcbrand, then you have to add that to <retracted>?
  357. jcbrand What's the difference? Why is this an issue?
  358. Ge0rG Kev: I'm not saying that bind2 isn't the right syntactic vehicle to perform MAM-Sub. It just lacks momentum.
  359. jcbrand larma: IMO it looks more correct semantically the way it is now
  360. Kev Ge0rG: Right.
  361. larma jcbrand: It is an issue because with your way it is undecidable if the message was send this way from the original sender or if it was done by MAM
  362. jcbrand Ok you have a point
  363. larma Also IMO the retracted message from MAM should probably also tell who retracted it and when?
  364. jcbrand yes, "when" is a good addition
  365. Ge0rG so store an original tombstone plus the retraction message?
  366. Ge0rG so store an "original" tombstone plus the retraction message?
  367. larma Ge0rG, we are approaching what a proper fastening XEP would add to a MAM message for every fastening 😉
  368. larma <forwarded xmlns='urn:xmpp:forward:0'> <delay xmlns='urn:xmpp:delay' stamp='2019-09-20T23:08:25Z'/> <retracted xmlns='urn:xmpp:message-retract:0' from='romeo@montague.example' by='lord@capulet.example' stamp='2019-09-20T23:09:15Z' /> </forwarded>
  369. larma (by being optional and defaulting to same as from)
  370. mukt2 has joined
  371. zach has left
  372. zach has joined
  373. larma jcbrand, > Clients MUST set the XEP-0359 'origin id' attribute on sent messages to make them suitable for message retraction. Shouldn't be needed in MUCs as we use MUCs stanza-id instead (and it would be stupid if you can't moderate messages that don't have an origin-id :D)
  374. jubalh has joined
  375. j.r has joined
  376. alameyo has left
  377. alameyo has joined
  378. larma jcbrand, https://github.com/xsf/xeps/pull/833/files#diff-30e15b71462f098e1b7b4cb6931c64bbR84 is type=normal intended here?
  379. Ge0rG larma: you tell us it will break MAM and Carbons?
  380. larma Ge0rG, huh?
  381. Ge0rG larma: type=normal is the code word to enter the black magic underground of xmpp message routing.
  382. Ge0rG I really need to update my "What's wrong" presentation
  383. Zash Shall we issue a blanket statement that examples without @type means "any type"
  384. jcbrand Is a type attribute mandatory?
  385. Zash No, but it defaults to 'normal'
  386. karoshi has left
  387. Zash so `<message/>` == `<message type="normal"/>`
  388. karoshi has joined
  389. kokonoe has left
  390. mukt2 has left
  391. kokonoe has joined
  392. alameyo has left
  393. larma jcbrand, https://github.com/xsf/xeps/pull/833/files#diff-30e15b71462f098e1b7b4cb6931c64bbR62 if you leave out type=groupchat here, the message won't be delivered to room occupants. Technically type=normal works in the other case because it is the MUC sending it, but type=groupchat is better IMO because it implies that every room occupant receives it and also if this was a self-retraction message, it would be type=groupchat as well.
  394. jcbrand larma: Thanks, I'll fix
  395. larma (We can also go with type=headline for the retraction message, but I bet this would just f**k up things)
  396. Ge0rG larma: yeah, it would
  397. Ge0rG I think we should be using headline for MAM retrieval and such
  398. jubalh has left
  399. Ge0rG just to annoy pidgin users.
  400. LNJ has left
  401. Martin has left
  402. Martin has joined
  403. zach has left
  404. zach has joined
  405. pdurbin has joined
  406. Chobbes has joined
  407. Chobbes has left
  408. Chobbes has joined
  409. pdurbin has left
  410. Zash What is the deal with https://xmpp.org/extensions/xep-0182.html ?
  411. zach has left
  412. zach has joined
  413. Zash It registers the namespace urn:xmpp:errors but I'm not aware of anything that uses it
  414. dele has left
  415. dele has joined
  416. Zash https://xmpp.org/registrar/errors.html hm
  417. Chobbes has left
  418. Chobbes has joined
  419. Ge0rG <too-many-stanzas/> is one for the firewall
  420. Daniel has left
  421. flow jonas’> I think we do, we just don’t use it well [re error scheme] I think it could be improved here and there: https://github.com/igniterealtime/Smack/blob/93aaf6d8d7df1071a224ef406738ff322c20724b/smack-extensions/src/main/java/org/jivesoftware/smackx/ping/PingManager.java#L156
  422. Daniel has joined
  423. alameyo has joined
  424. Chobbes has left
  425. Chobbes has joined
  426. zach has left
  427. zach has joined
  428. Andrew Nenakhov has joined
  429. j.r has left
  430. Andrew Nenakhov has left
  431. LNJ has joined
  432. zach has left
  433. zach has joined
  434. winfried has left
  435. winfried has joined
  436. winfried has left
  437. winfried has joined
  438. lumi has joined
  439. winfried has left
  440. winfried has joined
  441. Chobbes has left
  442. winfried has left
  443. winfried has joined
  444. zach has left
  445. zach has joined
  446. remko has left
  447. remko has joined
  448. lorddavidiii has left
  449. winfried has left
  450. winfried has joined
  451. Maranda has left
  452. Maranda has joined
  453. lorddavidiii has joined
  454. zach has left
  455. zach has joined
  456. winfried has left
  457. winfried has joined
  458. alameyo has left
  459. Guus has left
  460. Guus has joined
  461. alameyo has joined
  462. winfried has left
  463. dele has left
  464. winfried has joined
  465. dele has joined
  466. dele has left
  467. j.r has joined
  468. jubalh has joined
  469. winfried has left
  470. winfried has joined
  471. zach has left
  472. zach has joined
  473. dele has joined
  474. gav has left
  475. gav has joined
  476. kokonoe has left
  477. zach has left
  478. zach has joined
  479. Kev has left
  480. alameyo has left
  481. dele has left
  482. Chobbes has joined
  483. kokonoe has joined
  484. dele has joined
  485. Mikaela has left
  486. Mikaela has joined
  487. j.r has left
  488. j.r has joined
  489. karoshi has left
  490. karoshi has joined
  491. dele has left
  492. rion has left
  493. rion has joined
  494. j.r has left
  495. dele has joined
  496. zach has left
  497. zach has joined
  498. j.r has joined
  499. patrick has joined
  500. Kev has joined
  501. mimi89999 has left
  502. jubalh has left
  503. mimi89999 has joined
  504. lorddavidiii has left
  505. lorddavidiii has joined
  506. kokonoe has left
  507. j.r has left
  508. APach has left
  509. APach has joined
  510. j.r has joined
  511. zach has left
  512. zach has joined
  513. LNJ has left
  514. LNJ has joined
  515. Chobbes has left
  516. Chobbes has joined
  517. j.r has left
  518. zach has left
  519. zach has joined
  520. edhelas I reopened https://github.com/xsf/xeps/pull/824 a few days ago because it was merged by mistake, should I do something else to make it reviewed by the Council ?
  521. wojtek has joined
  522. !xsf_Martin has left
  523. Ge0rG edhelas: tell Council about it. Ideally through the means of an agenda submission to dwd, but shouting about it in here at the right time might work
  524. jonas’ edhelas, posting it somewhere around 15:00Z on a wednesday in an XSF room is a good start :)
  525. wojtek has left
  526. Guus moments ago, in the council room:
  527. Guus https://igniterealtime.org:443/httpfileupload/20d808ee-fbdf-4ab5-857d-95891aefbcd7/image.png
  528. !xsf_Martin has joined
  529. kokonoe has joined
  530. andy has left
  531. andy has joined
  532. winfried has left
  533. Wojtek has joined
  534. winfried has joined
  535. kokonoe has left
  536. mukt2 has joined
  537. Mikaela has left
  538. Wojtek has left
  539. Mikaela has joined
  540. alameyo has joined
  541. mukt2 has left
  542. zach has left
  543. zach has joined
  544. Wojtek has joined
  545. Wojtek has left
  546. winfried has left
  547. winfried has joined
  548. aj has joined
  549. aj has left
  550. kokonoe has joined
  551. zach has left
  552. zach has joined
  553. pdurbin has joined
  554. jonas’ MattJ, can we make a time window (2h or 3h in duration) where we try to figure out how the XSF Registrar is supposed to work technically?
  555. lovetox has joined
  556. Mikaela has left
  557. Mikaela has joined
  558. MattJ Sure
  559. MattJ How about this time +1w - 2h?
  560. zach has left
  561. zach has joined
  562. Ge0rG MattJ: that would overlap with Council Meeting
  563. winfried has left
  564. winfried has joined
  565. MattJ -1h?
  566. MattJ or just... after the council meeting next week
  567. Chobbes has left
  568. Chobbes has joined
  569. mimi89999 has left
  570. pdurbin has left
  571. mimi89999 has joined
  572. jubalh has joined
  573. winfried has left
  574. winfried has joined
  575. Mikaela has left
  576. Mikaela has joined
  577. gav has left
  578. zach has left
  579. zach has joined
  580. lorddavidiii has left
  581. lorddavidiii has joined
  582. waqas has joined
  583. kokonoe has left
  584. jubalh has left
  585. Mikaela has left
  586. emus has left
  587. zach has left
  588. zach has joined
  589. dele has left
  590. Steve Kille has left
  591. Mikaela has joined
  592. karoshi has left
  593. karoshi has joined
  594. david has left
  595. david has joined
  596. Steve Kille has joined
  597. mimi89999 has left
  598. mimi89999 has joined
  599. zach has left
  600. zach has joined
  601. j.r has joined
  602. kokonoe has joined
  603. j.r has left
  604. mukt2 has joined
  605. david has left
  606. david has joined
  607. !xsf_Martin has left
  608. !xsf_Martin has joined
  609. Martin has left
  610. mukt2 has left
  611. Martin has joined
  612. Chobbes has left
  613. zach has left
  614. zach has joined
  615. kokonoe has left
  616. Chobbes has joined
  617. kokonoe has joined
  618. zach has left
  619. zach has joined
  620. Martin has left
  621. mukt2 has joined
  622. pdurbin has joined
  623. zach has left
  624. zach has joined
  625. Daniel has left
  626. Daniel has joined
  627. sonny has left
  628. pdurbin has left
  629. Douglas Terabyte has left
  630. Douglas Terabyte has joined
  631. Chobbes has left
  632. Chobbes has joined
  633. Douglas Terabyte has left
  634. debacle has left
  635. zach has left
  636. zach has joined
  637. karoshi has left
  638. karoshi has joined
  639. kokonoe has left
  640. andrey.g has left
  641. Nekit has left
  642. jubalh has joined
  643. debacle has joined
  644. lorddavidiii has left
  645. zach has left
  646. zach has joined
  647. lorddavidiii has joined
  648. andrey.g has joined
  649. emus has joined
  650. mukt2 has left
  651. zach has left
  652. zach has joined
  653. dwd has left
  654. Mikaela has left
  655. Mikaela has joined
  656. sonny has joined
  657. xalek has joined
  658. karoshi has left
  659. karoshi has joined
  660. zach has left
  661. zach has joined
  662. emus has left
  663. pdurbin has joined
  664. Yagiza has left
  665. jubalh has left
  666. pdurbin has left
  667. Chobbes has left
  668. emus has joined
  669. LNJ has left
  670. zach has left
  671. zach has joined
  672. emus has left
  673. remko has left
  674. Nekit has joined
  675. Douglas Terabyte has joined
  676. matkor has left
  677. lovetox has left
  678. emus has joined
  679. matkor has joined
  680. jubalh has joined
  681. jubalh has left
  682. Tobias has left
  683. emus has left
  684. mukt2 has joined
  685. emus has joined
  686. zach has left
  687. zach has joined
  688. mukt2 has left
  689. emus has left
  690. lorddavidiii has left
  691. lorddavidiii has joined
  692. goffi has left
  693. wurstsalat has left
  694. wurstsalat has joined
  695. kokonoe has joined
  696. Chobbes has joined
  697. zach has left
  698. zach has joined
  699. goffi has joined
  700. Nekit has left
  701. remko has joined
  702. zach has left
  703. zach has joined
  704. remko has left
  705. emus has joined
  706. zach has left
  707. zach has joined
  708. Daniel has left
  709. goffi has left
  710. jcbrand has left
  711. debacle has left
  712. Daniel has joined
  713. Daniel has left
  714. andy has left
  715. zach has left
  716. zach has joined
  717. mukt2 has joined
  718. aj has joined
  719. mukt2 has left
  720. karoshi has left
  721. zach has left
  722. zach has joined
  723. Chobbes has left
  724. Chobbes has joined
  725. Mikaela has left
  726. matkor has left
  727. matkor has joined
  728. Daniel has joined
  729. lorddavidiii has left
  730. lorddavidiii has joined
  731. rion has left
  732. rion has joined
  733. emus has left
  734. lumi has left
  735. pdurbin has joined
  736. UsL has left
  737. UsL has joined
  738. sonny has left
  739. sonny has joined
  740. Daniel has left
  741. pdurbin has left