XSF Discussion - 2017-11-10


  1. Ge0rG has left
  2. arc has left
  3. Arc has left
  4. Arc has joined
  5. arc has joined
  6. uc has joined
  7. jjrh has left
  8. Ge0rG has left
  9. jjrh has left
  10. jjrh has left
  11. jjrh has left
  12. jjrh has left
  13. jere has left
  14. jere has joined
  15. Ge0rG has left
  16. Guus has left
  17. jjrh has left
  18. daniel has left
  19. Ge0rG has left
  20. Valerian has left
  21. Valerian has joined
  22. Valerian has left
  23. jjrh has left
  24. jjrh has left
  25. Guus has joined
  26. Lance has joined
  27. la|r|ma has joined
  28. Guus has left
  29. Ge0rG has left
  30. Guus has joined
  31. Arc has left
  32. Arc has joined
  33. Ge0rG has joined
  34. Valerian has joined
  35. Ge0rG has left
  36. sonny has left
  37. sonny has joined
  38. Guus has left
  39. Guus has joined
  40. la|r|ma has joined
  41. lskdjf has joined
  42. Ge0rG has left
  43. tux has left
  44. tux has joined
  45. SamWhited has left
  46. efrit has joined
  47. Ge0rG has left
  48. Valerian has left
  49. SamWhited has left
  50. Valerian has joined
  51. Valerian has left
  52. SamWhited has joined
  53. jere has left
  54. jere has joined
  55. Tobias has joined
  56. Tobias has joined
  57. Arc has left
  58. Arc has joined
  59. Ge0rG has left
  60. matlag has left
  61. arc has left
  62. arc has joined
  63. efrit has left
  64. efrit has joined
  65. bear has left
  66. daniel has left
  67. nyco has left
  68. nyco has joined
  69. Ge0rG has left
  70. Ge0rG has left
  71. Valerian has joined
  72. Ge0rG has left
  73. Ge0rG has left
  74. bear has joined
  75. Lance has left
  76. Ge0rG has left
  77. Ge0rG has left
  78. Valerian has left
  79. Ge0rG has left
  80. lumi has left
  81. Ge0rG has left
  82. uc has left
  83. uc has joined
  84. arc has left
  85. arc has joined
  86. efrit has left
  87. Ge0rG has left
  88. Ge0rG has left
  89. SamWhited has left
  90. jere has left
  91. Ge0rG has left
  92. Syndace has joined
  93. Syndace has joined
  94. Ge0rG has left
  95. daniel has left
  96. Ge0rG has left
  97. Ge0rG has left
  98. Ge0rG has left
  99. daniel has left
  100. Guus has left
  101. Guus has joined
  102. Ge0rG has left
  103. goffi has joined
  104. daniel has left
  105. arc has left
  106. arc has joined
  107. jubalh has joined
  108. Arc has left
  109. daniel has left
  110. arc has left
  111. arc has joined
  112. arc has left
  113. arc has joined
  114. Guus has left
  115. Guus has joined
  116. jubalh has left
  117. arc has left
  118. arc has joined
  119. xnyhps has left
  120. Guus has left
  121. Guus has joined
  122. ralphm has left
  123. ralphm has left
  124. intosi has joined
  125. Ge0rG has left
  126. marc has joined
  127. ralphm has left
  128. waqas has left
  129. Steve Kille has left
  130. Steve Kille has left
  131. Steve Kille has left
  132. Ge0rG has left
  133. Steve Kille has joined
  134. ralphm has left
  135. edhelas has left
  136. jubalh has left
  137. jubalh has left
  138. @Alacer has joined
  139. la|r|ma has joined
  140. jubalh has joined
  141. ralphm has joined
  142. Ge0rG has joined
  143. jubalh has left
  144. jubalh has joined
  145. daniel has left
  146. Ge0rG has left
  147. ralphm has joined
  148. daniel has left
  149. ralphm has left
  150. mimi89999 has joined
  151. lskdjf has joined
  152. daniel has left
  153. jcbrand has joined
  154. Zash has left
  155. Guus Any webrtc aficionado here?
  156. edhelas o/
  157. marc \o
  158. Zash has left
  159. jonasw possibly in the future
  160. edhelas I'm still waiting for clients that are proposing native WebRTC + native Jingle to do tests with Movim :)
  161. Guus (I'm a noob, my terminiology might be off): I'm looking for information on the SSLTCP ICE canidate. As far as I understand, it "mimics" a SSL/TLS handshake to fool some firewalls into accepting traffic, without doing actual SSL/TLS encryption (thus not fooling proper firewalls).
  162. Guus my questions: a) exactly what version of the clienthello (I think?) is mimiced? b) There appears to be something called TURNS which does full TLS that allows passage through proper filewalls (with the overhead of encryption). This is pretty hard to find via google - where's that documented?
  163. Guus </questions>
  164. jonasw Guus, https://tools.ietf.org/html/rfc5766
  165. jonasw that mentions "turns"
  166. jonasw (including the quotes)
  167. jonasw so maybe "TURN over TLS" is a good search term
  168. jonasw (that term at least works for me with google, but my google is well-trained on RFCs etc.)
  169. Guus tx
  170. jonasw a quick google suggests that ssltcp is propretary
  171. jonasw *proprietary
  172. jonasw so aside from reverse engineering google hangouts, it could be tricky to find out how it works
  173. Guus ah, Microsoft does document something similar, it appears. They're clalling that MS-TURN: http://interoperability.blob.core.windows.net/files/MS-TURN/[MS-TURN].pdf
  174. Guus "Pseudo-TLS over TCP"
  175. daniel has left
  176. daniel has left
  177. Guus has left
  178. efrit has joined
  179. Alex has joined
  180. @Alacer has left
  181. uc has joined
  182. uc has joined
  183. @Alacer has joined
  184. Zash has joined
  185. arc has left
  186. arc has joined
  187. jubalh has joined
  188. Syndace has left
  189. daniel has left
  190. zinid has left
  191. andrey.g has left
  192. Guus so, yeah, the SSLTCP ICE pseudo clienthello is a SSL v2.0 clienthello with a specific challenge (yey for wireshark)
  193. jonasw sslv2, amusing. but I wouldn’t be surprised if the kind of firewalls fooled by that would also be the kind of firewalls not giving a lot about actual transport security :-)
  194. Guus exactly what I was thinking. It also answers my question on why the multiplexer I was using didn't seem to pick it up with the default "TLS" probe :)
  195. jubalh has joined
  196. jere has joined
  197. lskdjf has joined
  198. jubalh has left
  199. sonny has joined
  200. waqas has joined
  201. waqas has left
  202. daniel has left
  203. edhelas has left
  204. jcbrand has left
  205. la|r|ma has joined
  206. daniel has left
  207. Alex has left
  208. daniel has left
  209. Syndace has left
  210. daniel has left
  211. ralphm has left
  212. jere has left
  213. jere has joined
  214. Alex has left
  215. daniel has left
  216. jubalh has joined
  217. Valerian has joined
  218. daniel has left
  219. daniel has joined
  220. intosi has left
  221. jubalh has left
  222. jubalh has joined
  223. Alex has joined
  224. jubalh has left
  225. intosi has joined
  226. efrit has left
  227. vanitasvitae has joined
  228. vanitasvitae has joined
  229. vanitasvitae has left
  230. lumi has joined
  231. vanitasvitae has joined
  232. lskdjf has left
  233. lskdjf has joined
  234. Alex has left
  235. vanitasvitae has left
  236. Valerian has left
  237. moparisthebest Guus: also stun and turn alpn IDs here https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
  238. zinid still no our ALPNs in the list
  239. zinid xmpp-server and xmpp-client
  240. daniel has left
  241. moparisthebest zinid: supposedly iana approved and they will be there next update
  242. moparisthebest I want to guess and say that was a month ago
  243. andrey.g has joined
  244. vanitasvitae has joined
  245. lovetox has joined
  246. lumi has joined
  247. Syndace has left
  248. Valerian has joined
  249. daniel has left
  250. Guus has left
  251. daniel has left
  252. daniel has joined
  253. waqas has joined
  254. waqas has left
  255. la|r|ma has left
  256. Syndace has left
  257. Syndace has left
  258. ralphm has joined
  259. tux has joined
  260. jere has left
  261. jere has joined
  262. jere has left
  263. jere has joined
  264. jere has left
  265. jere has joined
  266. Guus has left
  267. Syndace has left
  268. valo has joined
  269. valo has joined
  270. Syndace has left
  271. bjc has joined
  272. la|r|ma has joined
  273. la|r|ma has joined
  274. Ge0rG has left
  275. Zash has left
  276. Ge0rG has left
  277. Guus has left
  278. @Alacer has left
  279. Ge0rG has left
  280. ralphm has left
  281. Ge0rG has left
  282. Guus has left
  283. intosi has left
  284. Guus has left
  285. marc has left
  286. uc has joined
  287. daniel has left
  288. daniel has joined
  289. uc has joined
  290. Zash has left
  291. la|r|ma has joined
  292. la|r|ma has joined
  293. daniel has left
  294. daniel has joined
  295. tux has joined
  296. @Alacer has joined
  297. ralphm has joined
  298. Guus has left
  299. tux has joined
  300. Valerian has left
  301. la|r|ma has left
  302. la|r|ma has joined
  303. Valerian has joined
  304. tux has left
  305. jere has left
  306. jere has joined
  307. tux has joined
  308. jere has joined
  309. jere has joined
  310. bjc has left
  311. bjc has joined
  312. Guus has left
  313. vanitasvitae has left
  314. daniel has left
  315. Steve Kille has left
  316. Steve Kille has left
  317. Steve Kille has joined
  318. jubalh has joined
  319. ralphm has left
  320. jere has left
  321. jere has joined
  322. jere has left
  323. jere has joined
  324. jabberatdemo has joined
  325. Steve Kille has left
  326. jabberatdemo has left
  327. Guus has left
  328. Tobias has joined
  329. Guus has left
  330. jere has left
  331. jere has joined
  332. ralphm has joined
  333. Ge0rG has joined
  334. Guus has left
  335. jubalh has left
  336. bjc has joined
  337. daniel has left
  338. Valerian has left
  339. daniel has left
  340. Valerian has joined
  341. jjrh has left
  342. jjrh has left
  343. SamWhited daniel: the wording is a bit confusing, I'll have to think about how that whole section can be rewritten later, but here's a patch for the issue you mentioned: https://github.com/xsf/xeps/pull/539
  344. Zash has left
  345. jubalh has joined
  346. Zash has left
  347. daniel SamWhited, yes. wording this is the only downside of this otherwise useful change... I think you did a good job though.
  348. SamWhited It may be better to rewrite that chunk as a list of rules in the order you should apply them when parsing
  349. daniel should probably contain a few 'negative' examples as well. like `*foo *bar` (indicate that this wont be styled)
  350. daniel but we can finish the XEP first before we add more examples
  351. SamWhited Good call, I should add some for this rule to that list (there is a list of things that aren't styled)
  352. SamWhited (added that one)
  353. jubalh has joined
  354. daniel Conversations Master has already been updated to reflect that change by the way. That's going to be shipped with one of the bug fix releases that always follow my minor releases
  355. daniel Will be interesting to see where the broader 'leave keywords in' discussion leads
  356. SamWhited I still don't have the regular release for whatever reason
  357. daniel If people really end up hating the keywords we will have to think about and opt in annotations or what ever
  358. SamWhited Yah, I'll be curious about that. I still think it's an implementation detail and is up to individual clients/services, which is why I only made it a SHOULD after we upgraded it from MAY
  359. daniel I just promoted from beta to stable an hour ago
  360. daniel Guess you are not on the beta channel
  361. SamWhited oh, I thought it was already out, nevermind then
  362. SamWhited yah, I think the beta group didn't like my Google Apps account or something? I can't remember
  363. daniel > oh, I thought it was already out, nevermind then So did I 😀
  364. SamWhited hah, that explains it
  365. Guus has that / _ italics vs underline discussion come to an end?
  366. moparisthebest the problem with opt-in (client sending 'this is styled') is how would a client know I meant *bold*, that's sorta the whole point
  367. SamWhited Guus: I'm not sure. I didn't hear any compelling reason to change it other than one or two XMPP clients were doing / aleady, so I didn't, but if it's what the community wants I'm happy to do so.
  368. moparisthebest Guus, never
  369. SamWhited But I felt that didn't outweigh the fact that most other messengers seemed to be doing _ already and that _ has meant italics since the days of typewriters
  370. Guus I was discussing it with some frontend-oriented colleagues. They basically said: "Both underlining and italic are used to express emphasis. Never allow underlining for anything else than hyperlinks. Underlining has it's origin with typewriters, that (mechanically) didn't have skewed letters."
  371. SamWhited oh yah, I think you mentioned that; that seems like a good enough reason not to add underlines and to keep _ for italics to me.
  372. Guus is it an idea to simply define both as "emphasis" and let the client use whatever they prefer?
  373. lumi has joined
  374. SamWhited I defined it that way originally, where actually doing italics was a MAY; it's a SHOULD now, but I could be persauaded to go back.
  375. moparisthebest so do you support /this/ for italics too?
  376. SamWhited I just thought it made more sense to strive for consistency.
  377. Guus I personally prefer _ for italics - but most historical usage implies underline.
  378. moparisthebest I'm not actually sure where that comes from
  379. SamWhited There is of course nothing stopping clients from also supporting /this/, it just won't be as consistent
  380. SamWhited The typewriter historical usage implies italics, just not until you actually go to typeset it… maybe we should have a timer and it should randomly change into italics!
  381. moparisthebest does the XEP say both or not though
  382. SamWhited The XEP doesn't mention /
  383. moparisthebest I don't know the answer as to whether it should or not
  384. SamWhited I also thought it was likely that / would collide with paths
  385. Guus using / for markup is annoying, if your text has URLs (the stuff that ironically, requires an underline in rendering...)
  386. SamWhited /this/is/a/path/ would be italisized under the current rules
  387. SamWhited or "this" and "a" would anyways
  388. lumi has left
  389. moparisthebest URLs wouldn't
  390. SamWhited just "this", rather.
  391. moparisthebest a folder file path would and a file path would not
  392. Guus meh, perhaps it's best to just go with something and stop discussing :)
  393. moparisthebest at least for me that falls under who cares territory
  394. lumi has joined
  395. SamWhited It seems like there is a slight upside to using _ over /, so unless someone *really* comes up with a compelling reason I'll probably leave it as is
  396. SamWhited Although, at this point I'm not even sure if this will be accepted so ¯\_(ツ)_/¯
  397. moparisthebest I have nothing compelling :) just that I've always done /italics/ and gajim does it too
  398. moparisthebest it doesn't matter
  399. SamWhited yah, I like /italics/ pretty well too
  400. Guus yeah, hence my suggestion to define _ as well as / as 'emphasis' and throw consistency out of the window.
  401. lumi has joined
  402. Guus not sure if it's a fair tradeoff though
  403. SamWhited It doesn't seem worth it to me
  404. moparisthebest what's 'emphasis' ? bold or italics?
  405. Guus emphasis is typically expresses with underline or italics
  406. Guus ... but your quesion alone proves that it's a bad idea :)
  407. SamWhited I call it "bold" and "italics" right now in the protoxep, but they're both a SHOULD. Maybe I should merge those sections and say that they're different types of "emphasis", someone asked for it and I said I would, I just didn't want to make the change unless it was accepted (although now I've already done more work, might as well do a bit more)
  408. moparisthebest to me, obviously, 'emphasis' is unclear so I'd say bold/italics etc
  409. moparisthebest if the only argument is 'accessible' clients well they have to decide the difference anyway so
  410. moparisthebest there isn't a XEP police going you translated that to voice wrong
  411. daniel /this/is/a/path/ would emphasize the whole thing
  412. daniel Because the inner / will be ignored
  413. Ge0rG paths are important, they need emphasis.
  414. daniel With the PR SamWhited just made
  415. daniel Not with the published rules
  416. moparisthebest but I think /this/is/a/path/to/a/file would not emphasize anything right?
  417. moparisthebest because only folders are important, not files
  418. daniel moparisthebest: yes
  419. moparisthebest :)
  420. Ge0rG so directories are more important than files.
  421. moparisthebest yep
  422. SamWhited daniel: I don't think the change I made affects that one will it?
  423. daniel oh you are right
  424. daniel it will emphasize /this/
  425. daniel with both the old and the new rules
  426. daniel still not cool though. and a reason not to use / as a keyword
  427. moparisthebest what if my OS uses _ as a path seperator, then I'm back to the same problem
  428. jubalh has joined
  429. moparisthebest all of these messenger silently changes my send text is a problem I've always had in every client
  430. moparisthebest I wish they followed these rules where at least the characters were left in
  431. moparisthebest that fixes everything, so in my opinion what actually gets bolded/etc doesn't really matter
  432. moparisthebest try pasting code in 'lync' or 'skype for business' for example, it's a nightmare
  433. Guus whatsapp nicely fades the keywords a little, but keeps them in place
  434. moparisthebest perfect imho
  435. jjrh has left
  436. jubalh has left
  437. jubalh has joined
  438. jjrh has left
  439. jjrh has left
  440. jjrh has left
  441. ralphm has left
  442. jjrh has left
  443. daniel has left
  444. arc has left
  445. arc has joined
  446. daniel has left
  447. jjrh has left
  448. jjrh has left
  449. arc has left
  450. arc has joined
  451. jubalh has left
  452. Ge0rG has left
  453. sonny has left
  454. sonny has joined
  455. sonny has left
  456. sonny has joined
  457. sonny has joined
  458. sonny has joined
  459. Guus SamWhited: what about nested formatting? formatting in code blocks is likely unwanted, but what about in quotations?
  460. SamWhited Guus: It's allowed by the spec
  461. ThurahT has left
  462. Tobias has joined
  463. Guus "Block quotes may contain any child block, including other quotations"
  464. Guus I misread that as "may contain other quotations"
  465. SamWhited I probably also need to define the block/span thing better
  466. arc has left
  467. arc has joined
  468. Guus You're not mentioning hyperlinks - but I'd expect that most clients that do styling, would also make those clickable (and give them corresponding style). Maybe mention that?
  469. SamWhited I thought about it, but I didn't want to formally specify those (same with lists) because it's just something I'd expect clients to do by themselves and it's not really the same thing as the other indicators
  470. sonny has joined
  471. ThurahT has joined
  472. Lance has joined
  473. sonny has joined
  474. sonny has joined
  475. SamWhited Maybe just a quick mention to note that most clients probably will want to also auto-link hyperlinks
  476. Guus SamWhited: links shouldn't be rendered in preformatted blocks though.
  477. SamWhited and that lists were left off because users can type "1." easily enough
  478. Guus I'd not mention lists at all, I think.
  479. SamWhited I don't know if it matters if lists are rendered in preformatted blocks or not, but that does seem worth mentioning one way or another.
  480. arc has left
  481. Arc has joined
  482. SamWhited Even if it's just to say "clients may want to consider this and whether they want it or not"
  483. SamWhited Thanks!
  484. Guus ... I'm wondering if the adoption rate of the XEP would be significantly higher if you'd forget about blocks completely, and do spans only.
  485. Guus (that's an elaborate way to admit that I'm a lazy client dev)
  486. SamWhited I wouldn't be against that, although I think the blocks aren't very difficult to implement either. Did you run into any trouble while playing with it?
  487. Guus SamWhited: not 'trouble', but it does require me to rewrite parts of the displaying code. Things are easier when I only need to concern myself with single lines.
  488. Guus I quite dislike implementing stuff that has all kind of exceptional cases "if then do that except for when this is that"
  489. Guus the spans are already complex. Having to think of nesting spans or blocks in other blocks - meh, I'd rather fix another bug. :)
  490. Guus as I said, lazy.
  491. Guus also, preformatted blocks add little value for me, personally (I can see how they could be useful, but I'd much rather have people use a service like pastebin, isntead of cluttering up my MUC)
  492. Guus blockquotes could be useful to an extend, but the XEP would be interesting in itself without it.
  493. arc has joined
  494. Guus also: people in open_chat now are experimenting with cowsay in the muc.
  495. SamWhited I thought about making that an easter egg in my little client… if you did ```cowsay it would pipe it through that first and then display
  496. Guus shouldn't block text be mono-spaced?
  497. SamWhited That was the idea
  498. Guus I don't think it mentions that explicitly
  499. SamWhited oops, thanks, I'll add that to my todo as well
  500. SamWhited It mentions it in one of the examples!
  501. SamWhited > This should show up as monospace, preformatted text ⤴
  502. SamWhited Probably need some normative language there
  503. Guus is this valued: ``` hello ```
  504. Guus also, lines with ``` could easily by accident end with some random whitespace - might be good to explicitly allow for that?
  505. SamWhited hmm, no, I just didn't expand that section as much as I thought I did
  506. SamWhited It should only be the sequence "```\n" at the beginning of a line followed by "\n```"
  507. SamWhited I think; I'm not sure how likely accidental use of it would be without that
  508. Guus ```<space>\n
  509. SamWhited why the space?
  510. Guus because people copy/paste stuff sloppy?
  511. SamWhited maybe it should just be any line starting with ``` and anything after it is ignored, then people can shove syntax highlighting hints in there like github does
  512. Guus I've had hell with the import of DER certs, because of a trailing space somewhere. It might be good to be somewhat lenient.
  513. SamWhited yah, makes sense
  514. Guus (then again, I'm leaning towards dropping all of this weird complexity by dropping blocks from the xep completely)
  515. Guus two xeps? Styled spans, Styles blocks?
  516. Guus well, I'm going to pour myself a drink and call it a night :)
  517. Guus will lurk on mobile
  518. Guus g'dnight!
  519. SamWhited I suppose they don't all have to be a must; if the ``` blocks don't provide value for you, it's not like they'll look terrible if someone else sends you one and your client doesn't style it
  520. Ge0rG Can we have a language identifier right after the initial ``` ?
  521. Guus has left
  522. arc has left
  523. arc has joined
  524. SamWhited I don't think I'd want to call it a language identifier specifically, but maybe just say that the start of preformatted blocks is any line that matches ```.*\n and then clients that want to could assume it was a language thing
  525. Ge0rG SamWhited: call it a syntax hint, then it's sufficiently free form
  526. vanitasvitae has left
  527. Lance has joined
  528. jcbrand has joined
  529. Arc it rages on
  530. Valerian has left
  531. SamWhited Arc: It's all part of my secret plan to not be re-elected next term.
  532. Guus We'll punish you by reelecting you anyways.
  533. Valerian has joined
  534. Arc its true.
  535. Arc idk tho, 5 people must be elected to council.
  536. Arc you're easily one of the most qualified
  537. SamWhited heh, thanks… drat though, I guess I'll have to think up more controversial proposals to create right before the election
  538. efrit has joined
  539. jubalh has joined
  540. Kev I don't *think*, although I might misremember, that all the slots have to be filled.
  541. efrit has left
  542. efrit has joined
  543. pep. has joined
  544. efrit has left
  545. efrit has joined
  546. efrit has left
  547. efrit has joined
  548. jubalh has left
  549. jubalh has joined
  550. jjrh has left
  551. jubalh has left
  552. jubalh has joined
  553. jjrh has left
  554. jubalh has left
  555. jubalh has joined
  556. jubalh has left
  557. jubalh has joined
  558. Zash has left
  559. Valerian has left
  560. SamWhited has left
  561. jubalh has left
  562. jubalh has joined
  563. SamWhited has left
  564. jjrh has left
  565. jubalh has left
  566. jubalh has joined
  567. Zash has left
  568. marc has left
  569. jubalh has joined
  570. jubalh has joined
  571. jjrh has left
  572. jjrh has left
  573. jere has joined
  574. jubalh has left
  575. jubalh has joined
  576. jere has joined
  577. Valerian has joined
  578. jere has left
  579. jere has joined
  580. jubalh has left
  581. jubalh has joined
  582. uc has joined
  583. Zash has left
  584. uc has joined
  585. daniel has left
  586. jubalh has left
  587. jubalh has joined
  588. marc has left
  589. moparisthebest has joined
  590. uc has joined
  591. lovetox has left
  592. lovetox has joined
  593. jubalh has left
  594. jcbrand has left
  595. lovetox has left
  596. la|r|ma has left
  597. la|r|ma has joined
  598. daniel has left
  599. jjrh has left
  600. daniel has left
  601. daniel has joined
  602. Ge0rG has joined
  603. jere has left
  604. Zash has left
  605. SamWhited has joined
  606. SamWhited has joined
  607. Guus has left
  608. goffi has left