XSF Discussion - 2020-01-07

  1. Daniel has joined
  2. mukt2 has left
  3. mukt2 has joined
  4. Daniel has left
  5. Daniel has joined
  6. Douglas Terabyte has left
  7. Douglas Terabyte has joined
  8. mukt2 has left
  9. mukt2 has joined
  10. moparisthebest has left
  11. stpeter has left
  12. Kev has joined
  13. wurstsalat has left
  14. mukt2 has left
  15. Dele (Mobile) has joined
  16. Dele (Mobile) has left
  17. Dele (Mobile) has joined
  18. moparisthebest has joined
  19. Dele (Mobile) has left
  20. Dele (Mobile) has joined
  21. mukt2 has joined
  22. Dele (Mobile) has left
  23. emus has left
  24. Dele (Mobile) has joined
  25. Dele (Mobile) has left
  26. mukt2 has left
  27. pdurbin has joined
  28. mukt2 has joined
  29. mukt2 has left
  30. mukt2 has joined
  31. moparisthebest dwd: good article
  32. moparisthebest And on that topic, it's about time, does anyone know if anyone has started XMPP over QUIC work yet?
  33. pdurbin has left
  34. moparisthebest It handles switching networks itself, so in theory we wouldn't even need stream management anymore
  35. waqas dwd: Is the image under "High Latency" intended to be a gif of a spinning circle?
  36. stpeter has joined
  37. stpeter has left
  38. stpeter has joined
  39. mr.fister has left
  40. beta has left
  41. beta has joined
  42. winfried has left
  43. winfried has joined
  44. winfried has left
  45. winfried has joined
  46. winfried has left
  47. winfried has joined
  48. mukt2 has left
  49. mukt2 has joined
  50. beta has left
  51. mukt2 has left
  52. mukt2 has joined
  53. beta has joined
  54. mukt2 has left
  55. mukt2 has joined
  56. calvin has joined
  57. debacle has left
  58. beta has left
  59. beta has joined
  60. pdurbin has joined
  61. stpeter has left
  62. beta has left
  63. neshtaxmpp has left
  64. neshtaxmpp has joined
  65. Arc has left
  66. beta has joined
  67. calvin has left
  68. adiaholic has joined
  69. beta has left
  70. winfried has left
  71. winfried has joined
  72. beta has joined
  73. mukt2 has left
  74. mukt2 has joined
  75. Arc has joined
  76. beta has left
  77. mukt2 has left
  78. beta has joined
  79. mukt2 has joined
  80. beta has left
  81. winfried has left
  82. winfried has joined
  83. winfried has left
  84. winfried has joined
  85. andy has joined
  86. pdurbin has left
  87. winfried has left
  88. winfried has joined
  89. winfried has left
  90. winfried has joined
  91. winfried has left
  92. pdurbin has joined
  93. winfried has joined
  94. winfried has left
  95. beta has joined
  96. Arc why QUIC instead of SCTP?
  97. winfried has joined
  98. beta has left
  99. winfried has left
  100. sezuan has left
  101. winfried has joined
  102. winfried has left
  103. sezuan has joined
  104. winfried has joined
  105. winfried has left
  106. winfried has joined
  107. winfried has left
  108. mukt2 has left
  109. winfried has joined
  110. beta has joined
  111. lorddavidiii has joined
  112. winfried has left
  113. winfried has joined
  114. mukt2 has joined
  115. Vaulor has left
  116. Vaulor has joined
  117. Tobias has joined
  118. pdurbin has left
  119. beta has left
  120. paul has joined
  121. Steve Kille has joined
  122. beta has joined
  123. waqas has left
  124. waqas has joined
  125. lorddavidiii has left
  126. wurstsalat has joined
  127. Nekit has joined
  128. lorddavidiii has joined
  129. Steve Kille has left
  130. waqas has left
  131. lorddavidiii has left
  132. lorddavidiii has joined
  133. lorddavidiii has left
  134. marc has joined
  135. lorddavidiii has joined
  136. Steve Kille has joined
  137. lorddavidiii has left
  138. lorddavidiii has joined
  139. Zash Arc: New hotness?
  140. Douglas Terabyte has left
  141. Douglas Terabyte has joined
  142. lorddavidiii has left
  143. lorddavidiii has joined
  144. dwd Waqas, must be slow loading.
  145. andy has left
  146. lorddavidiii has left
  147. andy has joined
  148. beta has left
  149. lorddavidiii has joined
  150. lorddavidiii has left
  151. lorddavidiii has joined
  152. mukt2 has left
  153. Alex has left
  154. dwd Arc, QUIC has lower start-up cost, I think, plus it's likely to be around in implementations because of Google pushing it.
  155. Steve Kille has left
  156. flow dwd, the xep368 link is broken
  157. flow moparisthebest, I'd expect that XMPP over QUIC is not that hard to specifiy, it is probalby even esier than XMPP over TCP+TLS, because QUIC does most of the work for you.
  158. sonny has left
  159. Alex has joined
  160. Zash dwd, "latencies still have a visible human effect even when they drop below 30ms" - isn't that the other way around?
  161. Zash dwd, and browsers supposedly don't do pipelining
  162. sonny has joined
  163. dwd No, latencies still have an effect that low. Usually because of cumulative interaction, like sequential rtts, but in highly interactive stuff, I think people can still tell there's a lag just on a single rtt.
  164. marc has left
  165. sonny has left
  166. sonny has joined
  167. sonny has left
  168. sonny has joined
  169. sonny has left
  170. sonny has joined
  171. sonny has left
  172. sonny has joined
  173. sonny has left
  174. sonny has joined
  175. sonny has left
  176. sonny has joined
  177. pdurbin has joined
  178. mathijs has left
  179. mathijs has joined
  180. sonny has left
  181. sonny has joined
  182. sonny has left
  183. mukt2 has joined
  184. beta has joined
  185. sonny has joined
  186. sonny has left
  187. sonny has joined
  188. sonny has left
  189. sonny has joined
  190. sonny has left
  191. sonny has joined
  192. sonny has left
  193. sonny has joined
  194. sonny has left
  195. sonny has joined
  196. beta has left
  197. adiaholic has left
  198. adiaholic has joined
  199. ralphm Arc: primarily because SCTP has been tried before, and stranded on the fact that there is major inertia in middleboxes. They won't support new transport layer supports, and I think that this is the primary reason for Google to start work on QUIC.
  200. flow what ralphm said, and just when I asked myself about the differences and similarities between QUIC and SCTP, I found https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00
  201. sonny has left
  202. sonny has joined
  203. ralphm Yeah, that's an excellent, but bit dated, document.
  204. pdurbin has left
  205. ralphm I have been talking on and off with people about the prospects of XMPP-over-QUIC. Besides having TLS 1.3 built in, and the advantages of fewer round-trips upon reconnection (we probably still need to do work ourselves here, too), I also like the part where you have an identifier for a connection that survives roaming between different networks.
  206. Nekit has left
  207. Zash The "resource" ?
  208. ralphm E.g. when in an office on a higher floor going out for lunch, you'll be going WiFi - Cellular (elevator) - Wifi (lower floor) - Cellular (elevator) - WiFi (lobby) - Cellular (outside).
  209. sonny has left
  210. sonny has joined
  211. ralphm Zash: the Connection ID: https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-5
  212. sonny has left
  213. sonny has joined
  214. sonny has left
  215. sonny has joined
  216. emus has joined
  217. dwd That scenario is what we see, but on a constant basis as doctors and nurses walk between wards.
  218. Zash Moar access points!
  219. mathijs has left
  220. mathijs has joined
  221. mukt2 has left
  222. beta has joined
  223. flow ralphm, Isn't quick designed to survive roaming between different networks?
  224. flow ahh you "like the part", I read "like to have"…
  225. sonny has left
  226. flow slightly related: As I am working on Smack's lower layers, is there any reason I shouldn't prepare Smack to perform SM resumption over different transports besides TCP?
  227. Guus PSA: January 14, 2020 is the deadline for organisations to submit to GSoC. Now that I see some of the usual suspects here, I thought I'd bring that up. flow if we'd choose to apply, would you consider running as org admin again?
  228. flow Even though xep198 was probably written with SM resumption only being performed over TCP transports in mind, is there any reason we shouldn't allow SM resumption over different transports?
  229. Guus (14 January is in one week from now)
  230. flow Guus, as I am just back from vacation I was about to write a mail regarding that
  231. Guus 👍
  232. Guus just wanted to stir things. I'll await your email 🙂
  233. flow Guus, btw, 14th is not the deadline if I am not mistaken
  234. Guus flow you're right
  235. Guus that's when registration opens.
  236. Guus sorry for that.
  237. Guus > All organizations wishing to be a part of GSoC 2020 must complete their application by February 5, 2020 20:00
  238. Guus Sorry for butting in the conversation then
  239. flow na, no worries
  240. beta has left
  241. mukt2 has joined
  242. ralphm dwd: maybe we should make some time around the summit to work on this?
  243. sonny has joined
  244. dwd Flow, sm is deployed over websockets by Stanza, Prosody, Openfire, and probably others.
  245. flow dwd, so I could resume a session previously connected via TCP over webscokets on Openfire and Prosody?
  246. Ge0rG Speaking of SM over websockets, we still miss a way to sm-resume an anonymous session
  247. Zash Did ISR allow that?
  248. dwd Flow, ... Maybe?
  249. dwd Zash, yes, isr would allow that.
  250. dwd I think.
  251. Zash flow, yes, except for the part where Prosody doesn't officially support 198 out of the box
  252. mukt2 has left
  253. mukt2 has joined
  254. sonny has left
  255. flow So SM with TCP and Websockets ✓ what about SM resumption over BOSH and QUIC?
  256. flow I can see that we may not want to put in effort to think about SM over BOSH, as it would potentially duplicate a lot of what BOSH already does, or maybe there is a chance to unify it? But how relevant is BOSH given that we have Websockets now?
  257. flow Compared to that, SM over QUIC appears straight forward
  258. adiaholic has left
  259. adiaholic has joined
  260. dwd I think lots of networks will block QUIC, so SM is still useful.
  261. beta has joined
  262. karoshi has joined
  263. flow Probably even if QUIC is available nearly everhwere, SM resumption across transports is still nice to have
  264. Ge0rG I agree with that, and resuming 0198 from a gone TCP connection on a BOSH, because you moved into nazi firewall land, seems sensible
  265. sonny has joined
  266. beta has left
  267. beta has joined
  268. adiaholic has left
  269. adiaholic has joined
  270. beta has left
  271. sonny has left
  272. sonny has joined
  273. ralphm dwd: why would they block QUIC?
  274. dwd ralphm, Some of the hospitals we work in block everything and whitelist a handful of IP addresses and ports.
  275. dwd ralphm, QUIC operates over UDP, right? So I'd imagine there's little hope it'll just work in any kind of "nazi firewall land".
  276. ralphm Also note that there's been an effort to allow QUIC to multiplex with STUN and TURN.
  277. ralphm So indeed, if you are in a network that also blocks WebRTC, then you'd be out of luck.
  278. mukt2 has left
  279. sonny has left
  280. beta has joined
  281. Nekit has joined
  282. sonny has joined
  283. beta has left
  284. pdurbin has joined
  285. Dele (Mobile) has joined
  286. sonny has left
  287. Dele (Mobile) has left
  288. ralphm dwd: would you count medical institutions in such lands?
  289. pdurbin has left
  290. lorddavidiii has left
  291. lorddavidiii has joined
  292. adiaholic has left
  293. adiaholic has joined
  294. dwd Some of them certainly are. There's a lot of well-placed concern about infosec in the NHS, especially after the malware attacks a couple of years back.
  295. Dele (Mobile) has joined
  296. Dele (Mobile) has left
  297. Dele (Mobile) has joined
  298. sonny has joined
  299. larma has left
  300. Dele (Mobile) has left
  301. Dele (Mobile) has joined
  302. larma has joined
  303. beta has joined
  304. Dele (Mobile) has left
  305. Dele (Mobile) has joined
  306. neshtaxmpp has left
  307. sonny has left
  308. mukt2 has joined
  309. ralphm Right
  310. mukt2 has left
  311. sonny has joined
  312. Wojtek has joined
  313. lorddavidiii has left
  314. neshtaxmpp has joined
  315. lorddavidiii has joined
  316. sonny has left
  317. Dele (Mobile) has left
  318. Dele (Mobile) has joined
  319. lorddavidiii has left
  320. lorddavidiii has joined
  321. mukt2 has joined
  322. Dele (Mobile) has left
  323. Dele (Mobile) has joined
  324. lorddavidiii has left
  325. lorddavidiii has joined
  326. larma dwd, nice blog post. Just to play devil's advocate here, I think your "even on mobile" paragraph is not fair. Optimizing for mobile is not only about bandwidth and latency, it also needs to consider energy consumption (which seems to be something where EXI may have some significant advantage over plaintext XML), constantly switching networks (change in ip addreseses / tcp connections breaking up) and data consumption (due to limited plans). Also throttled mobile networks (after you exceeded your "flatrate"'s high speed data) can go as low as 32 kbit/s (shared with all apps on the phone)
  327. lorddavidiii has left
  328. lorddavidiii has joined
  329. sonny has joined
  330. pep. dwd, "the malware attack", you mean the ransomware?
  331. beta has left
  332. beta has joined
  333. mukt2 has left
  334. sonny has left
  335. pdurbin has joined
  336. beta has left
  337. mukt2 has joined
  338. lorddavidiii has left
  339. lorddavidiii has joined
  340. sonny has joined
  341. emus has left
  342. pdurbin has left
  343. emus has joined
  344. beta has joined
  345. sonny has left
  346. beta has left
  347. sonny has joined
  348. marc has joined
  349. debacle has joined
  350. sonny has left
  351. sonny has joined
  352. mukt2 has left
  353. mukt2 has joined
  354. mimi89999 has left
  355. mimi89999 has joined
  356. jonas’ https://sha-mbles.github.io/ via pep.
  357. ralphm I'm not sure if data consumption is affected by using using EXI, though. I believe mobile networks charge based on certain minimum packet sizes.
  358. beta has joined
  359. ralphm And dwd has discussed energy usage in his XEP a long time ago already.
  360. ralphm I.e. his argument there is that radio usage affects battery a great deal more.
  361. ralphm (larma)
  362. mimi89999 has left
  363. mimi89999 has joined
  364. beta has left
  365. dwd No, I think larma is right, modulo "significant". Transmitting EXI is lower octets, and while it'll probably cost the same, it'll be less power. Additionally, receiving EXI might come in under radio limits, though I have no idea if my knowledge on FACH etc is useful post-3G.
  366. dwd SO it'll make a difference, though whether this becomes significant or not I can't tell. My gut feeling is probably not.
  367. beta has joined
  368. larma I think EXI is more important from the save energy perspective than from the save bandwidth/data perspective. Significant might be a bit to much, but at least measurable
  369. COM8 has joined
  370. matlag has left
  371. larma It also depends on the type of messages you send around. If it's only messages with a body, then impact is far less than if you include messages like receipts and so on that can profit much more (relatively spoken) from EXI
  372. dwd ‎[23:24:25] ‎dwd‎: True, if you were shipping complex and large xml around like atom, it might make a difference. But EXI is most useful for reducing processor and memory load, not bandwidth.
  373. dwd But I don't think that's going to be very significant at all for a mobile handset - there I was meaning in terms of IoT and embedded devices.
  374. mimi89999 has left
  375. mimi89999 has joined
  376. dwd Still, by all means measure it.
  377. beta has left
  378. larma Maybe we should just try it out, I am at least rather certain that it won't hurt ;)
  379. dwd Well, aside from fixing schemas, etc.
  380. neshtaxmpp has left
  381. larma dwd: but using schema is optional for EXI, no?
  382. dwd Sort of. My (poor) understanding was that using EXI without strict schemas was a bit pointless.
  383. Kev Isn't it ~=deflate at that point?
  384. dwd Well, only if you're using deflate.
  385. dwd And if you're using deflate, then you have a compression oracle, so...
  386. dwd You're also probably outweighing any benefit, CPU-wise.
  387. mimi89999 has left
  388. mimi89999 has joined
  389. neshtaxmpp has joined
  390. beta has joined
  391. larma Wasn't it somehow learning the "schema" (probably rather qnames) from the actual XML being exchanged? Maybe I'm confusing it with something else. Yes that's probably similar to deflate(xml) but minus the xml parsing (because EXI already takes care of that in an efficient way)
  392. ralphm Arc has done a lot of work on EXI, so you may want to ask him.
  393. larma I talked with him a few months ago, so most of my EXI knowledge is actually from him ;)
  394. mukt2 has left
  395. mukt2 has joined
  396. dwd EXI has two switches - strict schema and deflate. With strict schema both ends will need to agree on the schemas used, and any additional attributes and extra bits in other namespaces (for example) are removed.
  397. Zash Was there a mode that's equivalent to sending generic XML packed in C-like structs?
  398. dwd Zash, That's sort of what EXI does, I believe, though the element tags etc are given identifiers based on the schema most of the time.
  399. Dele (Mobile) has left
  400. Dele (Mobile) has joined
  401. sonny has left
  402. Dele (Mobile) has left
  403. Dele (Mobile) has joined
  404. Dele (Mobile) has left
  405. Dele (Mobile) has joined
  406. pdurbin has joined
  407. sonny has joined
  408. Dele (Mobile) has left
  409. Dele (Mobile) has joined
  410. Shell has joined
  411. Nekit has left
  412. Dele (Mobile) has left
  413. Dele (Mobile) has joined
  414. Steve Kille has joined
  415. Dele (Mobile) has left
  416. moparisthebest Arc, simple, because only QUIC, not SCTP, has been blessed by "the browsers", so only it has a chance to work into the future :'(
  417. flow "With strict schema both ends will need to agree on the schemas used, and any additional attributes and extra bits in other namespaces (for example) are removed." Wasn't there a, potential configurable, fallback to schema-uninformed mode if the schemas are not available?
  418. Ge0rG What would be wrong with the client informing the server on its schema on session setup?
  419. pdurbin has left
  420. pep. moparisthebest, and by "the browsers" you mean google? :)
  421. Shell has left
  422. Ge0rG Google Chrome and Google Firefox.
  423. Daniel has left
  424. Daniel has joined
  425. Shell has joined
  426. moparisthebest well I meant chrome and firefox but yea that's a different thing to cry about
  427. sonny has left
  428. pep. Oh and Google Brave! The privacy-minded browser that's chained to a block
  429. matlag has joined
  430. ralphm moparisthebest, I think what I wrote above as the reason is a lot more plausible.
  431. mathijs has left
  432. mathijs has joined
  433. dwd Also not entirely clear what SCTP would buy us here. It does allow multiple endpoints at each end of a VC, but I don't think it'll allow for sudden network switching.
  434. dwd ANd the startup cost is roughly the same as TCP, unlike QUIC.
  435. sonny has joined
  436. moparisthebest also no encryption built in with SCTP, is there even encryption defined to go over it?
  437. Zash IPsec?
  438. Zash How's mptcp these days ?
  439. Shell has left
  440. Shell has joined
  441. moparisthebest I think it's equally dead for the reason ralphm said, too many middleboxes don't do IP, they only do UDP and TCP, so those are the only protocols allowed to exist in the future
  442. mukt2 has left
  443. mukt2 has joined
  444. j.r has joined
  445. Shell has left
  446. Shell has joined
  447. Zash MPTCP was supposed to be compatible with TCP
  448. adiaholic has left
  449. adiaholic has joined
  450. sonny has left
  451. sonny has joined
  452. larma SCTP over dTLS over UDP?
  453. larma feels like reconstructing the WebRTC stack 😀
  454. Shell has left
  455. Shell has joined
  456. Shell has left
  457. Shell has joined
  458. moparisthebest so I guess that was a "no" to my original question "has anyone started specifying XMPP-over-QUIC" ?
  459. moparisthebest the hardest part will be defining how to pronounce XoQ
  460. APach has left
  461. karoshi has left
  462. karoshi has joined
  463. mukt2 has left
  464. APach has joined
  465. Shell has left
  466. Shell has joined
  467. mukt2 has joined
  468. Steve Kille has left
  469. Kev has left
  470. sonny has left
  471. Dele (Mobile) has joined
  472. calvin has joined
  473. calvin has left
  474. goffi has joined
  475. ralphm AFAIK, nobody has done this yet, and I nudged dwd with a suggestion to work on it with him around the Summit.
  476. Ge0rG What kind of standardization is needed for that?
  477. ralphm Well, I think the best approach would be an IETF Draft. A few words on TLS already done at the transport layer, some on session reestablishment. I need to look into it in detail.
  478. ralphm For comparison, look at https://tools.ietf.org/html/rfc7395 that was done for the WebSocket binding.
  479. calvin has joined
  480. ralphm Then, if you want to go fancy, there could be another spec on how you might make use of the connection for multiplexing media streams with Jingle, TURN.
  481. eevvoor has joined
  482. Shell has left
  483. Shell has joined
  484. sonny has joined
  485. dwd FWIW, I don't think this is a Summit task.
  486. david has left
  487. david has joined
  488. ralphm dwd: I don't think it is a Summit task. It is something we could maybe discuss, figure out, whatever, around the Summit, while there's a high bandwidth connection in place.
  489. sonny has left
  490. Shell has left
  491. Shell has joined
  492. calvin has left
  493. calvin has joined
  494. Ge0rG does that actually require a high-bandwidth connection?
  495. dwd Ge0rG, Only until we have QUIC.
  496. Shell has left
  497. Shell has joined
  498. Ge0rG Are we speaking of the same kind of connection?
  499. moparisthebest here is an example of another protocol over QUIC https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07
  500. Shell has left
  501. Shell has joined
  502. moparisthebest but we probably want to consider if we want to take the same approach as https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07#section-3.5 or whether we should just throw up our hands and define XMPP-over-HTTP/QUIC
  503. jonas’ where’s the example which abolishes quic?
  504. moparisthebest at this point I'd probably just lean towards "indistinguishable from HTTP" to head off problems down the road
  505. COM8 has left
  506. COM8 has joined
  507. sonny has joined
  508. moparisthebest but maybe you don't and if you are faced with such a crap network you do XMPP-over-BOSH-over-HTTP/QUIC and cry in a corner
  509. Zash I don't wanna live in a world where everyhing is HTTP
  510. moparisthebest There are no Websockets over http/2, I'm pretty sure there ane no Websockets over http/3 either
  511. moparisthebest I don't think any of us want to live in that world Zash , yet here we are :(
  512. edhelas can't wait for QUIC over XMPP
  513. Shell has left
  514. Shell has joined
  515. MattJ over pubsub you mean?
  516. edhelas let's wait for full Pubsub support in the XMPP servers first
  517. pdurbin has joined
  518. Shell has left
  519. Shell has joined
  520. sonny has left
  521. stpeter has joined
  522. Shell has left
  523. Shell has joined
  524. sonny has joined
  525. karoshi has left
  526. karoshi has joined
  527. dwd moparisthebest, HTTP/2 doesn't have websockets?
  528. lorddavidiii has left
  529. moparisthebest nope
  530. lorddavidiii has joined
  531. marc has left
  532. calvin has left
  533. calvin has joined
  534. Zash Doesn't ALPN remove the need somewhat? Like, why talk something over ws when you can talk something directly?
  535. j.r has left
  536. jonas’ browsers still don’t allow you to open arbitrary sockets, do they?
  537. Zash Of course not
  538. moparisthebest 1. you are running in a web browser 2. you want to pretend to be a web browser because evil middleboxen
  539. Zash 1. I'm not. 2. I don't.
  540. j.r has joined
  541. adiaholic has left
  542. pdurbin has left
  543. alameyo has left
  544. alameyo has joined
  545. mukt2 has left
  546. mukt2 has joined
  547. dwd moparisthebest, RFC 8441 BTW
  548. Shell has left
  549. sonny has left
  550. Shell has joined
  551. Shell has left
  552. Shell has joined
  553. j.r has left
  554. j.r has joined
  555. mukt2 has left
  556. aj has joined
  557. moparisthebest dwd, ah awesome, that's newer, I *suppose* that might *just work* over http/3 too
  558. jonas’ if we accept that the world is going to be *-over-HTTP anyways, why keep bothering with XMPP?
  559. Zash give up and join matrix?
  560. jonas’ would make much more sense to drop that layer of complexity and do something with JSON-over-HTTP directly.
  561. moparisthebest HTTP doesn't solve the problems that XMPP does?
  562. sonny has joined
  563. jonas’ sure, but you can solve those problems on top of HTTP obviously, and you can do that easier than by wrapping XMPP in Websockets over HTTP
  564. jonas’ easier = with less technology stacked on top of each other
  565. moparisthebest JSON vs XML is a different discussion, JSON isn't any more closely tied to HTTP than XML is it?
  566. pep. it isn't. it also isn't more closely tied to browsers than XML is
  567. jonas’ also not the main point I’m trying to make
  568. jonas’ JSON vs. XML does indeed not matter
  569. jonas’ question is why bother with XMPP if we’re going to squash it over HTTP either way?
  570. moparisthebest I'm not sure I buy your argument yet, that you can do it easier with plain HTTP than XMPP over HTTP
  571. jonas’ for certain definitions of plain HTTP
  572. Shell has left
  573. Shell has joined
  574. moparisthebest just to be clear definition-wise, QUIC replaces TCP+TLS, http/3 is HTTP over QUIC, and we could end up doing XMPP over QUIC *and/or* XMPP over http/3 (and the latter could be BOSH, Websockets, or something new)
  575. moparisthebest sorry, http/3 is http/2 over QUIC
  576. jonas’ did I mention that’s all awful?
  577. Zash everything is terrible
  578. jonas’ I’m going to start make dinner before this ruins my night
  579. moparisthebest *all* of it's awful?
  580. moparisthebest at least QUIC replacing TCP+TLS doesn't seem bad to me
  581. dwd Seems fine to me too.
  582. Zash Something something potato farming
  583. pep. Zash, so you can throw potatoes at Google?
  584. mathijs has left
  585. mathijs has joined
  586. moparisthebest it has plenty of other upsides, but maybe the best for everyone is connections surviving network/ip switches
  587. j.r has left
  588. Zash pep., strategic ballistic potato warfare?
  589. jonas’ see, QUIC isn’t even an RFC yet
  590. mukt2 has joined
  591. moparisthebest it's pretty close, and widely implemented/deployed :)
  592. jonas’ and that everyone is talking about building stuff on it is plain running behind google and chromium to not fall perceivedly behind
  593. jonas’ widely ipmlemented/deployed and not through IETF process is a red flag to me
  594. moparisthebest some significant percentage of XMPP isn't an RFC either
  595. jonas’ especially if driven by a large commercial entity
  596. moparisthebest it is through an IETF process
  597. jonas’ "through" as in "passed completely"
  598. Zash Simliar to HTTP/2?
  599. dwd The concern is mostly whether, if Chrome and the IETF diverge, will the IETF's draft get "correctd" or the Chrome implementation.
  600. moparisthebest jonas’, no I'm not talking about the old/dead google/quic, but the widely implemented/deployed ietf/quic
  601. jonas’ moparisthebest, the core of XMPP is IETF-realm, and everything on top of that is XSF-realm, which as kind of a fork of some IETF workgroup is okay in my book. it’s an open process with controls to prevent a single company from taking over.
  602. jonas’ moparisthebest, ietf/quic, as per the expired draft?
  603. jonas’ a draft which has expired for two and a half years now
  604. jonas’ anyways, dinner
  605. j.r has joined
  606. calvin has left
  607. Zash Which draft?
  608. moparisthebest jonas’, https://quicwg.org/ "QUIC is an IETF Working Group that is chartered to deliver the next transport protocol for the Internet." I don't see what you are worried about exactly
  609. Zash https://tools.ietf.org/wg/quic/ most of those look fairly recent
  610. dwd Ah, I think jonas’ was looking at draft-tsvwg-quic-protocol, which died (and was shelved, IIRC, until HTTP/2 was done).
  611. Zash But HTTP is frozen in time!!!!1!!
  612. j.r has left
  613. !XSF_Martin That's a good album.
  614. Shell has left
  615. Shell has joined
  616. !XSF_Martin starts humming the 'redneck stomp'
  617. moparisthebest not good https://sha-mbles.github.io/
  618. calvin has joined
  619. aj has left
  620. !XSF_Martin Sha1 is used for scram in prosody, right?
  621. MattJ In XMPP
  622. dwd SHA-1 is used in SCRAM-SHA-1, yes.
  623. dwd Time to bump the MTI again...
  624. Zash SHA-1 broken doesn't mean that HMAC-SHA-1 is broken
  625. !XSF_Martin Is it possible to upgrade to something not yet broken?
  626. Zash Nor that PBKDF2 is broken
  627. !XSF_Martin > SHA-1 broken doesn't mean that HMAC-SHA-1 is broken So scram-sha-1 is not affected?
  628. rion has left
  629. Zash !XSF_Martin: Not easily
  630. rion has joined
  631. dwd https://twitter.com/matthew_d_green/status/1214585587874877440
  632. jonas’ it isn’t, because SCRAM doesn’t care much about collision resistance. also, love the analogy of Matthew Green there
  633. dwd More particularly, I do not know that HMAC-SHA-1 is safe (whereas I do know that HMAC-MD5 is safe, or rather, as a cryptographer said over coffee, "Yeah, I think that's still safe though you'd be insane to use it of course")
  634. mathijs has left
  635. mathijs has joined
  636. Zash Practically it's nontrivial to upgrade
  637. dwd It'd be nice if we had a forced password update protocol.
  638. dwd looks meaningfully at XEP-0388
  639. !XSF_Martin > Practically it's nontrivial to upgrade That's better than impossible. 🙂
  640. j.r has joined
  641. MattJ Zash: other way around. You mean theoretically it's nontrivial to upgrade. Practically speaking, I doubt most clients will blink if you one day just offer PLAIN
  642. Zash MattJ: No, they will refuse
  643. MattJ Because it's 2020 now and software is secure?
  644. MattJ Did I miss this?
  645. Zash Conversations does this
  646. marc has joined
  647. MattJ Any others?
  648. Zash Dunno
  649. MattJ Conversations can be fixed (to do something sensible)
  650. Zash Allowing downgrade attacks ?
  651. MattJ Which would be SASL2 of course
  652. Zash Right
  653. moparisthebest I wonder what it means for git/hg
  654. Zash They already started looking at replacing sha1
  655. mukt2 has left
  656. jonas’ I think they need to hurry up
  657. mukt2 has joined
  658. moparisthebest > linus said attacks like that on git are harder because the hash input is tagged with a type/length, so the collision would have to be the same length
  659. moparisthebest so "it's probably ok for now" but not rock solid
  660. !XSF_Martin A sealife habitat?
  661. dwd MattJ, Quite a few spot if you remove SCRAM-SHA-1 suddenly.
  662. dwd MattJ, But yeah, SASL2 and a password reset task would be awesome. Except clients would still try to use SCRAM-SHA-1.
  663. Ge0rG there is still PLAIN. But you can't downgrade secure clients.
  664. Shell has left
  665. Shell has joined
  666. Shell has left
  667. Shell has joined
  668. mimi89999 has left
  669. mimi89999 has joined
  670. calvin has left
  671. Shell has left
  672. Shell has joined
  673. sonny has left
  674. sonny has joined
  675. Dele (Mobile) has left
  676. Dele (Mobile) has joined
  677. eevvoor has left
  678. sonny has left
  679. sonny has joined
  680. adiaholic has joined
  681. Shell has left
  682. Shell has joined
  683. sonny has left
  684. sonny has joined
  685. mimi89999 has left
  686. mimi89999 has joined
  687. sonny has left
  688. sonny has joined
  689. mimi89999 has left
  690. mimi89999 has joined
  691. madhur.garg has joined
  692. pdurbin has joined
  693. matkor has left
  694. matkor has joined
  695. sonny has left
  696. sonny has joined
  697. pdurbin has left
  698. mukt2 has left
  699. mukt2 has joined
  700. calvin has joined
  701. sonny has left
  702. neshtaxmpp has left
  703. sonny has joined
  704. debacle has left
  705. Nekit has joined
  706. sonny has left
  707. calvin has left
  708. emus has left
  709. calvin has joined
  710. dele has joined
  711. Shell has left
  712. Shell has joined
  713. Shell has left
  714. Zash has left
  715. Zash has joined
  716. Zash has left
  717. Zash has joined
  718. adiaholic has left
  719. Dele (Mobile) has left
  720. Dele (Mobile) has joined
  721. COM8 has left
  722. moparisthebest if PLAIN is always good enough for HTTP...
  723. moparisthebest ducks and runs
  724. dele has left
  725. sonny has joined
  726. stpeter has left
  727. mukt2 has left
  728. mukt2 has joined
  729. emus has joined
  730. dwd Goodness no. The web world uses bearer tokens, which are entirely different.
  731. Ge0rG Say what? Authorization basic can't hear you
  732. debacle has joined
  733. calvin has left
  734. calvin has joined
  735. sonny has left
  736. pdurbin has joined
  737. Steve Kille has joined
  738. sonny has joined
  739. pdurbin has left
  740. sonny has left
  741. sonny has joined
  742. sonny has left
  743. calvin has left
  744. calvin has joined
  745. sonny has joined
  746. j.r has left
  747. j.r has joined
  748. mukt2 has left
  749. andrey.g has left
  750. calvin has left
  751. Wojtek has left
  752. mukt2 has joined
  753. calvin has joined
  754. sonny has left
  755. mukt2 has left
  756. mukt2 has joined
  757. stpeter has joined
  758. sonny has joined
  759. lovetox has joined
  760. sonny has left
  761. sonny has joined
  762. j.r has left
  763. j.r has joined
  764. Lance has joined
  765. Tobias has left
  766. mr.fister has joined
  767. Steve Kille has left
  768. j.r has left
  769. j.r has joined
  770. sonny has left
  771. Lance has left
  772. mukt2 has left
  773. pdurbin has joined
  774. neshtaxmpp has joined
  775. mukt2 has joined
  776. pdurbin has left
  777. j.r has left
  778. mukt2 has left
  779. j.r has joined
  780. Lance has joined
  781. mukt2 has joined
  782. Dele (Mobile) has left
  783. lorddavidiii has left
  784. lorddavidiii has joined
  785. lovetox has left
  786. sonny has joined
  787. sonny has left
  788. sonny has joined
  789. sonny has left
  790. sonny has joined
  791. sonny has left
  792. sonny has joined
  793. andrey.g has joined
  794. mukt2 has left
  795. lorddavidiii has left
  796. Dele (Mobile) has joined
  797. mukt2 has joined
  798. j.r has left
  799. j.r has joined
  800. Nekit has left
  801. goffi has left
  802. Shell has joined
  803. calvin has left
  804. emus has left
  805. beta has left
  806. mukt2 has left
  807. mukt2 has joined
  808. Dele (Mobile) has left
  809. beta has joined
  810. sonny has left
  811. sonny has joined
  812. Dele (Mobile) has joined
  813. Dele (Mobile) has left
  814. mukt2 has left