XSF Discussion - 2019-09-14

  1. patrick has left
  2. patrick has joined
  3. mukt2 has joined
  4. zach has left
  5. zach has joined
  6. Maranda has left
  7. Maranda has joined
  8. lumi has left
  9. lumi has joined
  10. LNJ has left
  11. mukt2 has left
  12. zach has left
  13. zach has joined
  14. Douglas Terabyte has left
  15. Douglas Terabyte has joined
  16. mukt2 has joined
  17. mukt2 has left
  18. lumi has left
  19. arc has left
  20. arc has joined
  21. mukt2 has joined
  22. aj has joined
  23. UsL has left
  24. UsL has joined
  25. moparisthebest has left
  26. moparisthebest has joined
  27. aj has left
  28. zach has left
  29. zach has joined
  30. pdurbin has joined
  31. inputmice has joined
  32. moparisthebest has left
  33. moparisthebest has joined
  34. remko has joined
  35. pdurbin has left
  36. remko has left
  37. zach has left
  38. zach has joined
  39. mukt2 has left
  40. mukt2 has joined
  41. lskdjf has left
  42. pdurbin has joined
  43. Yagiza has joined
  44. kokonoe has left
  45. kokonoe has joined
  46. mukt2 has left
  47. zach has left
  48. zach has joined
  49. mukt2 has joined
  50. Steve Kille has left
  51. Steve Kille has joined
  52. waqas has left
  53. jubalh has joined
  54. zach has left
  55. zach has joined
  56. pdurbin has left
  57. jubalh has left
  58. pdurbin has joined
  59. jubalh has joined
  60. mimi89999 has left
  61. mimi89999 has joined
  62. zach has left
  63. zach has joined
  64. patrick has left
  65. matkor has joined
  66. pdurbin has left
  67. jubalh has left
  68. neshtaxmpp has joined
  69. remko has joined
  70. rion has left
  71. rion has joined
  72. zach has left
  73. zach has joined
  74. jubalh has joined
  75. jubalh has left
  76. kokonoe has left
  77. kokonoe has joined
  78. jubalh has joined
  79. jubalh has left
  80. jubalh has joined
  81. arc has left
  82. arc has joined
  83. rion > [11:26:06] <Zash> Dear lazyxmpp, I wish for a PRECIS implementation suitable for use in C I need one too
  84. zach has left
  85. zach has joined
  86. krauq has left
  87. andy has left
  88. remko has left
  89. remko has joined
  90. jubalh has left
  91. zach has left
  92. zach has joined
  93. kokonoe has left
  94. zach has left
  95. zach has joined
  96. kokonoe has joined
  97. pdurbin has joined
  98. adiaholic has joined
  99. krauq has joined
  100. winfried has left
  101. winfried has joined
  102. adiaholic has left
  103. lovetox has joined
  104. adiaholic has joined
  105. flow join forces and consider starting one :)
  106. Alex has left
  107. Alex has joined
  108. kokonoe has left
  109. Ge0rG Patch libidn?
  110. zach has left
  111. zach has joined
  112. kokonoe has joined
  113. andy has joined
  114. kokonoe has left
  115. Mikaela has joined
  116. LNJ has joined
  117. kokonoe has joined
  118. kokonoe has left
  119. zach has left
  120. zach has joined
  121. Nekit has joined
  122. mtavares has left
  123. kokonoe has joined
  124. remko has left
  125. kokonoe has left
  126. Mikaela has left
  127. mtavares has joined
  128. kokonoe has joined
  129. Mikaela has joined
  130. mimi89999 has left
  131. mimi89999 has joined
  132. kokonoe has left
  133. Daniel What is the threat analysis for 'resource/presence leak'? Since for ever the community has treated that like something really bad. I never really understood why. I know that it makes some IQ based attacks easier. But really those can also be done over MUC and we generally don't put huge warnings signs up before someone joins a muc
  134. wurstsalat has joined
  135. kokonoe has joined
  136. ralphm Security Considerations are there to allow people to make informed choices when implementing features. There are always tradeoffs between functionality, UX, and security. Something being called a presence leak doesn't mean it is 100% bad and you MUST NOT allow for it ever.
  137. Daniel Right. I'm just trying to figure out if I'm missing something
  138. kokonoe has left
  139. adiaholic has left
  140. APach has joined
  141. APach has left
  142. APach has joined
  143. zach has left
  144. zach has joined
  145. flow Daniel, could potentially drain your mobiles battery if I know your resource
  146. flow (not saying that it isn't possible otherwhise too)
  147. remko has joined
  148. flow besides that, joining a MUC is an explicit decission to reveal your presence and potentially your resource. Leaks are typically unintentional
  149. ralphm Right, but for MUC you could decide to only send availability once and not sync it with your away/xa/etc
  150. ralphm As an example
  151. ralphm That then leaks less information
  152. alameyo has left
  153. Guus has left
  154. Daniel To be clear. (our terminology is a bit confusing here) I'm talking about leaking the resource. Not leaking availability
  155. ralphm Through MUC?
  156. Daniel Mostly Auto responding to certain messages
  157. jonas’ Daniel, it can be used to scan for accounts
  158. Daniel has left
  159. Daniel has joined
  160. jonas’ normally we take some care to avoid that being possible unless you know a resource
  161. ralphm I think it is not so much about leaking resources per se, as you generally reveal them to your contacts anyway, but making them unpredictable
  162. mukt2 has left
  163. remko has left
  164. karoshi has joined
  165. mukt2 has joined
  166. kokonoe has joined
  167. mukt2 has left
  168. mukt2 has joined
  169. pep. jonas’: vcard-temps and public omemo keys allow that
  170. pep. jonas’: vcard-temp and public omemo keys allow that
  171. flow I think it is about leaking the resource per se
  172. pep. (Scanning accounts)
  173. flow Remote entities shouldn't know that there is a connected client if they are not explicitly allowed to
  174. zach has left
  175. zach has joined
  176. flow andt hen even be able to send data directly to that client
  177. kokonoe has left
  178. Daniel flow, I get that I guess… That is a slightly different argument than leaking the resource (as in that specific string)
  179. mukt2 has left
  180. mukt2 has joined
  181. goffi has joined
  182. mukt2 has left
  183. mukt2 has joined
  184. Daniel has left
  185. Daniel has joined
  186. kokonoe has joined
  187. inputmice has left
  188. remko has joined
  189. mukt2 has left
  190. mukt2 has joined
  191. Steve Kille has left
  192. Steve Kille has joined
  193. mukt2 has left
  194. mukt2 has joined
  195. kokonoe has left
  196. debacle has joined
  197. Dele (Mobile) has joined
  198. Ge0rG Daniel: I agree with you that the leaking is overhyped as a security issue
  199. zach has left
  200. j.r has joined
  201. zach has joined
  202. kokonoe has joined
  203. jubalh has joined
  204. remko has left
  205. kokonoe has left
  206. jabberjocke has joined
  207. Nekit has left
  208. debacle has left
  209. j.r has left
  210. LNJ has left
  211. LNJ has joined
  212. zach has left
  213. zach has joined
  214. j.r has joined
  215. kokonoe has joined
  216. APach has left
  217. rion has left
  218. APach has joined
  219. Daniel https://www.businessinsider.de/ihr-koennt-bald-offenbar-nachrichten-von-threema-auf-whatsapp-verschicken-2019-9 IM regulation wrt to interop is happening and nobody has asked us for our expertise. is there a bank account we need to wire money to to get heard? google translate link: https://translate.google.com/translate?hl=&sl=auto&tl=en&u=https%3A%2F%2Fwww.businessinsider.de%2Fihr-koennt-bald-offenbar-nachrichten-von-threema-auf-whatsapp-verschicken-2019-9
  220. LNJ has left
  221. rion has joined
  222. rion has left
  223. rion has joined
  224. rion has left
  225. rion has joined
  226. APach has left
  227. pep. I wonder if Matrix also tried and also got ignored
  228. kokonoe has left
  229. kokonoe has joined
  230. rion has left
  231. ralphm It reads to me that this is a paper goal, and I don't think that half 2020 is realistic if that's the case.
  232. Daniel obviously 2020 is not realistic. but that's not the point. the point is that they seem to be somewhat serious about attempting it
  233. rion has joined
  234. rion has left
  235. ralphm The politicians or the companies?
  236. rion has joined
  237. Daniel the politicians
  238. ralphm Right
  239. kokonoe has left
  240. ralphm I'm curious if Ge0rG has heard back from his contacts.
  241. Ge0rG ralphm: no news yet. But I'll try to reach out again, I was told to remind them some months in
  242. Ge0rG That article is a good trigger for a reminder, actually
  243. ralphm This article seems like a good reason to. Was that contact in one of those parties?
  244. Ge0rG ralphm: I don't think so, he's an employee of one of the agencies
  245. Ge0rG ralphm: I'd love to be able to propose a way forward for E2EE
  246. Ge0rG This is something he was most concerned about
  247. Ge0rG MLS is probably something we need to evaluate properly in advance
  248. kokonoe has joined
  249. pep. > There is a lobby battle ahead Thank you article, I wasn't expecting that.
  250. kokonoe has left
  251. Daniel also no sources to when and where they said this
  252. Daniel but who needs sources in 2019
  253. Ge0rG pep.: sharpen your axes, we are going full in
  254. ralphm Also curious if governments want 'in' on the conversations.
  255. pep. Ge0rG: the XSF has no resources for this kind of battle. Companies using XMPP would, more than us already anyway
  256. Daniel that's only a problem if you believe that democracy is about who can bring the most resources to a battle
  257. dele has joined
  258. dele has left
  259. pep. I believe that's a harsh reality
  260. dele has joined
  261. ralphm Companies are people now, in some jurisdictions, so arguably the are part of the demos.
  262. Daniel maybe we need to go the indirect route and convince 'our' lobby groups (CCC, FSFE, …) first
  263. Ge0rG Daniel: we've seen recently in the copyright debate that it's not about "resources" in general, but about money to politicians. Having 200k people demonstrating on the streets is meaningless
  264. pep. Daniel: that might help. EDRi also maybe
  265. ralphm I was also thinking about IETF
  266. dele has left
  267. jubalh has left
  268. Ge0rG ralphm: is IETF a political lobby org?
  269. Daniel i actually tried to talk to a representative from the FSFE about that and he was like: no I don’t want that i just want free software; to which i replied but that's not the point and also having them interop would actually strengthen free software because network effect; and he was like: but we just want to convince everyone to use Conversations; to which i was like: …
  270. Daniel i don’t think the IETF is a lobby group in the sense that the CCC is one
  271. pep. Daniel: can we put up a talk for CCC about this?
  272. Daniel IM interop? yeah i still have one in the pipeline for the 'privacey week' but they haven’t accepted it (yet?)
  273. pep. What do we know about it already? Maybe we should also contact matrix
  274. Daniel the idea was if it goes well at privacy week i'll do the same one at ccc
  275. pep. Ok
  276. ralphm Ge0rG: no but they, under ISOC, might have ideas on how to approach this.
  277. ralphm And I'm not surprised at all about FSF(E)
  278. pep. I hear FSF/FSFE can be quite different btw, I haven't experienced that myself though
  279. Ge0rG Maybe we need to find someone else from the FSF then?
  280. ralphm Yes, there's also recently been considerable friction between them
  281. ralphm And I think neither cares about protocols
  282. Ge0rG Anyway, we need to act now.
  283. pep. I guess this kind of talk at POSS will fall in deaf ears
  284. jubalh has joined
  285. kokonoe has joined
  286. kokonoe has left
  287. kokonoe has joined
  288. Daniel maybe i should try calling those two people
  289. kokonoe has left
  290. madhur.garg has joined
  291. LNJ has joined
  292. kokonoe has joined
  293. jubalh has left
  294. jubalh has joined
  295. lskdjf has joined
  296. pdurbin has left
  297. debacle has joined
  298. Ge0rG Daniel: keep us up to date please. I'm going to write to the ministry employee early next week
  299. zach has left
  300. zach has joined
  301. jubalh has left
  302. jabberjocke has left
  303. Daniel I need to figure out what point I'm trying to make and how to get that across
  304. j.r has left
  305. Ge0rG Daniel: "please keep moving this, good work! Demand open standard APIs! Hire me to make E2EE work!"
  306. jubalh has joined
  307. debacle has left
  308. kokonoe has left
  309. j.r has joined
  310. kokonoe has joined
  311. Guus has joined
  312. alameyo has joined
  313. jubalh has left
  314. winfried has left
  315. winfried has joined
  316. krauq has left
  317. kokonoe has left
  318. zach has left
  319. zach has joined
  320. murabito has left
  321. andy has left
  322. krauq has joined
  323. remko has joined
  324. zach has left
  325. zach has joined
  326. Nekit has joined
  327. kokonoe has joined
  328. krauq has left
  329. pdurbin has joined
  330. flow > Daniel> flow, I get that I guess… That is a slightly different argument than leaking the resource (as in that specific string) I think it is the same argument assuming the leaked resource(string) is one of a "currently" connected client
  331. zach has left
  332. zach has joined
  333. moparisthebest has left
  334. pdurbin has left
  335. moparisthebest has joined
  336. waqas has joined
  337. moparisthebest Ge0rG, Daniel: https://www.theregister.co.uk/2019/05/28/german_government_encryption/
  338. zach has left
  339. zach has joined
  340. moparisthebest Maybe they are excluding open standards on purpose
  341. ralphm Now, what did I say?
  342. moparisthebest Nice chat network you got there, sure would be a shame if some regulation happened to it, maybe if you were to give us plain text though...
  343. Yagiza *GIRL CRY*
  344. moparisthebest What you don't trust the govt with everything? I mean in all the history of the German gover... Oh right...
  345. ralphm Don't mention
  346. kokonoe has left
  347. larma Daniel > i actually tried to talk to a representative from the FSFE about that Who did you talk to? Also I doubt interop will work with encryption, as there has to be an official, gov-supported encryption standard for that. So if any, we get unencrypted interop and encryption will only work within a messenger network.
  348. lumi has joined
  349. kokonoe has joined
  350. larma What could make sense though is to require messengers to have easy data export in a standard format that could then be imported in other messengers, making it easier to move to a different network
  351. Daniel right. because nobody has ever created standardized encryption before that works across different providers and vendors
  352. larma Daniel, we don't even have it within a single network, how should that work across networks?
  353. larma We have about 5 different e2e-encryption standards implemented by clients in XMPP
  354. larma (only counting those in well-known open source implementations)
  355. larma And it makes sense to have multiple, because they have different properties.
  356. lumi has left
  357. ralphm And also, you'll probably want the ability to upgrade to newer/better approaches in the future.
  358. Daniel and six part time open source developers not being able to agree means that you can’t do it?
  359. j.r has left
  360. larma Even TLS is a monster of different encryption protocols. It just works because connections are short living and only between two entities.
  361. ralphm If you get parties to federate based on XMPP, even if it just unencrypted, you already have a connected network. Whatever e2ee can then be put on top.
  362. moparisthebest Within just a few years here omemo was invented and adopted by all major clients, so I really don't know what you mean larma
  363. larma Not by all major clients, just by a subset for a specific niche (personal im)
  364. ralphm But omemo is from the end-all-be-all, though.
  365. zach has left
  366. zach has joined
  367. moparisthebest Also larma TLS is just for short lived connections????
  368. moparisthebest Are you talking about something else
  369. ralphm And I purposely turn it off because it invariably fails to work properly with my collection of multiple clients.
  370. larma Have you seen a TLS session running for several months as do OMEMO sessions?
  371. moparisthebest Yes
  372. larma Huh?
  373. Zash XMPP s2s connections would
  374. larma Zash, several months? I hope you install updates, don't you?
  375. moparisthebest Wait until you hear about quic where sessions can survive reboots and network changes etc
  376. Maranda has left
  377. Maranda has joined
  378. ralphm I've been mentioning (IETF) QUIC a couple of times.
  379. ralphm I think it definitely deserves an experiment to have an XMPP binding for.
  380. Daniel also i'm afraid that the people who want to regulate IM won’t stop because larma thinks E2EE (a subset of the entire thing) can’t be done. so I'd rather be part of the debate and help them do a slightly less shitty job than they would do if they'd only listen to facebook and google
  381. Zash larma: that's besides the point. and there can be months between updates to the servers or tls library that would mandate a restart
  382. moparisthebest ralphm: yea and I suspect you could do away with stream management inside quic too
  383. ralphm Daniel: to be honest, I would already settle for just the XMPP based federation, even without e2ee.
  384. ralphm moparisthebest: but it might be useful for file transfer
  385. moparisthebest Yes as long as they don't also ban e2e in the process
  386. ralphm Oh, I get what you meant, sorry. Yes, definitely.
  387. moparisthebest Cause as you said that can just be done over top of federation later
  388. ralphm Right
  389. ralphm moparisthebest: and about QUIC, yeah, there are quite a few benefits.
  390. larma QUIC probably won't survive reboots in practical scenarios as that would require to persist session keys I am talking about how TLS works in practice. Sure you can keep connections running longer, but ideally you don't so you can upgrade protocol version and ciphers for higher security at some point. And again TLS is between two entities. A group chat could consist of hundreds of different client versions if there was cross messenger interop...
  391. larma I guess I will be able to find a set of 5 TLS clients/servers that don't share a single common cipher compatibility
  392. moparisthebest So maybe you have Rock solid e2e between 2 entities and not as good in group chats?
  393. moparisthebest In fact that's what we have
  394. moparisthebest Is your point don't bother at all or?
  395. kokonoe has left
  396. kokonoe has joined
  397. Daniel i don’t get why "it's going to be difficult" is an argument for "let's not even attempt to try this"
  398. moparisthebest Also lessons have been learned from TLS, not everything should be an option etc, have you seen 1.3 ?
  399. larma I just think it's unlikely to get to a common standard for e2e. There are a lot of voices against OMEMO in the XMPP community alone (for some good reasons). That said, for unecrypted interop at least I see potential. It could even be that we can require unencrypted interop and messengers can voluntarily do encrypted interop if they want to.
  400. moparisthebest It vastly limits options, and http2 requires a specific cipher for instance
  401. larma > Daniel > > i actually tried to talk to a representative from the FSFE about that > Who did you talk to?
  402. moparisthebest larma: right, and the voices against omemo didn't matter did they? All main clients support it
  403. Daniel larma, the guy who gave the free your android talk at gpn
  404. moparisthebest It's not perfect, but perfect is the enemy of good, and it's good
  405. ralphm moparisthebest: except omemo is only about text
  406. moparisthebest Right, so it covers 95% of the use case for IM then? Great
  407. larma Daniel, I will be at the FSFE european community meetup in November, so I might be able to bring up that topic. I know that the president of FSFE use(d) Dino, so at least there is a certain interest present.
  408. Daniel fwiw I personally see greater challenges when it comes to group chats. because different IMs do them vastly different. however that is all besides the point. the point is that THEY want to do this and 'we' have 20 years worth of experience on the *how*
  409. ralphm Well, one of the arguments here is that people needing to use this also want to hide who's talking to whom, and I don't see how to do this in XMPP.
  410. ralphm And another indeed groups and MAM.
  411. ralphm We do indeed have 20 years worth of experience on federation.
  412. j.r has joined
  413. ralphm And I would probably be a bit sad if for groups we'd have to settle on MUC.
  414. Daniel i mean we could explain to them what parts are more easily federatable (is that a word?) (1:1, unencrypted, simple media sharing); and I'd rather have us explaining that to them than letting Facebook Inc do the explaining
  415. zach has left
  416. zach has joined
  417. ralphm Calling
  418. ralphm Yes
  419. flow > Daniel> i don’t get why "it's going to be difficult" is an argument for "let's not even attempt to try this" me neither
  420. ralphm Right. My reservations around e2ee are orthogonal to attempting to get services to federate.
  421. jonas’ +1 Daniel
  422. moparisthebest Actually group chat is a really good example
  423. moparisthebest Everyone agrees it's hard, everyone agrees muc isn't ideal, still how many years later here we are
  424. Ge0rG We rather should try to support the involved law makers in ensuring that things aren't botched from the start.
  425. moparisthebest Mix is an attempt to make it more perfect, where is that
  426. kokonoe has left
  427. ralphm moparisthebest: in progress
  428. ralphm And I'd love to have it sooner rather than later, but some of it is not easy
  429. moparisthebest I'm just saying it would have been silly to have avoided muc forever while waiting for mix
  430. Daniel MIX (and that's changing topics now) is pretty sad. I think it somehow got off to a wrong start and there is big resentment in the open source community toward it
  431. ralphm moparisthebest: sure
  432. moparisthebest Which is essentially what the "e2e is too hard" argument is
  433. ralphm Daniel: I mostly draw it up to ignorance, which is ok
  434. Daniel ralphm, maybe. but how can we make progress in that situation
  435. ralphm moparisthebest: no, MIX is achievable. I don't know about e2ee.
  436. Ge0rG Ignorance is also what I've experienced when trying to improve MIX. 🤷‍♂️
  437. ralphm I mean, I'm not discouraged by people looking at and going AARGH
  438. moparisthebest ralphm: except the opposite has happened in practice, we have working e2e, no working mix though
  439. Daniel i'm somewhat discouraged by people trying to "fix muc" with self ping, occupant id, and 100 others hacks like allowing members to read the affliations just to get something simple as a list of people who are in a room
  440. ralphm MIX needs to cater for a world with multiple devices, with a saner join model, and then some. I believe we can get it to be much easier for client devs. For servers there might be an impact that relies on server side support.
  441. Ge0rG ralphm: did you write your suggestions to standards@?
  442. Daniel or let me clarify that. i'm not discouraged by people trying to "fix muc" but by the fact that we have somehow given them the impression that this is the more achievable path than implementing MIX
  443. ralphm So various ideas there are solid, some need work. I'm going to take some time to look at that in the coming weeks
  444. Ge0rG ralphm: write a blog! 😉
  445. ralphm Ge0rG: I might
  446. Ge0rG Daniel: maybe the underlying problem isn't "MIX is too complex to tackle" but "server developers don't have enough time to make large changes at once"
  447. ralphm moparisthebest: as I said, I always disable e2ee because it doesn't work for me. Maybe it is just me.
  448. Ge0rG So that a path of small improvements of what's there already is working out better
  449. ralphm Ge0rG: but they do for each inventing their own
  450. Ge0rG Even if we are bound to end up in a local maximum.
  451. zach has left
  452. zach has joined
  453. Ge0rG ralphm: I also always disable E2EE.
  454. Ge0rG ralphm: none of those parties have provided reasonable specifications yet.
  455. ralphm My point is that I don't buy that argument
  456. ralphm (from them)
  457. lumi has joined
  458. Ge0rG ralphm: I was mainly talking about the OSS implementations out there.
  459. ralphm Sure, that's a valid point
  460. kokonoe has joined
  461. Ge0rG And as MUC isn't going anywhere, it's worth fixing it.
  462. moparisthebest Doesn't change the fact that omemo "just works" for the majority of people
  463. ralphm I have no metrics to make that argument
  464. jonas’ moparisthebest, ejabberd has a partial MIX implementation in the current release
  465. moparisthebest Most people don't use as many clients as you do etc
  466. jonas’ I’m going to start a MIX implementation in aioxmpp against that
  467. moparisthebest Most people just have a phone only, the ones that have a desktop also use a client that supports it on there
  468. Daniel well the MUC that is not going to go away is this kind of muc; the muc that we are in right now. however that kind of muc doesn’t suffer that much under the limitations of MUC
  469. Daniel so it does’t have to go away
  470. moparisthebest Again, not perfect, but good, waiting for perfect gets you in the waiting for mix forever mode
  471. Daniel however the "private group chat" can easily be switched over. and will also benefit from what mix has to over
  472. Daniel *offer
  473. Ge0rG Daniel: I agree. Still, somebody needs to write the code, then to find out the places where the MIX spec is broken, get them fixed and rewrite the code finally.
  474. Ge0rG I'm still not convinced that MIX is solving all the known technical problems of MUC.
  475. ralphm Like?
  476. andy has joined
  477. Kev has joined
  478. Daniel i kinda wish someone would address my MIX feedback so i could move on implementing it…
  479. Daniel or even invite me to do a PR i guess
  480. Ge0rG ralphm: my pet issue is message loss during s2s interruptions
  481. ralphm It would be good to have a list of those and document how such issues are, or are not (yet?), addressed by MIX.
  482. Ge0rG ralphm: I don't remember my other points raised around 2016.
  483. jonas’ Daniel, you got a +1 and no -1nes on the PEP node thing. Please just do a PR
  484. ralphm Ge0rG: yeah, that needs work
  485. jonas’ not sure where Steve Kille is
  486. Kev has left
  487. ralphm Enjoying his weekend?
  488. Daniel that might be a tiny bit undeserverd but I never got the impression that MIX is welcoming to PRs
  489. Ge0rG ralphm: one of my points, the incompatibility of the roster with MIX entries, has been addressed two or three years later, it seems to me
  490. jonas’ ralphm, for three months?
  491. jonas’ Daniel, true, in a way
  492. ralphm As I said, I'm going to try and dislodge things
  493. Ge0rG Daniel: not just PRs, but any kind of change requests?
  494. jonas’ Daniel, FTR, I added a +1 to that thread, maybe that gets it rolling again
  495. Ge0rG ralphm: feel free to make a list from what was written on standards@ over the last years
  496. Daniel one more than the other maybe
  497. ralphm Ge0rG: various comments I raised have been addressed by Steve last time around, though.
  498. ralphm And after that I was less involved, so didn't follow up
  499. Ge0rG ralphm: so you say I should re-read the XEPs and what I wrote in 2016, and just submit the open points as new feedback? I'd do that, but I lack the time.
  500. Daniel assuming that I would go ahead and make a PR. what is it that we want to do exactly? private pep node, multiple items, one item per channel, client can’t modify it. last item notify is off (so a client can +notify that node but not get bothered with the last item for no reason on connect)
  501. dele has joined
  502. Ge0rG I wouldn't mind at all if somebody else did it.
  503. ralphm Understood. Time is precious. But I do have some, so am going to use it for MIX
  504. dele has left
  505. moparisthebest And to be clear my only point was no one is saying "group chat too hard we should give up" so why say the same about e2e that's all, sorry for starting mix discussion :)
  506. jonas’ Daniel, all of what you say sounds excellent
  507. Ge0rG ralphm: > ralphm: feel free to make a list from what was written on standards@ over the last years
  508. Daniel and MIX-PAM will automatically send presence to all the items
  509. jonas’ Daniel, if and only if presence is enabled for that MIX, IIRC you can turn that off?
  510. jonas’ (that type of metadata should maybe be included in that PEP node?)
  511. ralphm Daniel: I am not following. What are you talking about?
  512. Daniel yes… so a client would have to be able to modify that paramater
  513. jonas’ Daniel, wouldn’t that work via the existing PAM-IQ-flows?
  514. jonas’ Daniel, wouldn’t that work via the existing PAM/MIX-IQ-flows?
  515. Daniel jonas’, i would have to look into that again
  516. jonas’ let’s start it simple though
  517. Ge0rG Daniel: weren't there issues with multi item PEP?
  518. Daniel ralphm, moving channels out of the roster
  519. ralphm Daniel: I missed that was an issue. Can you explain why that is a problem?
  520. Daniel ralphm, didn’t you raise the same issue during the summit?
  521. jonas’ goes and fetches the standards@ link
  522. jonas’ ralphm, https://mail.jabber.org/pipermail/standards/2019-June/036172.html
  523. Daniel mostly because it is mixing concerns
  524. Daniel i might not want a roster
  525. ralphm Daniel: my primary concern was that it requires servers to know about MIX. I'm not sure if I still think that is a problem. Sure it means that if your server doesn't you can use MIX. A counter argument is that at some point progress means you have to let that go.
  526. zach has left
  527. zach has joined
  528. jonas’ ralphm, servers need to know about MIX anyways, that’s '405
  529. ralphm Daniel: not having a roster indeed is a good point
  530. ralphm And I did raise that.
  531. Daniel i remember that
  532. Ge0rG ralphm: From my 2016 memory: non MIX clients need to get a copy of the roster without the rooms. This means servers need to disco a client before sending roster, and roster versioning becomes a mess.
  533. ralphm Thanks for bringing that up again.
  534. Daniel i also see virtually no argument in favor of putting it in the roster
  535. Daniel and a lot of (some bigger than others) arguments against doing that
  536. jonas’ (FTR, the roster mail I linked was what I was referring to when I was ironically asking whether Steve was enjoying his weekend for three months now ;))
  537. ralphm Ge0rG: wait huh?
  538. Ge0rG Also you might not want automatic presence delivery to all rooms, but this is a minor issue.
  539. jonas’ Ge0rG, the 2016 design still had only those MIXes where you’d send presence in the roster
  540. Yagiza has left
  541. Ge0rG jonas’: which is also bonkers, because how do you know of the others?
  542. jonas’ yeah
  543. Ge0rG I remember the bad things that happen if you add a MUC to your roster.
  544. ralphm Knowing which channels you have joined is orthogonal from which channels you send presence to and the current roster integration conflates that? Yes I see that argument.
  545. jonas’ s/bad/fun/
  546. Ge0rG jonas’: fun for an outside sadistic watcher, yeah
  547. mr.fister has joined
  548. Ge0rG ralphm: it would also require roster annotations to be inside the respective room elements to know those are not people
  549. jonas’ 👿
  550. jonas’ 😈
  551. ralphm Ge0rG: I disagree with that point
  552. Ge0rG Because, surprisingly, a client needs to know that when opening a chat window
  553. Ge0rG ralphm: it's not a MUST, but the alternatives are worse
  554. ralphm Hmm
  555. Ge0rG Say, disco#info to all roster entries after connecting.
  556. ralphm Or doing that right when while opening a chat.
  557. ralphm And caching it.
  558. mukt2 has left
  559. Daniel not just opening the chat. but take the simple task of learning what channels you are joined
  560. mukt2 has joined
  561. ralphm Obviously CAPS are in issue for this.
  562. ralphm An issue
  563. Daniel because when starting the client you might want to have open tabs for all channels
  564. Daniel how would i do that if the roster items are not annotated
  565. ralphm Daniel: right
  566. jonas’ (something about inbox)
  567. ralphm Heh
  568. Ge0rG ralphm: you also need to know that when receiving a message from MAM. Which is why I've insisted on adding <x/> elements into MUC PMs.
  569. Daniel also you might want to learn what nodes you are subscribed to for a specific channel
  570. Daniel in MucSub there is a get me my 'channels' command. and then each items lists the nodes
  571. Daniel *currently subscribed nodes
  572. Ge0rG ralphm: making the UI depend on another roundtrip is a horrible idea. What if you just lost your network connection, or are on EDGE?
  573. ralphm Sure, I see that argument, but once you know it is a MIX Channel, that's forever, likely.
  574. Ge0rG ralphm: think of thin clients.
  575. ralphm Daniel: having to query the full list all the time is an issue, too, so you need some versioning there too?
  576. jonas’ or web clients, for that matter
  577. Ge0rG Do they have to store a local list of MIXes now?
  578. Daniel also MIX-PAM already has those annotations
  579. Ge0rG ralphm: how is all that outweighing a simple child element / a dedicated list in PEP?
  580. ralphm I'm not saying it is
  581. ralphm Just exploring what's being said here. Happy to see all these points.
  582. Ge0rG ralphm: you said you disagree with that point.
  583. Ge0rG ralphm: I've argued all that back in 2016. It's nice to see we have finally moved beyond it.
  584. ralphm I disagreed that it has to be in the roster
  585. Ge0rG > ralphm: it would also require roster annotations to be inside the respective room elements to know those are not people ralphm [16:43]: > Ge0rG: I disagree with that point I read that as you disagreeing with annotations.
  586. ralphm Ge0rG: sure, to get anywhere we need to reevaluate all of it
  587. Ge0rG ralphm: please do, and blog it.
  588. ralphm Yes, sir. 🤣
  589. Ge0rG ralphm: or make a spreadsheet of problems and their respective solutions
  590. pdurbin has joined
  591. Ge0rG Because I'm honestly tired of arguing all that, over and again.
  592. ralphm I definitely want this to be easy and thin.
  593. ralphm E.g. I think having to ask every channel for MAM is not good.
  594. ralphm Vn.
  595. Ge0rG ralphm: I agree with the general idea. Just ping me once you've taken over authorship... 😉
  596. Daniel what is the counter argument of putting it in a private pep node roughly in i style of: > private pep node, multiple items, one item per channel, client can’t modify it. last item notify is off (so a client can +notify that node but not get bothered with the last item for no reason on connect)
  597. zach has left
  598. zach has joined
  599. Ge0rG Daniel: it sounds sensible to me, but I haven't really worked with PEP, so don't know the pitfalls
  600. Daniel (note that servers could implement it as a virtual pep node)
  601. Ge0rG Daniel: Zash recently mentioned issues with having multiple items in one node. But those might be practical and not protocol limitations, so can be fixed in a MIX supporting server
  602. ralphm Daniel: might work, indeed. Was just mostly interested in the issues, rather than looking at possible solutions.
  603. jonas’ the only pitfall I see is that it might not scale to enormous numbers of channels
  604. ralphm jonas’: I'm curious what is enormous
  605. Daniel can you RSM through pubsub items?
  606. ralphm Yes
  607. mukt2 has left
  608. jonas’ Daniel, in theory, yes
  609. Daniel so i don’t see the issue
  610. jonas’ ralphm, anything which breaks the stanza limit
  611. jonas’ Daniel, you have to fetch the channel list on each reconnect, don’t you?
  612. Ge0rG Can you receive a delta of all PEP changes, given a certain initial state? From MAM?
  613. Daniel that's why it is multiple items
  614. jonas’ Daniel, but if those are 1k items, the fetch will still be annoying on each connect, especially on mobile.
  615. Daniel also if you are afraid it will break your stanza size limit it will also break your roster fetch
  616. ralphm When I was in VEON, our Slack had many channels. I was in 40+, and then there are the unnamed 'channels' for talking to an immutable set of people.
  617. ralphm My daughter uses WhatsApp quite a bit
  618. ralphm Many many channels
  619. ralphm None of them ever closed
  620. ralphm (though many go unused)
  621. mukt2 has joined
  622. ralphm My current thinking is that PEP might not be the best model. If a server manages all your subscriptions, why would a client need to touch it? Maybe just a plain old iq would be good.
  623. Daniel so the argument against PEP would be that we that we don’t benefit from roster versioning
  624. jonas’ ralphm, the PEP node is read-only to the client
  625. jonas’ Daniel, we cannot benefit from roster versioning in any serious way anyways because for non—MIX clients the entries must not be in the roster
  626. jonas’ it would at least make roster versioning much more complex on the server side
  627. Daniel i'm not overly attached to PEP. i just don’t like to use roster
  628. pdurbin has left
  629. ralphm Aye
  630. Daniel ralphm, there would need to be some kind of subscribe to changes mechanism. and +notify would _one_ solution to signal that
  631. ralphm Right.
  632. Syndace has left
  633. Daniel also reusing syntax. my client might already have PEP notification handling
  634. Ge0rG > Can you receive a delta of all PEP changes, given a certain initial state? From MAM?
  635. jonas’ Ge0rG, there are rumors about MAM for PubSub
  636. Daniel that probably doesn’t help you with PEP
  637. Ge0rG jonas’: you can't implement a rumor
  638. ralphm Just to be clear, this is hardly PEP, but node-on-account, but I digress.
  639. Ge0rG Whatever it is, I want a delta mechanism.
  640. ralphm jonas’: without MAM for pubsub, I'm unsure how we could do other nodes in MIX
  641. ralphm Ge0rG: noted
  642. Daniel > Just to be clear, this is hardly PEP, but node-on-account, but I digress. fair enough
  643. Syndace has joined
  644. jonas’ #undef PEP #define PEP PubSub-on-user-accounts
  645. Zash PEP Plus
  646. Zash XEP-0222, XEP-0223
  647. APach has joined
  648. ralphm But but
  649. mr.fister has left
  650. mr.fister has joined
  651. holatestey has joined
  652. winfried has left
  653. winfried has joined
  654. winfried has left
  655. winfried has joined
  656. zach has left
  657. holatestey has left
  658. zach has joined
  659. Daniel in an attempt to get to a point where I could actually make a PR. if we didn’t use a pubsub node on the account we would have to specificy: 1) querying the list; (possibly with RSM) 2) subscribing to the list (can be done with putting a mix namespace into caps) 3) new item notification 4) retract item notification am i missing anything?
  660. Daniel are those four tasks close enough to pubsub to justify borrowing the syntax
  661. Daniel or is it better to create own syntax for that
  662. Ge0rG Daniel: receiving actual deltas if you were offline for some weeks
  663. winfried has left
  664. winfried has joined
  665. jonas’ Daniel, provisions which would allow us to introduce versioning later
  666. jonas’ ha, what Ge0rG said
  667. ralphm I'd not put in a PR at this point. Rather reiterate the issues and requirements.
  668. jonas’ ralphm, the issues have been re-iterated on the ML since 2016
  669. jonas’ nobody has objected to Daniels bringing it up three months ago
  670. jonas’ I think we can move forward with proposing an update to this *Experimental* XEP to finally achieve some progress
  671. mukt2 has left
  672. Daniel it doesn’t have to be a PR. and i'm happy not having to create one
  673. ralphm Ok, if you don't want to wait for me, maybe it'll work.
  674. Daniel but i would like to get to a point where i'm not being ignored
  675. mukt2 has joined
  676. jonas’ ralphm, what timeframe do you anticipate? MIX has been "waiting" for years now.
  677. Daniel ralphm, wait for you? what are you planning to do?
  678. jonas’ a few more weeks probably won’t hurt if you’re going to do an in-depth evaluation which might actually move us forward
  679. jonas’ what Daniel is saying, effectively
  680. ralphm I have time on my hands and will try and dislodge the whole thing
  681. arc has left
  682. arc has joined
  683. jonas’ my dictionary does not list a sensible translation of `dislodge`
  684. jonas’ my dictionary does not list a sensible (in this context) translation of `dislodge`
  685. ralphm Get it unstuck.
  686. jonas’ I see
  687. neshtaxmpp has left
  688. neshtaxmpp has joined
  689. arc has left
  690. arc has joined
  691. Ge0rG I'm sure the underlying conditions have changed significantly since I tried the in depth evaluation.
  692. jonas’ ralphm, I don’t mean to attack you. It seems just frustrating to re-iterate all the arguments we’ve had yet another time.
  693. ralphm Consider the discussions on MAM2 in light of MIX.
  694. jonas’ which reminds me that certain Reactions-interested folks also don’t feel heard with their feedback on XEP-0422
  695. ralphm jonas’: well, I don't think you have to. I'll try to dig things up.
  696. ralphm jonas’: I still owe responses to people reacting to my post. Anything specific you mean?
  697. jonas’ all in https://mail.jabber.org/pipermail/standards/2019-September/036422.html
  698. ralphm Right.
  699. zach has left
  700. zach has joined
  701. Daniel there is also some underlying meta debate one could go into. so assuming I'm company X and I had some money to develop a group chat thing. I'll start looking into MIX but it doesn’t yet do 100% of what i want to achieve. so i provide feedback (like the roster thing); my feedback is being ignored. however my customers needs a group chat now and not in 5 years. so what do I do; do I fork MIX internally and use a "fixed MIX" which due to other constraints in MIX might still only be 99% of what i'm trying to do. or do I start from scratch and develop something new that fits my needs and my needs alone
  702. ralphm I think Kev did a good job of attempting to help out with his document. People not immediately responding doesn't mean they are being ignored. What do you think are reasonable expectations from people putting in volunteer efforts in our standards process?
  703. jonas’ ralphm, I carefully chose my words to say "feel"
  704. Daniel seems like a lot of companies in the past have gone down the second road. P1, erlang solutions, redsolution etc
  705. jonas’ I understand as well as anyone that volunteer standards process will have delays and everything
  706. jonas’ ralphm, I’m not sure how we can fix this, but this is in a similar vein as what Daniel says
  707. ralphm Yep, this stuff is not easy. Some people want something now because they have business constraints, and some others have other priorities.
  708. kokonoe has left
  709. ralphm I'm not opposed to companies doing their own private thing in the meanwhile.
  710. larma has left
  711. larma has joined
  712. Daniel i don’t have an answer to that (otherwise i wouldn’t be asking) but is there anything we can do to help people who need solutions now and keep them in the community
  713. Daniel as opposed to what some companies are currently doing with "let's develop our own XEPs"
  714. ralphm Well, doing your own is a valid choice if you have internal pressure and don't require interop.
  715. Daniel you say "in the meantime" as if they were coming back once MIX is done. but i highly doubt that
  716. ralphm Even if we fix the protocol to most desire, it will still take a while to get to a place where we can migrate away from MUC.
  717. ralphm Daniel: I'm not sure how to help that other than my offer to move things forward.
  718. ralphm So in the short while that is fastening/references and MIX
  719. ralphm I also have opinions on calling, but I don't want to overcommit.
  720. neshtaxmpp has left
  721. neshtaxmpp has joined
  722. kokonoe has joined
  723. ralphm And larma's comments are valid, so I'll try to get to that next week.
  724. kokonoe has left
  725. lumi has left
  726. winfried has left
  727. winfried has joined
  728. kokonoe has joined
  729. zach has left
  730. zach has joined
  731. winfried has left
  732. winfried has joined
  733. arc has left
  734. arc has joined
  735. mukt2 has left
  736. zach has left
  737. zach has joined
  738. Daniel > Daniel: receiving actual deltas if you were offline for some weeks Yes. Being able to retrieve deltas is probably a good argument for using custom syntax. I've re-read parts of 60 to see if we can build something like that on pubsub, rsm or mam but it doesn't seem to be the case. Not without either being super hacky or having massiv overheads
  739. kokonoe has left
  740. Daniel I mean you don't actually want to get pubsub notifications from MAM. Not if your desire is to safe bandwidth
  741. mukt2 has joined
  742. Ge0rG Can a smart server aggregate those?
  743. Nekit has left
  744. kokonoe has joined
  745. Daniel Well I guess it would be fake mam in practice. Because you don't actually want to store the individual notification messages. It would just use a time stamp as a replacement for a version identifier and the your server would play out the notifications wrapped in pubsub wrapped in mam to you
  746. Daniel But that's not worth the overhead imho
  747. kokonoe has left
  748. Daniel Compared to a custom syntax that would probably work more similar to how roster versioning works
  749. wurstsalat has left
  750. lumi has joined
  751. kokonoe has joined
  752. lumi has left
  753. Nekit has joined
  754. lumi has joined
  755. kokonoe has left
  756. ralphm But you can also use RSM directly on pubsub?
  757. Daniel ralphm, that won’t give you the deletes
  758. Daniel also what is your after id
  759. Daniel if id (like in bookmarks 2) is the jid
  760. ralphm Right
  761. Ge0rG Can we generalize that into something to properly synchronize multi item PEP / PubSub?
  762. Zash pubsub since?
  763. Ge0rG I have no idea
  764. Zash https://xmpp.org/extensions/xep-0312.html
  765. kokonoe has joined
  766. ralphm That also doesn't send retracts.
  767. ralphm Problem is that PubSub is not designed to store retractions.
  768. Daniel and it's time based…
  769. ralphm So servers don't (currently) have that information.
  770. ralphm Daniel: yeah, that's not ideal either
  771. Ge0rG Can we design something new around MAM then?
  772. zach has left
  773. zach has joined
  774. ralphm What MAM really means in pubsub has been debated before, but I don't think there's been a conclusion:
  775. ralphm a) you expose item storage as the archive
  776. Daniel a) you still don’t have a good ID for use in after b) syntax wise that would mean pubsub notification inside forward inside mam results (=massive overhead)
  777. ralphm b) you store the notifications as the archive
  778. Daniel and the ideas with the deltas is to avoid overhead
  779. ralphm a) clearly doesn't help for this.
  780. j.r has left
  781. ralphm And by the way, you could have a mode where replays are *not* enveloped in forwarded.
  782. j.r has joined
  783. ralphm But item or retract directly in result.
  784. ralphm But I'm not sure.
  785. Daniel i mean what you really want is 'replay me events since x' and then you just get vanilla pubsub events; without any wrapper
  786. Daniel but at that point you are so far away from what pubsub can do that it is probably better to just use a custom syntax for that
  787. Ge0rG And x should be an ID, not a timestamp
  788. ralphm Daniel: maybe, but then how to differentiate between life events
  789. ralphm Ge0rG: yes
  790. ralphm Live events
  791. Daniel do you have to? roster versioning doesn’t use anything different for live events
  792. mukt2 has left
  793. ralphm Race conditions and sync are not fun
  794. Daniel seems to work for roster versioning
  795. mukt2 has joined
  796. Ge0rG With roster you know when und sync is complete
  797. Daniel do i?
  798. Ge0rG With roster you know when the sync is complete
  799. Nekit has left
  800. ralphm And you don't get new events until you send presence, no?
  801. Ge0rG Isn't it all in one iq response?
  802. Daniel no you send ver to server. server sends you result (empty) and then a bunch of pushes
  803. Daniel and pushes are of the same syntax like normal pushes would be
  804. Ge0rG Okay
  805. ralphm Ah, right
  806. Ge0rG But it does have merit to know when it's over, at least in a new design
  807. ralphm But we currently don't have notification ids
  808. ralphm For pubsub
  809. Daniel yes
  810. Daniel that what i mean with "by the time you have hacked all that in you are probably better of just doing something custom"
  811. ralphm Roster versioning has strictly increasing version numbers, right?
  812. Daniel the xep doesn’t say i think
  813. ralphm 4.4
  814. Ge0rG ralphm: strictly opaque
  815. Daniel i think there are cheap implementations where they just use a hash; and on reconnect if the hash doesn’t match anymore you just get the entire thing
  816. Ge0rG Yay.
  817. ralphm Right, and otherwise strictly increasing
  818. j.r has left
  819. Ge0rG Still, I'm sure the general problem is worth solving
  820. ralphm Yes
  821. Daniel i mean pubsub notifications having an event-id/version-id and then being able to say give me all events since version x would be nice
  822. ralphm Yes, that seems doable. Besides probably having to redesign storage in implementations. 🤣
  823. adiaholic has joined
  824. mukt2 has left
  825. mukt2 has joined
  826. wurstsalat has joined
  827. zach has left
  828. zach has joined
  829. mukt2 has left
  830. mukt2 has joined
  831. remko has left
  832. kokonoe has left
  833. kokonoe has joined
  834. zach has left
  835. zach has joined
  836. mr.fister has left
  837. mr.fister has joined
  838. remko has joined
  839. kokonoe has left
  840. arc has left
  841. arc has joined
  842. lumi has left
  843. debacle has joined
  844. j.r has joined
  845. vanitasvitae has left
  846. zach has left
  847. zach has joined
  848. vanitasvitae has joined
  849. winfried has left
  850. zach has left
  851. zach has joined
  852. APach has left
  853. gav has left
  854. jabberjocke has joined
  855. zach has left
  856. zach has joined
  857. remko has left
  858. derdaniel has joined
  859. zach has left
  860. zach has joined
  861. remko has joined
  862. adiaholic has left
  863. APach has joined
  864. derdaniel has left
  865. kokonoe has joined
  866. APach has left
  867. zach has left
  868. zach has joined
  869. kokonoe has left
  870. j.r has left
  871. j.r has joined
  872. kokonoe has joined
  873. remko has left
  874. mr.fister has left
  875. mr.fister has joined
  876. remko has joined
  877. Dele (Mobile) has left
  878. arc has left
  879. arc has joined
  880. Steve Kille has left
  881. zach has left
  882. zach has joined
  883. mukt2 has left
  884. Steve Kille has joined
  885. mukt2 has joined
  886. zach has left
  887. zach has joined
  888. kokonoe has left
  889. winfried has joined
  890. kokonoe has joined
  891. sonny has left
  892. andy has left
  893. kokonoe has left
  894. kokonoe has joined
  895. jubalh has joined
  896. zach has left
  897. zach has joined
  898. jubalh has left
  899. moparisthebest has left
  900. moparisthebest has joined
  901. jubalh has joined
  902. mukt2 has left
  903. mukt2 has joined
  904. remko has left
  905. jubalh has left
  906. mukt2 has left
  907. mukt2 has joined
  908. mimi89999 has left
  909. mimi89999 has joined
  910. mukt2 has left
  911. pep. > ralphm> It would be good to have a list of those and document how such issues are, or are not (yet?), addressed by MIX. Yes please, can we have a wiki page or something. If I ever take the time to read MIX and attempt giving feedback on it I don't want to repeat what everybody said already
  912. remko has joined
  913. Steve Kille has left
  914. pep. > moparisthebest, [..] sorry for starting mix discussion it's fine, it seems some people (not you) love to jump on the opportunity to push the subject whenever there's a slight relation (or not even) :)
  915. pep. (that alienates me as much as what Matrix making IRC people's lives harder. Even if they deserve it somehow, let's be honest :))
  916. mukt2 has joined
  917. wurstsalat has left
  918. Mikaela has left
  919. mukt2 has left
  920. Nekit has joined
  921. goffi has left
  922. Steve Kille has joined
  923. mukt2 has joined
  924. mukt2 has left
  925. Maranda has left
  926. Maranda has joined
  927. mukt2 has joined
  928. Douglas Terabyte has left
  929. mukt2 has left
  930. krauq has joined
  931. Douglas Terabyte has joined
  932. j.r has left
  933. mukt2 has joined
  934. zach has left
  935. zach has joined
  936. pdurbin has joined
  937. j.r has joined
  938. pdurbin has left
  939. matkor has left
  940. matkor has joined
  941. andrey.g has left
  942. andrey.g has joined
  943. Douglas Terabyte has left
  944. mukt2 has left
  945. Douglas Terabyte has joined
  946. Nekit has left
  947. mukt2 has joined
  948. mukt2 has left
  949. UsL has left
  950. UsL has joined
  951. mukt2 has joined
  952. Douglas Terabyte has left
  953. mukt2 has left
  954. zach has left
  955. zach has joined
  956. Steve Kille has left
  957. Steve Kille has joined
  958. mukt2 has joined