XSF logo 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