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