XSF Discussion - 2018-07-27


  1. kasper.dement has joined

  2. nyco has left

  3. lumi has left

  4. kasper.dement has joined

  5. peter has left

  6. waqas has left

  7. jjrh has left

  8. dos has left

  9. jjrh has left

  10. kasper.dement has left

  11. jjrh has left

  12. kasper.dement has joined

  13. peter has joined

  14. tux has joined

  15. rishiraj22 has left

  16. bjc has joined

  17. bjc has joined

  18. rishiraj22 has joined

  19. rishiraj22 has left

  20. rishiraj22 has joined

  21. rishiraj22 has left

  22. rishiraj22 has joined

  23. rishiraj22 has left

  24. rishiraj22 has joined

  25. waqas has joined

  26. SamWhited has left

  27. jjrh has left

  28. Lance has joined

  29. Lance has left

  30. anjan has left

  31. anjan has joined

  32. rishiraj22 has left

  33. rishiraj22 has joined

  34. Zash has left

  35. rishiraj22 has left

  36. rishiraj22 has joined

  37. rishiraj22 has left

  38. rishiraj22 has joined

  39. Zash has left

  40. Zash has joined

  41. rishiraj22 has left

  42. rishiraj22 has joined

  43. ta has joined

  44. kasper.dement has joined

  45. rishiraj22 has left

  46. rishiraj22 has joined

  47. matlag has left

  48. rishiraj22 has left

  49. winfried has joined

  50. winfried has joined

  51. rishiraj22 has left

  52. kasper.dement has joined

  53. Dave Cridland has left

  54. Dave Cridland has joined

  55. anjan has joined

  56. anjan has joined

  57. kasper.dement has left

  58. winfried has joined

  59. winfried has joined

  60. Yagiza has joined

  61. Zash has left

  62. kasper.dement has joined

  63. Yagiza has left

  64. Yagiza has joined

  65. jjrh has left

  66. Dave Cridland has left

  67. Dave Cridland has joined

  68. Dave Cridland has left

  69. Dave Cridland has joined

  70. Dave Cridland has left

  71. Dave Cridland has left

  72. kasper.dement has joined

  73. Dave Cridland has left

  74. Dave Cridland has joined

  75. Dave Cridland has left

  76. Dave Cridland has joined

  77. rishiraj22 has left

  78. kasper.dement has joined

  79. rishiraj22 has left

  80. peter has left

  81. rishiraj22 has left

  82. rishiraj22 has left

  83. kasper.dement has left

  84. kasper.dement has joined

  85. rishiraj22 has left

  86. rishiraj22 has left

  87. kasper.dement has left

  88. jere has left

  89. jere has joined

  90. ta has joined

  91. jere has left

  92. rishiraj22 has left

  93. anjan has left

  94. winfried has joined

  95. rishiraj22 has left

  96. rishiraj22 has left

  97. rishiraj22 has left

  98. kasper.dement has joined

  99. daniel has left

  100. SamWhited has left

  101. SamWhited has joined

  102. Dave Cridland has left

  103. Dave Cridland has joined

  104. daniel has joined

  105. Dave Cridland has left

  106. Dave Cridland has joined

  107. kasper.dement has left

  108. bjc has left

  109. rishiraj22 has left

  110. rishiraj22 has left

  111. rishiraj22 has joined

  112. rishiraj22 has left

  113. anjan has left

  114. rishiraj22 has joined

  115. rishiraj22 has left

  116. rishiraj22 has joined

  117. rishiraj22 has left

  118. rishiraj22 has joined

  119. Dave Cridland has left

  120. Dave Cridland has joined

  121. rishiraj22 has left

  122. rishiraj22 has joined

  123. Dave Cridland has left

  124. Dave Cridland has joined

  125. Nekit has joined

  126. kasper.dement has joined

  127. rishiraj22 has left

  128. rishiraj22 has joined

  129. rishiraj22 has left

  130. rishiraj22 has joined

  131. marmistrz has joined

  132. marmistrz has joined

  133. mrdoctorwho has joined

  134. rishiraj22 has left

  135. rishiraj22 has joined

  136. rishiraj22 has left

  137. rishiraj22 has joined

  138. bjc has joined

  139. kasper.dement has joined

  140. kasper.dement has joined

  141. rishiraj22 has left

  142. rishiraj22 has joined

  143. rishiraj22 has left

  144. rishiraj22 has joined

  145. rishiraj22 has left

  146. rishiraj22 has joined

  147. rishiraj22 has left

  148. rishiraj22 has joined

  149. rishiraj22 has left

  150. rishiraj22 has joined

  151. karp has left

  152. karp has joined

  153. anjan has joined

  154. kasper.dement has left

  155. ta has left

  156. ta has joined

  157. kasper.dement has joined

  158. goffi has joined

  159. kasper.dement has left

  160. karp has left

  161. karp has joined

  162. kasper.dement has joined

  163. edhelas has left

  164. anjan has joined

  165. edhelas has joined

  166. daniel has left

  167. daniel has joined

  168. anjan has left

  169. rishiraj22 has left

  170. rishiraj22 has joined

  171. rishiraj22 has left

  172. rishiraj22 has joined

  173. mikaela has joined

  174. rishiraj22 has left

  175. rishiraj22 has joined

  176. kasper.dement has joined

  177. marmistrz has joined

  178. kasper.dement has joined

  179. rion has joined

  180. andy has joined

  181. rishiraj22 has left

  182. rishiraj22 has joined

  183. kasper.dement has joined

  184. Valerian has joined

  185. Guus has joined

  186. Valerian has left

  187. Valerian has joined

  188. mikaela has joined

  189. Ge0rG

    Andrew Nenakhov: if your company only employs jabber fans, this is an expected outcome. If you start with a bunch of people who never before did business chat, slack is much easier than any of the alternatives, especially xmpp

  190. Dave Cridland has left

  191. Dave Cridland has joined

  192. Dave Cridland has left

  193. Dave Cridland has joined

  194. mikaela has joined

  195. jonasw

    Andrew Nenakhov, to be frank, I don’t like how you seem to do decent development, but don’t discuss with the community whenever you make such choices.

  196. jonasw

    (re 0221 vs. 0066, but also MUC etc.)

  197. jonasw

    (although muc is kinda understandable given the state MIX is in)

  198. kasper.dement has joined

  199. Tobias has left

  200. Tobias has joined

  201. jonasw has left

  202. anjan has joined

  203. Dave Cridland has left

  204. Ge0rG

    > Zulip is 100% open source software, built by a vibrant community of hundreds of developers from all around the world. With 120,000 words of developer documentation, a high quality code base, and a welcoming community, it’s easy to extend or tweak Zulip. What did they do right that we did wrong?

  205. SamWhited

    They built a service, we build a protocol.

  206. SamWhited

    We need a service to champion the protocol.

  207. Ge0rG

    Yes, but where are we going to get the "vibrant community of hundreds of developers"?

  208. SamWhited

    Same thing, I think: By building a service. Their community is building on one client and one server. We have a fragmented ecosystem where lots of devs work on lots of clients and servers.

  209. SamWhited

    That's fine, but we need some bigger ones with commercial support too.

  210. waqas

    Ge0rG: It's fairly rare for the hundreds of developers to be doing much, it's probably a handful of core contributors

  211. SamWhited

    yah, that's probably true as well

  212. kasper.dement has joined

  213. Steve Kille has left

  214. Ge0rG

    waqas: so where is the modern xmpp client with a handful of core contributors, then?

  215. waqas

    The vibrancy though, we need to learn to vibrate appropriately

  216. Ge0rG

    We could start out by making more of a buzz

  217. labdsf has left

  218. rishiraj22 has left

  219. rishiraj22 has joined

  220. la|r|ma has joined

  221. kasper.dement has joined

  222. Steve Kille has left

  223. Seve/SouL

    My phone can vibrate, if that counts.

  224. kasper.dement has joined

  225. rishiraj22 has left

  226. rishiraj22 has joined

  227. rishiraj22 has left

  228. rishiraj22 has joined

  229. kasper.dement has joined

  230. goffi

    Hi. Is there a way with OMEMO to specify xml:lang?

  231. rishiraj22 has left

  232. rishiraj22 has joined

  233. rishiraj22 has left

  234. rishiraj22 has joined

  235. lnj has joined

  236. kasper.dement has joined

  237. waqas has left

  238. rishiraj22 has left

  239. rishiraj22 has joined

  240. lnj has left

  241. lnj has joined

  242. ThibG has left

  243. ThibG has joined

  244. mimi89999 has left

  245. kasper.dement has joined

  246. Zash has joined

  247. Chobbes has joined

  248. Chobbes has joined

  249. jonasw

    re vibration: https://www.youtube.com/watch?v=JWAAbmps_Zs

  250. kasper.dement has joined

  251. Steve Kille has joined

  252. Dave Cridland has left

  253. Dave Cridland has joined

  254. Dave Cridland has left

  255. Dave Cridland has joined

  256. Dave Cridland has left

  257. Dave Cridland has joined

  258. Dave Cridland has left

  259. Dave Cridland has joined

  260. Guus has left

  261. Guus has joined

  262. goffi has left

  263. goffi has joined

  264. anjan has left

  265. anjan has joined

  266. kasper.dement has joined

  267. anjan has joined

  268. anjan has joined

  269. rishiraj22 has left

  270. rishiraj22 has joined

  271. rishiraj22 has left

  272. Zash has left

  273. kasper.dement has left

  274. Dave Cridland has left

  275. rishiraj22 has joined

  276. Ge0rG has left

  277. Andrew Nenakhov

    jonasw, to me it seems that coding > discussing. No point to argue how to do something until we have a working prototype. If there are competing prototypes, community might stick to the one that is better, the other ones will die out by themselves. As is the case with MIX, creating a protocol without implementation might be a perpetual affair.

  278. goffi has left

  279. Alex has joined

  280. MattJ

    I think there is a balance to be struck between the two

  281. MattJ

    "Rough conensus and running code" is a decent mantra in that regard

  282. rishiraj22 has left

  283. rishiraj22 has joined

  284. jonasw

    Andrew Nenakhov, fair enough. this wasn’t necessarily meant as an accusation by the way, although I can see that it may read that way. I think this might also be a symptom of the issue that we have way too many ways to do the same thing.

  285. MattJ

    e.g. I looked at MUC Sub recently, and it definitely suffers from code-first problems, a number of things are not specified adequately, or at all

  286. Andrew Nenakhov

    > Same thing, I think: By building a service. Their community is building on one client and one server. We have a fragmented ecosystem where lots of devs work on lots of clients and servers. Currently what we're trying to do is to build server AND clients for all major platforms, so they simultaneously support new features and do it so that all clients have a similar look and feel

  287. jonasw

    Andrew Nenakhov, for example, any reason why you’re not using XEP-0385, which seems like a more natural choice for transmitting that type of stuff?

  288. daniel has left

  289. Andrew Nenakhov

    Because it has a way too big number and wit myriad of xeps it's hard to read up to that point.

  290. daniel has joined

  291. Andrew Nenakhov

    And it looks kinda vague

  292. rishiraj22 has left

  293. Andrew Nenakhov

    :)

  294. rishiraj22 has joined

  295. jonasw

    uh, I haven’t read all XEPs up to that. I follow more of a mix&match approach ;-)

  296. rishiraj22 has left

  297. rishiraj22 has joined

  298. Zash has joined

  299. rishiraj22 has left

  300. rishiraj22 has joined

  301. jonasw

    what is appealing about 0385 to me is that it has a well-defined way to share multiple sources for the data (like XEP-0221) has, it is reasonably simple to implement, and it allows to provide metadata like file size, mime type and dimensions

  302. Andrew Nenakhov

    We slightly extended 0221 for exactly that.

  303. jonasw

    meh

  304. Dave Cridland has left

  305. jonasw

    why not use something which already exists instead of modifying something else which ~nobody else uses?

  306. Andrew Nenakhov

    https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f16a0abdf3f7ff84d/sHmWWFaYLaa0hl29XM0iYHhDMe07ouSq3B0jrZF6/IMG_20140212_165807.jpg https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f16a0abdf3f7ff84d/AccuS9gfadNqhr46nO3c6JokNJQ85sM3ZMmoSSfn/Screenshot_20180727-031120.png https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f16a0abdf3f7ff84d/Hmg5tqjf5dxZOYWngVKfMEmnhgkYOP55kkb96iqh/IMG_20140212_165719.jpg https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f16a0abdf3f7ff84d/V1e5V9S2fBwTzTEGPi08gkLMbcuLDsQC4jypTxc0/4b92c4f3-2cd6-4a75-ae43-cb1abc98ddf2.jpg

  307. Andrew Nenakhov

    Here are 4 files. All with sizes, dimensions, file types, etc

  308. Dave Cridland has left

  309. rishiraj22 has left

  310. rishiraj22 has joined

  311. kasper.dement has joined

  312. Andrew Nenakhov

    jonasw, because no one generally uses xmpp at all. So being compatible with some obsolete clients that are a long time abandoned is futile.

  313. jonasw

    Andrew Nenakhov, there are actively developed clients outside of redsolution.

  314. Andrew Nenakhov

    We have a clear picture of the paying audience we plan to reach. They'll be happy to use our clients exclusively. If we succeed, our approach will be standard. If we fail, well, other clients approach will win.

  315. rishiraj22 has left

  316. rishiraj22 has joined

  317. Dave Cridland has left

  318. Ge0rG

    Andrew Nenakhov: your approach will not be "standard", it will be a silo.

  319. jonasw

    I expect it more to end up like whatsapp with no compatibility to other clients at all, yet another XMPP fork.

  320. Ge0rG

    or slack.

  321. Ge0rG

    or any other cloud-based chat offering with a half life of five years.

  322. labdsf has joined

  323. Andrew Nenakhov

    Ge0rG, > Andrew Nenakhov: your approach will not be "standard", it will be a silo. X in XMPP stands for extensible. It seems to me that we understand Extensibility differently. If our approach succeeds with users, we'll suggest updating the standard. And we do everything with providing compatibility, not breaking anything anyway.

  324. Ge0rG

    Andrew Nenakhov: what MattJ said. "rough consensus and working code". Without consensus from the community, your code will end up in a dead end

  325. Ge0rG

    Andrew Nenakhov: I can understand your position from a business point of view, but I'm not yet sure it will actually benefit the XMPP community

  326. jonasw

    Andrew Nenakhov, while you figure out your business model and acquire customers, the community is doing its own development. then we end up with two strains of XMPP, one of which in your company which isn’t written down in standards, and one used by the community actually written down in the XEPs.

  327. jonasw

    I doubt that modifications to the XEPs which replicate things the community already has figured out in a more consensual way would be accepted

  328. MattJ

    I think it's also not taking advantage of community expertise that exists

  329. jonasw

    that, too

  330. Andrew Nenakhov

    What exactly things do we replicate?

  331. jonasw

    Andrew Nenakhov, the use of XEP-0221 over XEP-0385 is a good example

  332. jonasw

    but also the multi-user-chat discussion.

  333. Andrew Nenakhov

    Why did community develop unnecessary standard instead of slightly updating 0221?

  334. jonasw

    because data forms are---to me at least, but I think others may agree---not primarily a way to share (meta-)data but for interactive things. '221 was written with captchas in mind. '385 was specifically written with file sharing in mind, and I think it achieves that much better. There’s no way to annotate individual URLs in a <body/> using '221. '385 re-uses references for taht.

  335. Andrew Nenakhov

    And with mix, I'm probably one of the few who mostly read it along with my dev team. It's broken by design. And we already have a working group chat that works great, it's fast and reliable. Maybe 30% work left on server side.

  336. jonasw

    (but this is just waht I assume, '385 happenend before I was around here)

  337. Ge0rG

    Let's not talk about MIX

  338. Andrew Nenakhov

    Ok. )

  339. tux has joined

  340. jonasw

    I understand your point about code-first, standards-second, but I don’t see how a quick "Hey, we’re going to do file sharing with metadata and plan to use '221 for that, any reasons we shouldn’t?" email would’ve hurt anyone.

  341. jonasw

    I think you would have gotten a clear response that building on '385 (I’m not saying that '385 is perfect, it can certainly use some love) would be preferrable.

  342. Alex has left

  343. Alex has joined

  344. Andrew Nenakhov

    You see. I respect you guys who do stuff . And I like the idea of federated messaging. I firmly believe humanity needs an independent protocol to exchange messages. That's why I'm using my time, money and attract investors to fund our efforts in this space. However, xmpp is already older than one of my developers who joined the team yesterday. If in all these years doing things like it's done xmpp didn't reach even a fraction of WhatsApp success, did it occur to you that things should be done differently? At least, tried to be done differently?

  345. jonasw

    I see your point, however, going the same way WhatsApp (originally XMPP based, too) went by forking the protocol and ignoring the community won’t help here.

  346. Andrew Nenakhov

    jonasw, ok I'll write an email on 221 use. We actually considered 385 and rejected it, I'll explain why.

  347. jonasw

    that’d be great

  348. jonasw

    Looking forward to see why you came to the conclusion that modifying '221 was a better way forward than modifying '385.

  349. Ge0rG

    Andrew Nenakhov: we are building a protocol, not a product. You can't attract users with a protocol ;)

  350. lnj has left

  351. Andrew Nenakhov

    jonasw, we are not going the exact WhatsApp way. If we do stuff we'll publish protocol extensions and release open source products that support them.

  352. jonasw

    (especially given that '385 is Experimental and thus has a much lower barrier to modification than '221 has)

  353. kasper.dement has joined

  354. Dave Cridland has left

  355. Dave Cridland has left

  356. Holger has left

  357. ThibG has left

  358. ThibG has joined

  359. kasper.dement has left

  360. lskdjf has joined

  361. pep. has joined

  362. rion has left

  363. Andrew Nenakhov

    Btw I'm still not over how xhtml XEP was made deprecated.

  364. kasper.dement has joined

  365. Seve/SouL smiles.

  366. jonasw

    I’m still not certain on that one either.

  367. jonasw

    I’m swaying between "it’s not *that* hard to get it right, even if done by simply disallowing all CSS" and "ugh. XHTML brings us a horde of security issues"

  368. Guus has left

  369. Guus has joined

  370. efrit has left

  371. labdsf has left

  372. rishiraj22 has left

  373. la|r|ma has joined

  374. rishiraj22 has left

  375. la|r|ma has joined

  376. kasper.dement has joined

  377. Link Mauve

    Disallowing all CSS isn’t even a good solution, the subset defined in 0071 is known to not have any vulnerability on current browsers.

  378. jonasw

    Link Mauve, sure, but it’s not trivial to properly sanitise CSS

  379. jonasw

    which is why a simple implementation may choose to ignore it altogether.

  380. jonasw

    also, you’d want to modify any colors used to blend in with your UI.

  381. Link Mauve

    Maybe I should split out xmpp-parsers’s XHTML handling into another crate, and provide bindings and compilation targets for a bunch of other languages.

  382. Andrew Nenakhov has joined

  383. Link Mauve

    jonasw, sure, and you can.

  384. jonasw

    yes, but it’s work

  385. jonasw

    work which can be gotten wrong

  386. jonasw

    and which can lead to interesting issues when gotten wrong

  387. jonasw

    although CSS will most likely only cause tracking since javascript URLs have been forbidden there. although I wouldn’t put my money on that one.

  388. rishiraj22 has left

  389. Andrew Nenakhov has left

  390. Andrew Nenakhov has joined

  391. Valerian has left

  392. kasper.dement has joined

  393. mimi89999 has joined

  394. muppeth has joined

  395. anjan has joined

  396. la|r|ma has left

  397. Dave Cridland has left

  398. muppeth has joined

  399. lnj has joined

  400. andrey.g has left

  401. labdsf has joined

  402. Dave Cridland has left

  403. kasper.dement has joined

  404. mrdoctorwho has joined

  405. mrdoctorwho has joined

  406. mrdoctorwho has joined

  407. mrdoctorwho has joined

  408. lumi has joined

  409. kasper.dement has joined

  410. mrdoctorwho has left

  411. mrdoctorwho has joined

  412. Ge0rG

    > As the team chat market is overcrowded by copycats, Nayego is different. Said yet another xmpp client developer.

  413. Seve/SouL

    Someone from the XMPP community was involved in it, is it?

  414. Ge0rG

    I'd say nyco

  415. goffi has joined

  416. Dave Cridland

    Ge0rG, Team chat market isn't as crowded as it was yeterday, mind.

  417. Ge0rG

    Dave Cridland: it's crowded by the bodies of those who tried and zombies of those who don't want to realize that they failed.

  418. Dave Cridland

    Ge0rG, Yeah, I was making a nod toward Stride/Hipchat/Jitsi.

  419. Ge0rG

    Oh, I didn't know Jitsi was Atlassian as well. Is it also EOL now?

  420. Dave Cridland

    Jitsi was part of HipChat's business unit. The code was incorporated into Stride. Slack, OTOH, use a modified Janus SFU and things - I can't see they'd use much from it.

  421. Ge0rG

    Will they make use of the team?

  422. Dave Cridland

    I wouldn't know.

  423. Dave Cridland

    I've not examined the details of the transfer, but I believe it's a sale of customers basically.

  424. Ge0rG

    Except it's not providing customers with a clean migration path, except "install slack, kill your old chat".

  425. Dave Cridland

    Basically.

  426. jubalh has joined

  427. Dave Cridland

    And honouring contracts, of course, though they were priced more or less identically.

  428. Ge0rG

    I suppose this merger will make few people happy and many people sad, for a variety of reasons.

  429. kasper.dement has joined

  430. Guus has left

  431. goffi has left

  432. Andrew Nenakhov has left

  433. goffi has joined

  434. Valerian has joined

  435. valo has left

  436. valo has joined

  437. Valerian has left

  438. Valerian has joined

  439. Andrew Nenakhov has joined

  440. Valerian has left

  441. 404.city has joined

  442. Ge0rG has left

  443. Andrew Nenakhov has left

  444. alacer has joined

  445. muppeth has joined

  446. jubalh has left

  447. muppeth has joined

  448. rishiraj22 has left

  449. labdsf has left

  450. mimi89999 has left

  451. labdsf has joined

  452. mimi89999 has left

  453. mimi89999 has left

  454. Andrew Nenakhov has joined

  455. nyco has left

  456. ThibG has joined

  457. jubalh has joined

  458. blabla has left

  459. rishiraj22 has left

  460. Andrew Nenakhov has left

  461. Andrew Nenakhov has joined

  462. Alex

    https://www.atlassian.com/blog/announcements/new-atlassian-slack-partnership

  463. Alex

    :'-(

  464. blabla has joined

  465. lnj has left

  466. lnj has joined

  467. Dave Cridland

    Alex, Indeed. Nothing on Jitsi, mind, but that's part of the same business unit.

  468. marc has joined

  469. Zash has left

  470. kasper.dement has joined

  471. Andrew Nenakhov has left

  472. Dave Cridland has left

  473. Andrew Nenakhov has joined

  474. Andrew Nenakhov has joined

  475. Andrew Nenakhov has joined

  476. Andrew Nenakhov has left

  477. Andrew Nenakhov has joined

  478. andrey.g has joined

  479. kasper.dement has joined

  480. rishiraj22 has left

  481. lnj has left

  482. lnj has joined

  483. Valerian has joined

  484. Valerian has left

  485. Valerian has joined

  486. rishiraj22 has left

  487. xnyhps has left

  488. xnyhps has joined

  489. jere has joined

  490. Zash has left

  491. alacer has left

  492. alacer has joined

  493. Valerian has left

  494. Valerian has joined

  495. kasper.dement has joined

  496. rishiraj22 has left

  497. kasper.dement has joined

  498. Valerian has left

  499. lovetox has joined

  500. blabla has left

  501. alacer has left

  502. muppeth has left

  503. muppeth has joined

  504. winfried has joined

  505. winfried has joined

  506. lnj has left

  507. kasper.dement has joined

  508. tux has joined

  509. kasper.dement has joined

  510. lnj has joined

  511. j.r has joined

  512. kasper.dement has left

  513. muppeth has joined

  514. muppeth has joined

  515. kasper.dement has joined

  516. winfried has joined

  517. winfried has joined

  518. rishiraj22 has left

  519. rishiraj22 has left

  520. muppeth has left

  521. muppeth has joined

  522. dos has joined

  523. lnj has left

  524. rishiraj22 has left

  525. rishiraj22 has left

  526. lnj has joined

  527. rishiraj22 has left

  528. lnj has left

  529. rishiraj22 has left

  530. lnj has joined

  531. efrit has joined

  532. rishiraj22 has left

  533. rishiraj22 has left

  534. efrit has left

  535. efrit has joined

  536. j.r has joined

  537. rishiraj22 has left

  538. jubalh has joined

  539. rishiraj22 has left

  540. ta has joined

  541. efrit has left

  542. efrit has joined

  543. rishiraj22 has left

  544. daniel has left

  545. daniel has joined

  546. tux has left

  547. blabla has left

  548. blabla has left

  549. lnj has left

  550. rishiraj22 has left

  551. blabla has joined

  552. ta has left

  553. rishiraj22 has left

  554. rishiraj22 has left

  555. Andrew Nenakhov has left

  556. Andrew Nenakhov has joined

  557. andrey.g has left

  558. Andrew Nenakhov has left

  559. Andrew Nenakhov has joined

  560. Andrew Nenakhov has left

  561. Andrew Nenakhov has joined

  562. Andrew Nenakhov has left

  563. Andrew Nenakhov has joined

  564. rishiraj22 has left

  565. efrit has left

  566. marc has left

  567. andrey.g has joined

  568. rishiraj22 has left

  569. andy has left

  570. nyco has left

  571. marc has joined

  572. mimi89999 has joined

  573. kasper.dement has joined

  574. rishiraj22 has left

  575. kasper.dement has joined

  576. rishiraj22 has left

  577. jubalh has joined

  578. jubalh has left

  579. rishiraj22 has left

  580. pep. has left

  581. rishiraj22 has left

  582. rishiraj22 has left

  583. lnj has joined

  584. muppeth has joined

  585. mimi89999 has joined

  586. muppeth has joined

  587. rishiraj22 has left

  588. kasper.dement has joined

  589. labdsf has left

  590. rishiraj22 has left

  591. rishiraj22 has left

  592. xnyhps has joined

  593. rishiraj22 has left

  594. jonasw

    goffi, could you make a PR against '384 regarding the singleton implementation note?

  595. Zash

    There's a thing

  596. jonasw

    Zash, that thing? https://xmpp.org/extensions/xep-0060.html#impl-singleton

  597. Zash

    https://xmpp.org/extensions/xep-0060.html#impl-singleton > When this pattern is desired, it is RECOMMENDED for the publisher to specify an ItemID of "current" to ensure that the publication of a new item will overwrite the existing item.

  598. jonasw

    that’s what I’m talking about

  599. kasper.dement has joined

  600. Zash

    jonasw: Yes. That thing.

  601. goffi

    jonasw: OK I can check that, will do it later this week-end.

  602. jonasw

    goffi, thx!

  603. mimi89999 has joined

  604. xnyhps has joined

  605. la|r|ma has joined

  606. la|r|ma has joined

  607. rishiraj22 has left

  608. labdsf has joined

  609. lskdjf has joined

  610. kasper.dement has joined

  611. waqas has joined

  612. rishiraj22 has left

  613. blabla has left

  614. blabla has joined

  615. kasper.dement has joined

  616. kasper.dement has left

  617. kasper.dement has joined

  618. waqas has left

  619. jonasw has left

  620. goffi has left

  621. rishiraj22 has left

  622. kasper.dement has joined

  623. rishiraj22 has left

  624. waqas has joined

  625. dos has left

  626. dos has joined

  627. rishiraj22 has left

  628. rishiraj22 has left

  629. intosi has left

  630. intosi has joined

  631. intosi has left

  632. Holger has left

  633. kasper.dement has joined

  634. ta has joined

  635. moparisthebest has joined

  636. Dave Cridland has left

  637. peter has joined

  638. moparisthebest has left

  639. 404.city has left

  640. Andrew Nenakhov has left

  641. Andrew Nenakhov has joined

  642. Andrew Nenakhov has left

  643. kasper.dement has joined

  644. Andrew Nenakhov has joined

  645. la|r|ma has joined

  646. Andrew Nenakhov has left

  647. Andrew Nenakhov has joined

  648. kasper.dement has joined

  649. Dave Cridland has left

  650. 404.city has joined

  651. Dave Cridland has left

  652. Dave Cridland has left

  653. rishiraj22 has left

  654. Andrew Nenakhov has left

  655. Andrew Nenakhov has joined

  656. Dave Cridland has left

  657. Dave Cridland has left

  658. Andrew Nenakhov has left

  659. Andrew Nenakhov has joined

  660. lskdjf has left

  661. rishiraj22 has left

  662. Andrew Nenakhov has left

  663. Andrew Nenakhov has joined

  664. xnyhps has joined

  665. labdsf has left

  666. labdsf has joined

  667. xnyhps has joined

  668. lskdjf has left

  669. lskdjf has joined

  670. Steve Kille has left

  671. Steve Kille has left

  672. Alex has left

  673. ta has joined

  674. lskdjf has joined

  675. Steve Kille has joined

  676. Dave Cridland has left

  677. kasper.dement has joined

  678. Holger has left

  679. goffi has joined

  680. rishiraj22 has left

  681. kasper.dement has joined

  682. lumi has left

  683. Steve Kille has left

  684. Guus has joined

  685. lskdjf has joined

  686. lskdjf has left

  687. Guus

    With regards to CSI, does RFC6120#section-10.1 forbid the queuing of some stanzas, while letting other ones through?

  688. karp has left

  689. lskdjf has left

  690. karp has joined

  691. kasper.dement has joined

  692. kasper.dement has joined

  693. Holger

    I've been told it's fine to break RFC rules if the XEP allows it.

  694. Guus

    That's ... Surprising

  695. Guus

    And feels wrong

  696. goffi has left

  697. Holger

    The rationale was that the rule breakage is negotiated and hence won't lead to trouble.

  698. Holger

    The problem I see is implementation-wise. If you encoded those rules in the lower layers, you must change those layers to implement an extension.

  699. Guus

    At best, I feel that that should be worded better in the XEP.

  700. Guus

    It now appears to describe that you should be compliant with section 10.1

  701. Guus

    MattJ, thoughs?

  702. Guus

    (penny for your)

  703. Andrew Nenakhov has left

  704. Andrew Nenakhov has joined

  705. MattJ

    My thoughts are that the XEP does not give any mandate to break the RFC

  706. kasper.dement has joined

  707. MattJ

    In-order processing is relied upon in multiple edge cases

  708. MattJ

    The CSI XEP originally, very intentionally, avoided saying anything about what a server might do with its knowledge of the client state

  709. Zash

    And then some got annoyed because they couldn't be sure what the server would do.

  710. goffi has joined

  711. MattJ

    Right, so community consensus seemed to be that it should at least provide a list of example behaviours

  712. Guus

    So you feel that you cannot withold say a status update from a client when you push it a message that was sent to it later?

  713. MattJ

    I don't, no

  714. Holger

    > The CSI XEP originally, very intentionally, avoided saying anything about what a server might do with its knowledge of the client state The problem I see with that is that the client can't rely on anything once sending <inactive/>.

  715. Guus

    And would it be ok to withold from Alice a status update sent from Bob, when Bob later sends a message to Jacky?

  716. muppeth has joined

  717. kasper.dement has joined

  718. MattJ

    Guus, I think it's a little safer between two distinct (bare?) JIDs

  719. MattJ

    Holger, I don't see a problem with that

  720. Dave Cridland has left

  721. Guus

    Sure, but it either does or doesn't break spec.

  722. Bunneh has left

  723. MattJ

    Holger, the CSI XEP was never intended to have any observable effect to the client, at a high level

  724. Bunneh has joined

  725. MattJ

    Guus, CSI does not break the RFC

  726. MattJ

    CSI is a way for the client to say whether it is "active" or not, it's very simple

  727. Guus

    The withold bit in my example, I mean

  728. MattJ

    As far as I'm concerned, what servers do with this info is up to them

  729. MattJ

    and not standardised

  730. MattJ

    and neither should be, without very careful consideration

  731. MattJ

    As far as I'm concerned, if the server breaks the client by messing around with the stream, the server is broken

  732. MattJ

    Maybe someone feels like making a standard for this, possibly with an opt-in for the client, they are free to

  733. karp has left

  734. karp has joined

  735. lumi has joined

  736. Guus

    So, as far as queuing goes, a CSI based optimization should not queue anything when sending something else to the same bare jid?

  737. Holger

    MattJ: Server implementors would have to anticipate all possible use cases to judge whether a given optimization is 'safe', i.e. "has no observable effect".

  738. karp has left

  739. karp has joined

  740. rishiraj22 has left

  741. Yagiza has left

  742. alacer has joined

  743. Holger

    > So, as far as queuing goes, a CSI based optimization should not queue anything when sending something else to the same bare jid? In ejabberd, if I send you a message, I send all queued traffic from the same sender first. (Not sure why I don't just flush the queue in that case, the radio is woken anyway.)

  744. kasper.dement has joined

  745. Guus

    From the same sender?

  746. lnj has left

  747. Guus

    I'd think you'd flush all data to the same recipient. Possibly all its full jids?

  748. Valerian has joined

  749. Valerian has left

  750. Holger

    Yeah, that's the part I'm not sure makes sense 🙂 (It's been a while and I recently thought about just flushing the queue whenever I send traffic.)

  751. Zash

    The thing I personally use has a single queue, that gets flushed when it's "full" or when there's something "important". The original order is preserved.

  752. labdsf has left

  753. Holger

    Guus: Right now if I send you a message from=alice, I only flush all stanzas that were sent from=alice.

  754. Guus

    Zash: I'm leaning towards something like that now too.

  755. MattJ

    Yes, I'm planning to include the single-queue one in the next Prosody release

  756. Guus

    Holger: that's weird to me, as a message from Bob that was sent to the same recipient might arrive out of order.

  757. MattJ

    The others are just too risky, but people can use them if they want (from prosody-modules) (and they do)

  758. MattJ

    Despite no tests as to how effective any of these methods are on real traffic

  759. Holger

    Apart from that I try to dedup "state" things (presence, chat states, PEP), i.e. you only receive the current state. Mainly to avoid frequent queue flushes due to the queue size limit being exceeded.

  760. Zash

    Guus: The Mobile Optimizations XEP (or whatsitcalled, by Dave Cridland) basically says that too, "send a lot while the radio is hot"

  761. vanitasvitae has left

  762. Guus

    Zash: makes sense

  763. jjrh has left

  764. Dave Cridland has left

  765. Holger

    Guus: Yes queued traffic can go out of order that way. I.e. Alice sent presence before Bob, then Bob sent a message, so you receive Bob's presence before Alice's. This stuff can be hairy with MUC joins, for example. Just don't do this 🙂

  766. Dave Cridland has left

  767. Zash

    Holger: As I've said before, the rules for things like that quickly grow complicated

  768. Guus

    I'm now wondering if I should stop CSI support with dropping chat state notifications and the like only...

  769. Holger

    Yes. But you might consider the complexity with it to avoid frequent queue flushes.

  770. Valerian has joined

  771. Guus

    And not have a queue at all

  772. Holger

    *worth it

  773. MattJ

    Dropping chat states -> never drop "active", never drop if there is any other payload in the message (that isn't recognised as safe to drop)

  774. kasper.dement has joined

  775. MattJ

    Is that the only required logic?

  776. Guus

    Why not 'active' if there's no other payload?

  777. MattJ

    Because then someone could be typing, and then stop typing while I was inactive

  778. MattJ

    and then they would be forever typing

  779. MattJ

    in my client

  780. Guus

    I now have "drop messages that have no other child elements that do define a namespace, other than chatstates"

  781. Dave Cridland has left

  782. MattJ

    So you would have the perpetual typing issue?

  783. Guus

    Yeah, I didn't think of that

  784. Zash

    Isn't what Holger says to keep the last one?

  785. Zash

    That makes sense

  786. Zash

    Like that module that does that for presence already

  787. Guus

    But, really, only dropping chatstates, really doesn't make a dent in the traffic

  788. Dave Cridland has left

  789. Guus

    Zash: yeah, but that'd involve queuing which I think either is flushed all the time (rendering CSI effectless) or break RFC mandated ordering

  790. Zash

    I do think trying to group stuff into batches is better than trying to drop things

  791. Zash

    If we bring back Compression-except-safe, then it should be possible to squeeze in all them chatstates without using much data

  792. Valerian has left

  793. Valerian has joined

  794. dos has left

  795. mrdoctorwho has left

  796. Guus

    Meh, this all is a bit disappointing. I kinda hoped for a silver bullet.

  797. Dave Cridland has left

  798. MattJ

    Don't we all? :)

  799. MattJ

    But when was the last time anyone measured XMPP client traffic or battery usage?

  800. Guus

    Sooooo.... Would things be more effective if we explicitly let the client tell the server for what kind of data it allows the server to break the delivery order requirement?

  801. karp has left

  802. karp has joined

  803. lskdjf has left

  804. MattJ

    I don't think that's a nice thing to do to client devs

  805. Guus

    "only send me the last non subscription presence update for each contact that changed state after I went inactive"

  806. MattJ

    Complex protocol for something where basically everyone will want the same rules

  807. Guus

    Well, without that, they don't get any benefit from CSI.

  808. MattJ

    Just the rules aren't easy to describe or discover

  809. MattJ

    Single queue has benefit

  810. MattJ

    In theory

  811. Kev

    I'm not reading up for all the context, but ...

  812. Kev

    Is there any way we can get rid of CSI and instead disconnect when in the background and then get our reconnects to a sensible speed?

  813. moparisthebest has joined

  814. MattJ

    I'm not sure how different that is in the end

  815. MattJ

    E.g. if the server optimizes the 198 queue with the same rules

  816. kasper.dement has joined

  817. Kev

    I don't know. I just can't shake the feeling that both CSI and 198 Resumption are trying to work around a fundamental problem rather than address it.

  818. Guus

    Well, without SM you'd not show as online

  819. MattJ

    What if they are addressing it?

  820. karp has left

  821. karp has joined

  822. Guus

    Sorry, "available"

  823. Kev

    The issue being that getting current state is slow unless you were online when it changed, so we're trying to avoid going offline, with 198 letting us resume, and CSI letting us cut down the cost of being online.

  824. Kev

    But if we could solve the fundamental "It's expensive to catch up" issue, neither would be needed.

  825. blabla has left

  826. Guus

    Kev: there's truth in that. Unsure if it's sufficiently feasible.

  827. Zash

    I think there's value in staying connected

  828. Yagiza has joined

  829. Kev

    If it's not feasible I think we end up with significant issues anyway, because at some point you're going to need to fire up a new client, or an old one will get disconnected beyond 198 periods, or whatever.

  830. Kev

    It feels to me like we should look at what we really want to do on login (rather than what current protocol dictates we do), and see how close to that we can get.

  831. lnj has joined

  832. marmistrz has joined

  833. kasper.dement has joined

  834. alacer has left

  835. blabla has joined

  836. ta has left

  837. ta has joined

  838. jubalh has joined

  839. karp has left

  840. karp has joined

  841. kasper.dement has left

  842. Dave Cridland has left

  843. Dave Cridland has left

  844. Dave Cridland has left

  845. Dave Cridland has left

  846. Dave Cridland has left

  847. karp has left

  848. karp has joined

  849. Dave Cridland has left

  850. Dave Cridland has left

  851. rishiraj22 has left

  852. 404.city has left

  853. marmistrz has joined

  854. marmistrz has joined

  855. tux has joined

  856. pep. has left

  857. karp has left

  858. karp has joined

  859. karp has left

  860. karp has joined

  861. rishiraj22 has left

  862. kasper.dement has joined

  863. winfried has joined

  864. rishiraj22 has left

  865. rishiraj22 has left

  866. jjrh has left

  867. rishiraj22 has left

  868. rishiraj22 has joined

  869. jjrh has left

  870. valo has joined

  871. jjrh has left

  872. rishiraj22 has left

  873. rishiraj22 has joined

  874. karp has left

  875. karp has joined

  876. SamWhited has left

  877. rishiraj22 has left

  878. rishiraj22 has joined

  879. kasper.dement has joined

  880. mikaela has joined

  881. lskdjf has left

  882. peter has left

  883. winfried has joined

  884. jjrh has left

  885. Guus has left

  886. labdsf has joined

  887. Dave Cridland has left

  888. jere has left

  889. jere has joined

  890. kasper.dement has joined

  891. karp has left

  892. karp has joined

  893. kasper.dement has left

  894. lskdjf has joined

  895. kasper.dement has joined

  896. kasper.dement has left

  897. kasper.dement has joined

  898. Valerian has left

  899. Valerian has joined

  900. labdsf has left

  901. Valerian has left

  902. karp has left

  903. karp has joined

  904. Valerian has joined

  905. Dave Cridland has left

  906. Dave Cridland has left

  907. 404.city has joined

  908. labdsf has joined

  909. kasper.dement has left

  910. nyco has left

  911. muppeth has joined

  912. muppeth has joined

  913. moparisthebest has left

  914. Valerian has left

  915. Chobbes has joined

  916. karp has left

  917. karp has joined

  918. Dave Cridland has left

  919. muppeth has joined

  920. dos has joined

  921. karp has left

  922. karp has joined

  923. muppeth has joined

  924. SamWhited has left

  925. SamWhited has joined

  926. lumi has left

  927. la|r|ma has left

  928. la|r|ma has joined

  929. lskdjf has left

  930. j.r has joined

  931. ta has left

  932. ta has joined

  933. labdsf has left

  934. rishiraj22 has left

  935. rishiraj22 has joined

  936. karp has left

  937. karp has joined

  938. j.r has joined

  939. j.r has joined

  940. rishiraj22 has left

  941. rishiraj22 has joined

  942. intosi has joined

  943. kasper.dement has joined

  944. karp has left

  945. rishiraj22 has left

  946. rishiraj22 has joined

  947. kasper.dement has left

  948. ralphm has joined

  949. ralphm has left

  950. ralphm has joined

  951. ralphm has joined

  952. ralphm has joined

  953. intosi has left

  954. ralphm has left

  955. goffi has left

  956. Guus has joined

  957. labdsf has joined

  958. karp has joined

  959. Guus has left

  960. alacer has joined

  961. Lance has joined

  962. j.r has joined

  963. karp has left

  964. karp has joined

  965. karp has left

  966. karp has joined

  967. jubalh has left

  968. Dave Cridland has left

  969. Dave Cridland has joined

  970. Dave Cridland has left

  971. Yagiza has left

  972. Dave Cridland has joined

  973. Dave Cridland has left

  974. Dave Cridland has joined

  975. Dave Cridland has left

  976. Dave Cridland has joined

  977. mikaela has left

  978. ralphm has joined

  979. waqas has left

  980. labdsf has left

  981. Guus has joined

  982. rishiraj22 has left

  983. rishiraj22 has joined

  984. Guus has left

  985. Syndace has joined

  986. Syndace has joined

  987. labdsf has joined

  988. rishiraj22 has left

  989. rishiraj22 has joined

  990. Guus has joined

  991. Guus has left

  992. Guus has joined

  993. Guus has left

  994. lskdjf has left

  995. lskdjf has joined

  996. blabla has left

  997. blabla has joined

  998. ralphm has left

  999. ralphm has joined

  1000. karp has left

  1001. karp has joined

  1002. jubalh has joined

  1003. MattJ has joined

  1004. Chobbes has joined

  1005. karp has left

  1006. karp has joined

  1007. karp has left

  1008. karp has joined

  1009. SamWhited has left

  1010. SamWhited has joined

  1011. karp has left

  1012. karp has joined

  1013. karp has left

  1014. karp has joined

  1015. marc has left

  1016. bjc has joined

  1017. Dave Cridland has left

  1018. Nekit has joined

  1019. Dave Cridland has joined

  1020. karp has left

  1021. karp has joined

  1022. karp has left

  1023. karp has joined

  1024. karp has left

  1025. karp has joined

  1026. rishiraj22 has left

  1027. rishiraj22 has joined

  1028. anjan has joined

  1029. ta has joined

  1030. anjan has joined

  1031. anjan has joined

  1032. moparisthebest has joined

  1033. Lance has left

  1034. bjc has joined

  1035. dos has left

  1036. lskdjf has joined

  1037. moparisthebest has joined

  1038. anjan has left

  1039. anjan has joined

  1040. marc has left

  1041. rishiraj22 has left

  1042. rishiraj22 has joined

  1043. 404.city has left

  1044. Lance has joined