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


  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.


  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


  372. larma


  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


  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


  418. ralphm


  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


  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


  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’


  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’


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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