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


  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


  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’


  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


  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


  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


  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


  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