XSF Discussion - 2017-10-14

  1. Ge0rG has left
  2. Kev has left
  3. dwd has left
  4. Ge0rG has left
  5. Guus has left
  6. Guus has left
  7. Ge0rG has left
  8. efrit has left
  9. Valerian has left
  10. Guus has joined
  11. goffi has left
  12. Ge0rG has left
  13. daniel has left
  14. sonny has left
  15. sonny has joined
  16. Valerian has joined
  17. daniel has left
  18. daniel has joined
  19. Guus has left
  20. Guus has joined
  21. nyco has left
  22. nyco has joined
  23. Ge0rG has left
  24. alacer has left
  25. alacer has joined
  26. daniel has left
  27. Guus has left
  28. uc has joined
  29. uc has left
  30. daniel has joined
  31. dwd has left
  32. Ge0rG has left
  33. Ge0rG has left
  34. uc has joined
  35. alacer has joined
  36. alacer has joined
  37. Ge0rG has left
  38. uc has left
  39. arc has joined
  40. Ge0rG has left
  41. lskdjf has left
  42. stefandxm has left
  43. arc has left
  44. arc has joined
  45. alacer has joined
  46. alacer has joined
  47. Ge0rG has left
  48. uc has joined
  49. vanitasvitae has joined
  50. Ge0rG has left
  51. Guus has joined
  52. Valerian has left
  53. daniel has left
  54. alacer has left
  55. daniel has joined
  56. Valerian has joined
  57. arc has left
  58. arc has joined
  59. uc has joined
  60. Ge0rG has left
  61. alacer has joined
  62. daniel has left
  63. daniel has joined
  64. stefandxm has joined
  65. dwd has left
  66. Ge0rG has left
  67. uc has joined
  68. stefandxm has left
  69. tux has joined
  70. lumi has left
  71. waqas has joined
  72. Ge0rG has left
  73. arc has left
  74. arc has joined
  75. arc has left
  76. arc has joined
  77. arc has left
  78. arc has joined
  79. arc has left
  80. arc has joined
  81. Ge0rG has left
  82. arc has left
  83. arc has joined
  84. uc has joined
  85. jere has joined
  86. jere has joined
  87. Ge0rG has left
  88. Ge0rG has left
  89. Ge0rG has left
  90. matlag has left
  91. lskdjf has joined
  92. arc has left
  93. arc has joined
  94. Guus has left
  95. uc has joined
  96. Ge0rG has left
  97. SamWhited has left
  98. Guus has joined
  99. Guus has left
  100. jere has left
  101. Guus has joined
  102. Ge0rG has left
  103. Ge0rG has left
  104. uc has left
  105. Guus has left
  106. waqas has left
  107. stefandxm has joined
  108. SamWhited has left
  109. Ge0rG has left
  110. Guus has joined
  111. Guus has left
  112. stefandxm has left
  113. Ge0rG has left
  114. uc has joined
  115. Valerian has left
  116. Ge0rG has left
  117. uc has joined
  118. Ge0rG has left
  119. Syndace has joined
  120. Syndace has joined
  121. jubalh has joined
  122. Guus has joined
  123. Ge0rG has left
  124. some1namednate has joined
  125. some1namednate has left
  126. uc has joined
  127. ralphm has left
  128. jubalh has joined
  129. Ge0rG has left
  130. Ge0rG has left
  131. valo has joined
  132. uc has joined
  133. daniel has left
  134. la|r|ma has joined
  135. stefandxm has joined
  136. Tobias has joined
  137. ralphm has left
  138. stefandxm has left
  139. Ge0rG has left
  140. dwd has left
  141. edhelas has left
  142. uc has joined
  143. ralphm has left
  144. Ge0rG has left
  145. lovetox has joined
  146. Ge0rG has left
  147. la|r|ma has joined
  148. lovetox has left
  149. uc has joined
  150. lskdjf has joined
  151. Ge0rG has left
  152. goffi has joined
  153. daniel has left
  154. Syndace Can a client respond with an internal-server-error if something internal goes wrong when handling a request? The "server" part makes me unsure.
  155. MattJ Heh
  156. MattJ Do you have a specific case in mind?
  157. MattJ or is this just a "is it possible"?
  158. Syndace Im currently coding a client for fun and I have a situation where something internal may fail and I'm wondering what to respond in that case. To make it more specific: Before I send a stanza as response I validate it using the XML schema files and some additional logic. What do I do if the validation fails? I have to anwser something to iq request..
  159. Syndace Now that I think about it, maybe I should only validate incoming stanzas and not outgoing ones. The receiving entity can't expect valid stanzas anyway and has to validate itself.
  160. Ge0rG has left
  161. Syndace I just thought it would be cool to make sure what I'm sending is valid.
  162. MattJ Isn't that bad-request?
  163. MattJ Oh, sorry, I see what you're saying
  164. MattJ Maybe undefined-condition with a custom error would be appropriate here
  165. MattJ There's not much the remote party can do about it in any case
  166. jubalh has joined
  167. valo has joined
  168. Syndace Hmm the undefined-condition should be used in application-specific cases
  169. Syndace I mean, should is not must but it does not feel clean either
  170. valo has joined
  171. Syndace I think I'll use my internal validation to display warnings/errors and send the invalid stanza anyway. At least this way finding and debugging invalid stanzas is easy.
  172. mimi89999 has left
  173. stefandxm has joined
  174. Ge0rG has left
  175. uc has joined
  176. stefandxm has left
  177. Ge0rG has left
  178. uc has joined
  179. Alex has joined
  180. Syndace has left
  181. Guus has left
  182. daniel has joined
  183. sonny has joined
  184. sonny has joined
  185. valo has joined
  186. daniel has left
  187. Ge0rG has left
  188. valo has joined
  189. Guus has left
  190. dwd has left
  191. dwd has left
  192. dwd has left
  193. dwd has left
  194. mimi89999 has joined
  195. Ge0rG has left
  196. dwd has left
  197. uc has joined
  198. dwd has left
  199. dwd has left
  200. Guus has left
  201. dwd has left
  202. Ge0rG has left
  203. valo has left
  204. valo has joined
  205. Alex has left
  206. dwd has left
  207. Flow has joined
  208. Alex has joined
  209. dwd has left
  210. Ge0rG has left
  211. Flow Syndace, whatever you do, it's often a good idea to include a human readable english text into the error response which provides more information about what whent wrong. But only if that information does not cause some sort of security leak
  212. Alex has left
  213. Ge0rG has left
  214. xnyhps has joined
  215. Alex has joined
  216. Syndace Flow, most of the errors are self explanatory, aren't they? Often the XEPs define semantics for error conditions. I like to avoid decisions that might cause security leaks.
  217. valo has joined
  218. Guus has left
  219. Ge0rG has left
  220. valo has joined
  221. stefandxm has joined
  222. winfried has joined
  223. jubalh has joined
  224. emxp has left
  225. emxp has joined
  226. jere has joined
  227. valo has joined
  228. tux has left
  229. valo has joined
  230. stefandxm has left
  231. Ge0rG has left
  232. Alex has left
  233. dwd has left
  234. daniel has joined
  235. stefandxm has joined
  236. Alex has joined
  237. Alex has left
  238. Ge0rG has left
  239. dwd has left
  240. dwd has left
  241. dwd has left
  242. dwd has left
  243. dwd has left
  244. dwd has left
  245. Ge0rG has left
  246. Flow Syndace, In my experience it's quite the opposite. For example internal-server-error: It's often usefull to know the cause of the error
  247. Syndace Why does the client have to know which internal server error occured?
  248. Syndace Nevermind, there are probably cases where additional info makes a lot of sense. I'll overthink which of my generated errors could benifit from additional info.
  249. Flow Syndace, so that it can report the error condition back to the server operator
  250. Syndace The server operator should really log internal errors himself..
  251. Flow and he will very likely do that
  252. lumi has joined
  253. jubalh has left
  254. Ge0rG has left
  255. Syndace has left
  256. mimi89999 has left
  257. zinid Syndace: sometimes a user sees an error and don't bother support, because the error is temporary, for example, database failure
  258. jere has joined
  259. Ge0rG has left
  260. dwd has left
  261. tux has left
  262. tux has left
  263. dwd has left
  264. xnyhps has joined
  265. Ge0rG has left
  266. uc has joined
  267. zinid has left
  268. stefandxm has left
  269. daniel has left
  270. efrit has joined
  271. Ge0rG has left
  272. daniel has joined
  273. daniel has left
  274. tux has left
  275. tux has left
  276. dwd has left
  277. Ge0rG has left
  278. dwd has left
  279. winfried has joined
  280. nyco has left
  281. nyco has joined
  282. dwd has left
  283. Ge0rG has left
  284. dwd has left
  285. lovetox has joined
  286. tux has left
  287. daniel has joined
  288. Ge0rG has left
  289. jere has left
  290. valo has joined
  291. xnyhps has joined
  292. pep. jonasw, in your last email to the XHTML-IM thread, I fail to see how having a protocol break from xml to xml would fix OP's issue. I'd like to keep XML as well but if you do that you're still open to the same vulnerabilities
  293. jonasw pep., yes, I’m not convinced that XML helps, which is what I wrote I think?
  294. pep. let me reread
  295. jonasw actually I’m even posting an example of how this might be exploited
  296. jonasw yeah, I probably should’ve added something like "I *think* that […], but I’m not convinced that clients will do the right thing by default, which is why we’re trying to get rid ofXHTML-IM in the first place." will clarify on-list
  297. pep. :)
  298. pep. But,
  299. pep. hmm, yes
  300. stefandxm has joined
  301. pep. yeah, saying "We are now using this NS instead" won'T fix the problem of people not validating
  302. pep. So if people want a change, XML is a no-no
  303. pep. And so is markdown because some implementation (most?) accept html
  304. jonasw markdown is out even if only because it’s not extensible
  305. pep. Right
  306. pep. But I would go further and say, for XML, it's a no-no for web clients at all.
  307. pep. Because people are putting stuff everywhere without validating and that creates vulnerabilities :)
  308. pep. Not just in <body>
  309. pep. Even if it's the most obvious
  310. jonasw has left
  311. Kev has left
  312. daniel has left
  313. Flow has left
  314. Flow has joined
  315. stefandxm has left
  316. Ge0rG has left
  317. daniel has joined
  318. daniel has left
  319. daniel has joined
  320. Tobias has joined
  321. Tobias has joined
  322. Ge0rG has left
  323. daniel has left
  324. Syndace has left
  325. valo has joined
  326. daniel has joined
  327. dwd has left
  328. daniel has left
  329. Ge0rG has left
  330. waqas has joined
  331. ralphm has joined
  332. arc has left
  333. arc has joined
  334. arc has left
  335. arc has joined
  336. goffi pep.: that is issue with client dev, validating untrusted input is the first thing to learn when you do web dev (even not web actually)
  337. dwd has left
  338. goffi pep.: (disclaimer: I'm not claming that my web software are failproof, security issue can and will happen to most software)
  339. daniel has joined
  340. pep. goffi, yeah, look at my last email on the list
  341. Zash Can't have nice things!
  342. winfried has joined
  343. dwd has left
  344. Ge0rG has left
  345. dwd has left
  346. pep. I should have put something like "unlike OP suggests" at the end of that sentence
  347. dwd has left
  348. efrit has left
  349. dwd has left
  350. dwd has left
  351. Guus has left
  352. daniel has left
  353. dwd has left
  354. dwd has left
  355. Ge0rG has left
  356. Guus has left
  357. dwd has left
  358. jubalh has joined
  359. dwd has left
  360. jubalh has left
  361. dwd has left
  362. Guus has left
  363. ralphm has joined
  364. arc has left
  365. arc has joined
  366. stefandxm has joined
  367. intosi has joined
  368. jere has joined
  369. Ge0rG has left
  370. arc has left
  371. arc has joined
  372. SamWhited has left
  373. la|r|ma has joined
  374. jubalh has joined
  375. stefandxm has left
  376. SamWhited has left
  377. arc has left
  378. arc has joined
  379. arc has left
  380. arc has joined
  381. Ge0rG has left
  382. arc has left
  383. ralphm has joined
  384. dwd has left
  385. arc has joined
  386. dwd has left
  387. arc has left
  388. arc has joined
  389. dwd has left
  390. arc has left
  391. arc has joined
  392. Valerian has joined
  393. arc has left
  394. arc has joined
  395. valo has joined
  396. arc has left
  397. arc has joined
  398. dwd has left
  399. dwd has left
  400. Ge0rG has left
  401. dwd has left
  402. arc has left
  403. arc has joined
  404. dwd has left
  405. dwd has left
  406. daniel has left
  407. uc has joined
  408. arc has left
  409. lskdjf has joined
  410. nyco has left
  411. nyco has joined
  412. arc has joined
  413. valo has joined
  414. arc has left
  415. arc has joined
  416. daniel has joined
  417. la|r|ma has left
  418. la|r|ma has joined
  419. Ge0rG has left
  420. tux has joined
  421. jubalh has left
  422. arc has left
  423. arc has joined
  424. Guus has joined
  425. arc has left
  426. Ge0rG has left
  427. dwd has left
  428. arc has joined
  429. Guus has left
  430. Guus has joined
  431. dwd has left
  432. arc has left
  433. arc has joined
  434. dwd has left
  435. arc has left
  436. Guus has left
  437. dwd has left
  438. dwd has left
  439. arc has joined
  440. jubalh has left
  441. Guus has joined
  442. ralphm has joined
  443. dwd has left
  444. Ge0rG has left
  445. dwd has left
  446. jubalh has joined
  447. dwd has left
  448. dwd has left
  449. jubalh has joined
  450. dwd has left
  451. la|r|ma has left
  452. la|r|ma has joined
  453. dwd has left
  454. jabberatdemo has joined
  455. Ge0rG has left
  456. jabberatdemo has left
  457. dwd has left
  458. lskdjf has left
  459. lskdjf has joined
  460. tux has left
  461. tux has joined
  462. dwd has left
  463. stefandxm has joined
  464. arc has left
  465. arc has joined
  466. dwd has left
  467. dwd has left
  468. dwd has left
  469. arc has left
  470. arc has joined
  471. jjrh has left
  472. dwd has left
  473. jubalh has left
  474. Ge0rG has left
  475. arc has left
  476. jjrh has left
  477. arc has joined
  478. stefandxm has left
  479. ralphm has joined
  480. arc has left
  481. arc has joined
  482. jubalh has joined
  483. jjrh has left
  484. jjrh has left
  485. Ge0rG has left
  486. jjrh has left
  487. arc has left
  488. arc has joined
  489. arc has left
  490. arc has joined
  491. Ge0rG has left
  492. arc has left
  493. jjrh has left
  494. arc has joined
  495. Guus has left
  496. valo has joined
  497. Valerian has left
  498. daniel has left
  499. valo has joined
  500. daniel has left
  501. daniel has joined
  502. la|r|ma has left
  503. la|r|ma has joined
  504. Valerian has joined
  505. goffi jonasw: thanks for your last message, I kind of feel alone when I don't even understand while people are still talking about markdown after the debate we had.
  506. goffi s/while/why/
  507. jonasw I’m assuming some good faith (i.e. too long other thread and people didn’t read)
  508. goffi it's possible, I've had the same thing during OMEMO flamewar, hard to follow when you arrive after the battle.
  509. Zash I kinda wanna pin the entire xhtml-im problem on whoever invented .innerHTML
  510. jonasw Zash, .innerHTML isn’t the issue with XHTML-IM
  511. Valerian has left
  512. jonasw XHTML-IM breaks not only if you use .innerHTML, it also breaks if you use appendChild
  513. Valerian has joined
  514. Zash Blame the web!
  515. valo has joined
  516. edhelas Mardown in XMPP, seriously ?!
  517. Ge0rG has left
  518. edhelas i'm not against Markdown, but looks like we are trying to solve a problem by changing it
  519. valo has joined
  520. Zash No, Markdown being defined as a superset of HTML rules it out
  521. jonasw dwd gave a proper definition of what he thinks should be markdown for IM.
  522. jonasw more or less proper.
  523. jonasw I’m tired of asking how to emphasize "Trainer*Innen" with that though.
  524. Zash \bold{Trainer*Innen}
  525. jonasw uhhh
  526. jonasw TeX in IM
  527. goffi one of the problem is that people always thing about their own use case
  528. jonasw that’s execellent
  529. jonasw it’s even turing complete!
  530. Zash (I don't actually know TeX, wild guess)
  531. jonasw it’d be \emph{} or \textbf{}, depending on whether you want emphasis (italics) or actual boldface
  532. Zash Is this Creole? http://www.wikicreole.org/wiki/Creole1.0
  533. goffi XMPP message can also be "normal" with a subject and potentially long, not necessarily a line in a MUC/MIX, and embedded images can be useful there (think about email gateway)
  534. jonasw goffi, agreed
  535. jonasw Zash, yes
  536. goffi I'll take a break on standard@ for tonight, I have written enough there today :)
  537. Zash Ok, me, a naive web developer does a simple string replace and puts the result as .innerHTML
  538. waqas You are doing a simple string replace? That's naive web developer lvl3
  539. edhelas I append my HTML like I append my variables in my SQL requests, using concatenation
  540. goffi why we don't use mirc colors in <body>? Looks like a good idea (as good as using markdown)
  541. jonasw goffi, those use control codes in the 0x00..0x1f range right? you can’t send those over XML
  542. goffi jonasw: easy, we just have to add \uxxxx
  543. Ge0rG has left
  544. goffi we can even use ANSI escape code like this, will be great
  545. dwd goffi, Note that I'm explicitly suggesting we *keep* XHTML embedding, but just avoid it being the go-to way of adding bold and italics in IM messages.
  546. jonasw dwd, I’m not convinced that this is a good thing.
  547. Valerian has left
  548. jonasw this just introduces fragmentation we can avoid.
  549. Zash Is it bold and italics and other *styling* people want?
  550. dwd jonasw, I don't really want to specify a whole new document definition.
  551. Zash If so, bringing back <font> could work
  552. jonasw dwd, why not?
  553. dwd Zash, For IM, you mean? I think people want emphasis (mostly just *bold*) and preformat is handy, mostly because code-like stuff is about the only time you use * and / in IMs.
  554. Zash XFONT-IM, you get <font> with a bunch of attributes that map roughtyl to CSS properties
  555. jonasw dwd, as I said. Trainer*Innen is a legit german word
  556. arc has left
  557. arc has joined
  558. goffi dwd: for <message> ? I didn't got that, I though you were suggesting the separate XHTML XEP (which is a good idea) only for blogging
  559. Zash ~$ pandoc <<< '*Trainer*Innen*' <p><em>Trainer</em>Innen*</p>
  560. Zash Palm -> face
  561. goffi but sorry, movie time, will read updates later
  562. jubalh has left
  563. Zash jonasw: You type ^B Trainer*Innen ^B in your client. The client translates the input into protocol and sends it.
  564. Zash Or click the [B] button
  565. jonasw Zash, sure, but if the protocol doesn’t support it, because it’s mardown?
  566. Zash ~$ pandoc -f html -t markdown <<< '<b>Trainer*Innen</b>' **Trainer\*Innen**
  567. jonasw nice
  568. jonasw at this point we can simply use a proper format, because nobody will learn that syntax for themselves.
  569. dwd jonasw: Either (a) you can't. (b) We define bold toggle as being on a word break. (c) We use doubled asterisks as an escape.
  570. jonasw dwd, see above
  571. jonasw "you can’t" is a terrible answer
  572. intosi has joined
  573. Zash dwd: Should we really demand end-users learn some syntax?
  574. jonasw "bold toggle on word breaks" moves the "you can’t" answer to other cases
  575. jonasw "doubled asterisks as an escape", see what Zash says
  576. dwd No, it's not. You also cannot embed images. This is OK. There are lots of edge cases. Imagine how many there's going to be on a complete document markup language.
  577. Zash ~$ pandoc <<< '**Trainer*Innen**' <p>**Trainer*Innen**</p>
  578. Zash scratches head
  579. jonasw dwd, of course. which is why I suggest to have a language we can easily extend instead of some markdown-ish markup.
  580. jonasw that easily allows us to take care of edge-cases and new use-cases later
  581. jonasw without breaking everything again
  582. Ge0rG has left
  583. Valerian has joined
  584. uc Don't forget S̶t̶r̶i̶k̶e̶ t̶h̶r̶o̶u̶g̶h̶
  585. zinid lol, guys, you will never come to agreement :)
  586. zinid is reading another round of xhtml-im ranting
  587. Zash I see. Then there can only ever be conflict between us.
  588. valo has joined
  589. Ge0rG has left
  590. daniel has left
  591. remko has joined
  592. stefandxm has joined
  593. remko i shall refrain from suggesting to use docbook markup
  594. jonasw remko, how about groff?
  595. Zash I actually went to look through a bunch of existing XML formats yesterday
  596. Zash There's a bunch
  597. remko for the subset that i think we want (bold, italic, code), i don't think it matters really.
  598. jonasw remko, depends on who "we" includes, "bold, italic, code" doesn’t cut it.
  599. remko 'we' => '99% of the use cases' ;-)
  600. Zash But I'm not sure any XML format will make it difficult enough to do the wrong thing
  601. jonasw Zash, I can see people not sanitising attributes and simply changing local names, unfortunately.
  602. Zash Yup
  603. remko jonasw: looking at all the IM clients out there, bold, italic, and underline are the only thing they seem to support. I haven't heard people complaining about this limitation.
  604. Zash Don't forget iChat users with colors
  605. remko it'll boil down to whether we want a structured format or a non-structured format. Personally, I'm torn. I used to lean one way, but am now leaning the other.
  606. jonasw remko, you haven’t heard me then ;-)
  607. jonasw remko, at least there’s also blockquote
  608. remko jonasw: I like blockquote. But there is a case to be made that this should be replaced by a snippet payload.
  609. Zash remko: semantics vs style, xml vs not xml, structured vs not
  610. Zash Any more considerations?
  611. remko Zash: Messages doesn't even support markup i just noticed.
  612. jonasw remko, and how’d you encode those in snippets?
  613. jonasw do we want full-blown HTML snippets, with all the vulnerabilities that has?
  614. remko nope. Just <pre>.
  615. jonasw do you confuse blockquote with code?
  616. remko i.e. a snippet is just rendered as a <pre>, no markup.
  617. jonasw https://d2k1ftgv7pobq7.cloudfront.net/meta/u/res/images/db8a72d486e14d6fe249b6a80962b69b/slack-webdesign-cropped.jpg
  618. remko jonasw: i did confuse both
  619. jonasw here’s one example of inline images, links, something like headings in an IM client
  620. Bunneh has joined
  621. Ge0rG has left
  622. Zash jonasw: Isn't that more like a referece?
  623. remko jonasw: for blockquote, the question is whether this is really a part of the message or not. Could be a reference to something that you happen to render this way.
  624. jonasw Zash, sure, it should be a reference in addition, and ideally the markup should reference the reference to make things super-clear
  625. jonasw but having every client support every type of reference isn’t a good idea I think
  626. Zash jonasw: {xep attaching} maybe?
  627. Bunneh jonasw: XEP-0367: Message Attaching (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0367.html
  628. jonasw wouldn’t it make more sense to have references in addition rather than instead of content?
  629. remko i don't think the bulk of 'modern' (non-XMPP) IM clients out there put images and links in their messages. They use autolinking and unicode replacement object, and attach the immage as an external object.
  630. edhelas the issue with XHTML-IM are also things like images
  631. jonasw remko, sure, you need to mark up where the image goes though
  632. Zash Do modern messagers even do actual in-line images?
  633. remko jonasw: hence the unicode replacement object
  634. jonasw which is again some kind of markup
  635. Zash As opposed to messages that consist only of an image
  636. remko Zash: i wonder about that. I have seen them use the unicode replacement object, but am not sure if they actually use it for placement.
  637. remko (talking about Messages concretely)
  638. remko if you look in the Messages DB, i see messages that came with an image as { "text": "\uFFFC Hi there", "attachments": [ { "image": "..."}]} (or some sorts)
  639. remko but as i said, i'm not sure if they actually use this, or just always render the image at the front/back of the message.
  640. jonasw remko, that looks like something which grew historically because they don’t have proper markup.
  641. remko might be
  642. remko in any case, i would rather not have any markup for images than <img> tags.
  643. jonasw what’s wrong wtih <img/> tags or their equivalent in any other markup?
  644. remko it's a slippery slope to too complex document. It's also ambiguous how text should flow around this stuff etc. If you don't allow it, it's less ambiguous
  645. remko just render is at a separate image. That's also how people feel IM should work i think.
  646. Zash remko: Like a separate type of message box?
  647. remko yes
  648. jonasw I think there’s a lot of value for that type of rich messages.
  649. Zash Yeah I think most things I've seen do that
  650. jonasw possibly not images, but other semantic markup
  651. remko jonasw: i'm not saying there's no use case in XMPP for rich messages with full document markup. IM is just not one IMO.
  652. jonasw talking about IM.
  653. jonasw not necessarily human-generated messages though
  654. remko those should perhaps be a different thing then.
  655. jonasw why make it a different thing?
  656. remko slack also distinguishes between bot messages and human-written messages.
  657. remko you can't do anything beyond bold, italic, and underline as a person.
  658. jonasw but why does the transport need to be different?
  659. stefandxm has left
  660. jonasw sharing the transport format for whatever markup we’re doing leads to better interoperability
  661. Zash https://xmpp.org/extensions/inbox/content-types.html
  662. jonasw oh god
  663. jonasw type='text/xml'
  664. jonasw I’m in pain now.
  665. remko haven't read the XEP, but saw that pass the mailing list. That sounded like pandora's box to me :)
  666. jubalh has joined
  667. jubalh has left
  668. daniel has joined
  669. nyco has left
  670. jonasw that specific implementation feels bad
  671. jonasw and I’m still not convinced that it’s a good thing to have in any case. This will fragment implementations.
  672. Zash I think someone (could be me) suggested <body>markdown markup here</body><body-content type='markdown'/>
  673. zinid Zash: that's exactly Example 1 from the ProtoXEP
  674. zinid <message from='person1@example.org/34892374' to='person2@example.org/938089023' type='chat'> <body>**Note:** This message is very important.</body> <content type='text/markdown' xmlns='urn:xmpp:content'/> </message>
  675. Zash zinid: ah, must have scrolled past that
  676. jonasw zinid, yes, but an empty <content/> has a different meaning than a <content> with text content, which is super awkward.
  677. jubalh has joined
  678. zinid jonasw: yep, I don't think we need this crap
  679. nyco has joined
  680. Zash I actually think it's awkward with <body/><xhtml-im/>
  681. zinid still, it's unclear what should a client render if it doesn't support the content type?
  682. zinid in the case of markdown it's obvious, but with another formats/
  683. zinid ?
  684. Zash zinid: if you do this only with formats that are still readable when treated as plain text, it's probably fine
  685. zinid Zash: yes
  686. Zash You probably also wanna have explicit features for formats you understand
  687. jonasw feature discovery doesn’t work in modern IM though.
  688. Zash As in, disco#info features and the whole caps dance
  689. Zash Oh right, we're moving away from the end-to-end thing :/
  690. jonasw let the server handle translation to the different markup types understood by the client!
  691. Zash Ohgod
  692. zinid jonasw: OMEMO guys will not approve :D
  693. daniel has left
  694. jonasw zinid, right
  695. zinid feature discovery won't help in MUCs
  696. jonasw that, too
  697. jonasw or MIXes
  698. Zash or when you switch client and fetch stuff from MAM
  699. Zash or if you use carbons
  700. Zash or ...
  701. jonasw yes, so, that’s not really gonna work.
  702. Zash Can we even do things at all then?
  703. jonasw sure
  704. jonasw like we’ve been doing it with <xhtml-im/>
  705. Zash multipart/alternative basically
  706. jonasw yupp
  707. Zash Do everything at once and let the recipient do what they want :)
  708. nyco has left
  709. nyco has joined
  710. daniel has joined
  711. zinid do I understand correctly: the only concern about xhtml-im is security issues?
  712. jonasw zinid, the "only", yes
  713. jonasw for me at least.
  714. remko no, i don't think that's true
  715. Zash That's why SamWhited wants it dead, no?
  716. remko that's what initially triggered the discussion, yes. And it's important, because xhtml-im is very hard to sanitize.
  717. Zash It's too easy to just stick the incoming XML tree into a browser DOM
  718. remko but i think other people don't want XHTML-IM, because it's very unpredictable to render in a chat log.
  719. zinid can we provide testing vectors?
  720. Zash User studies needed
  721. SamWhited I hadn't actually considered the difference between text style and layout before, it was just security for me at first, but now I agree that we need something that's purely style, not layout.
  722. jonasw SamWhited, I think we need something for semantics, not for style.
  723. jonasw (neither for layout by the way)
  724. Zash I actually think normal people will want style rather than semantics
  725. remko semantics for things that don't need layout :)
  726. jonasw emphasis, blockquote, strong emphasis, lists and enumerations, and code at the very least.
  727. remko yes, zash is right
  728. SamWhited jonasw: yes, that's fair, I think I agree with that. I can imagine certain clients render "emphasis" as italics and other bold or something similar.
  729. jonasw SamWhited, that, and also accessibility tools
  730. jonasw like screen readers
  731. jonasw they benefit a lot from semantics.
  732. remko i actually agree with Zash, people don't care about semantics in IM, they care about style.
  733. SamWhited Yes, I think for the most part you'll find they're the same for anything simple though.
  734. jonasw Zash, they think they want style, but they actually want semantics.
  735. remko they want something to be bold, not 'emphasized'
  736. Zash jonasw: That's probably true.
  737. jonasw remko, they want something to be bold to emphasize it
  738. jonasw they don’t think in terms of semantics, but that’s what they want
  739. remko different people have different interpretations of emphasis.
  740. remko if i want something emphasized, i don't want it in italic (even though that's the standard way to emphasize things)
  741. jonasw remko, you’re free to chose strong emphasis then, people make that kind of mistakes all the time.
  742. jonasw it’s still emphasis, and that’s the meaning which is wanted to be conveyed and which is conveyed
  743. SamWhited Although, if I'm a client author I'm going to put a "Bold" button, not an "Emphasis" button and it would be confusing if on one of my other clients the "Bold" button turns out to be italics.
  744. jonasw SamWhited, when you’re saying "purely style", I’m afraid that use-cases like enumerations are excluded though.
  745. Zash has left
  746. remko SamWhited: exactly
  747. jonasw SamWhited, yes of course you wouldn’t label it emphasis ;-). and it should be made clear which defaults apply for the two kinds of emphasis people have (render weak -> italic, strong -> bold; people will choose strong in 99.9% of the cases, that doesn’t matter)
  748. SamWhited yah, nevermind, I juts changed my mind again. Conveying semantics might be nice in some cases, but all I want is the most dead simple thing we can do.
  749. jonasw will all due respect, I wonder whether you might maybe want to consider not only what you want ;-)
  750. remko jonasw: so you're saying that you're offering a bold and italic button, but insist they're using semantics? It has to render the same way on the other side, so i don't think it's semantics anymore.
  751. SamWhited I just gave you the reason why client developers want it.
  752. SamWhited (probably)
  753. jonasw SamWhited, as a client developer, I want to have one markup which covers all things my users are likely to encounter. This includes more complex messages (possibly generated by automated systems, similar to slack integrations or something). And I don’t want to have to support three different tiers of markdown dialects to achieve that.
  754. jonasw I may not offer my users the tools to create, e.g., a three-level nested enumerated list in the interface, because this ain’t a word processor.
  755. Ge0rG has left
  756. Zash People can't use a comma?
  757. SamWhited Wait, what? Who said anything about multiple tiers of markdown dialects?
  758. jonasw Zash, context?
  759. Zash jonasw: lists
  760. jonasw SamWhited, that’s what happens if we go down the route of "we’ll start with some simple text-based markup and oops, then we’ll find out two years later that we also need something to do lists or whatever, so let’s bump the namespace"
  761. jonasw Zash, bullet points, if you will
  762. zinid Zash: lists are easier to read I guess
  763. jonasw much easier
  764. Zash Do peopel use this when talking?
  765. zinid I do sometimes
  766. jonasw Zash, I do ;-). but also, "possibly generated by automated systems"
  767. SamWhited I think that: 1. That's probably not a problem 2. It already works fine
  768. zinid Zash: for example to tell my wife what to buy in a shop ;)
  769. Zash I have found a 𝐁𝐎𝐋𝐃 solution!
  770. jonasw it works fine until you have multiple lines in a bullet (e.g. due to word-wrap) and then it is unreadable, SamWhited,
  771. jonasw it works fine until you have multiple lines in a bullet (e.g. due to word-wrap) and then it is unreadable, SamWhited.
  772. jonasw I would like to quote a few things from the Zen of Python which have been in my mind during this whole "the new markup for XMPP" discussion: Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. […] In the face of ambiguity, refuse the temptation to guess.
  773. jonasw and also, especially since people are now suggesting that they’re creating precedents by implementing things in a wide-spread client: Now is better than never. Although never is often better than *right* now.
  774. Zash dwd: btw, *bold* in markdown isn't bold, but italics :P
  775. jonasw (that, too)
  776. jonasw SamWhited, I really, really don’t understand what the issue is with creating an extensible, very simple markup or re-using one instead of restricting us to a very small set of things.
  777. SamWhited I never said there was a problem with it
  778. jonasw fair.
  779. daniel has left
  780. jonasw I somehow felt you did, but that wasn’t true.
  781. jonasw maybe I mixed up an email somewhere and had that lingering thought somewhere, I apologize.
  782. Zash SamWhited: Do you think any XML based format will be too easy to do the wrong thing with?
  783. SamWhited Zash: I'm not sure, I suspect so, but I have no idea.
  784. zinid Zash: only when you put unescaped cdata into DOM?
  785. SamWhited XMPP doesn't allow CDATA, no?
  786. Zash Question is, where's the cutoff where people will prefer the right thing?
  787. jonasw SamWhited, cdata is any text, actually
  788. zinid SamWhited: well I mean the content of <body/> for example
  789. SamWhited *unescaped CDATA
  790. Zash SamWhited: You are thinking of <![CDATA[ ]]>?
  791. Zash Whatever that's called
  792. SamWhited yah, that
  793. Zash Do we disallow it tho?
  794. zinid no, I meant a text within tags in general
  795. zinid I see no other way how to screw up
  796. jonasw zinid, I have one: let’s say we have a tag <emph/> for emphasis
  797. zinid we can assume that you can screw up during transforming layout element into DOM, but you can screw up this way with any formats
  798. jonasw a client may simply do a translation mapping the emph local name to em for XHTML.
  799. Zash Also wtf unicode has all sorts of 𝗯𝗼𝗹𝗱 𝘁𝗲𝘅𝘁
  800. jonasw and then fail to remove attributes such as onclick="alert('fnord')"
  801. zinid jonasw: yes, but you can do the same with other formats, no?
  802. jonasw not with non-XML formats
  803. jonasw you’d have to actively put attributes in the result
  804. Zash I think non-XML formats may be to easy to just run trough a regex and allow HTML trough
  805. jonasw Zash, depends
  806. jonasw think: [{"text": "some text", "emphasis": "strong"}, {"text": " and now without emphasis"}] -> '<strong>some text</strong> and now without emphasis'
  807. jonasw you can’t regex that in any reasonable way.
  808. Ge0rG has left
  809. jonasw anything in ["text"] will have to be htmlescaped, but otherwise it should be safe.
  810. zinid jonasw: other formats can also posses kinda "attributes" and you can also copy their contents into so evil DOM element blindly, no?
  811. jonasw (now I officially did it. I proposed a JSON-transport for things.)
  812. jonasw zinid, not if none of those attributes reasonably map to any DOM element which is evil
  813. Flow has left
  814. jonasw we shouldn’t be needing any attributes at all, I think
  815. jonasw except maybe class if we do that palette thing
  816. jonasw (okay, href too)
  817. Zash [{"c":[{"c":"bold","t":"Str"}],"t":"Strong"},{"t":"Space"},{"c":"text","t":"Str"}]
  818. jonasw but attributes should be rather rare
  819. Zash ^ actual JSON "markup" format.
  820. jonasw Zash, not sure if that’s some serious markup you found somewhere or if you’re trolli... oh dear
  821. jonasw I don’t know what that does
  822. Zash jonasw: pandoc -t json
  823. jonasw but does it work?
  824. jonasw ah, t is type.
  825. Zash jonasw: It's a JSON dump of the internal parse tree
  826. jonasw right
  827. jonasw probably not a good choice since probably underspecified
  828. jonasw but yeah, that’s the idea
  829. Zash <Strong><Str>bold</Str></Strong><Space/><Str>text</Str>
  830. Kev has left
  831. Zash ~$ pandoc -t native <<< '**bold** text' [Para [Strong [Str "bold"],Space,Str "text"]]
  832. zinid jonasw: if we can map attributes reasonably, can't we do the same for xhtml-im? and then forbid unknown attributes/elements
  833. jonasw zinid, the difference is that one requires action to fail, the other requires inaction.
  834. zinid I don't understand
  835. jonasw of course, XHTML-IM already defines that some attributes are evil and you need to remove them.
  836. jonasw that doesn’t magically make developers do that.
  837. SamWhited Even if they do it, any trivial mistake in the white list logic results in a vulnerability.
  838. jubalh has joined
  839. zinid XML schema?
  840. zinid hides
  841. jonasw zinid, sure, nobody does that.
  842. jonasw it requires action to do that
  843. jonasw getting developers to take action is what’s tricky
  844. zinid yeah, I know
  845. jonasw (if it was only about trivial mistakes, we could provide an audited reference implementation)
  846. jonasw (either based on XML schemas or whatever works in JavaScript)
  847. zinid ok, we refuse xhtml-im, then what?
  848. zinid there are 100500 formats and we can invent others
  849. zinid how to choose?
  850. zinid ah, and we need to make sure there are no potential vulnerabilities, hell yeah
  851. Syndace has left
  852. Guus has joined
  853. jubalh has joined
  854. efrit has joined
  855. zinid regarding markdown: if we don't choose it, then developers will blame us even harder that we don't use "modern" technologies like json or markdown, or rest :)
  856. jonasw zinid, I’m all in for a JSON-based markup
  857. zinid for example, I heard "xmpp is dead if they don't switch to json" and seems like people tend to agree with that
  858. jere has left
  859. jere has joined
  860. dwd has left
  861. uc has joined
  862. Ge0rG has left
  863. dwd has left
  864. daniel has joined
  865. dwd has left
  866. Ge0rG has left
  867. Alex has joined
  868. dwd has left
  869. sonny has joined
  870. dwd has left
  871. Valerian has left
  872. Valerian has joined
  873. Valerian has left
  874. uc has joined
  875. dwd has left
  876. remko has joined
  877. jubalh has left
  878. SamWhited has left
  879. Ge0rG has left
  880. jubalh has left
  881. stefandxm has joined
  882. dwd has left
  883. remko has joined
  884. goffi has left
  885. jonasw has left
  886. dwd has left
  887. jubalh has left
  888. Alex has left
  889. Valerian has joined
  890. remko has joined
  891. remko has left
  892. jonasw has left
  893. jjrh has left
  894. stefandxm has left
  895. efrit has left
  896. arc has left
  897. dwd has left
  898. jjrh has left
  899. jjrh has left
  900. dwd has left
  901. dwd has left
  902. dwd has left
  903. tim@boese-ban.de has joined
  904. jubalh has left
  905. winfried has joined
  906. daniel has left
  907. la|r|ma has left
  908. la|r|ma has joined
  909. Guus has left
  910. jjrh has left
  911. winfried has joined
  912. zinid has left
  913. winfried has left
  914. valo has joined
  915. alacer has left
  916. Ge0rG has left
  917. alacer has joined
  918. stefandxm has joined
  919. Ge0rG has left
  920. alacer has joined
  921. stefandxm has left
  922. jjrh has left
  923. Zash I note that PEP examples doesn't include the 'http://jabber.org/protocol/pubsub' feature. Is that supposed to be implied by <identity category='pubsub' type='pep'/>?
  924. Zash And the last version of PEP changed that section from being to=host to to=account and /some/ unnamed implementations still advertise stuff on the host
  925. dwd has left
  926. Ge0rG has left
  927. daniel has left
  928. Ge0rG has left
  929. daniel has left
  930. alacer has joined
  931. lskdjf has left
  932. daniel has left
  933. lskdjf has left
  934. stefandxm has joined
  935. Valerian has left
  936. Valerian has joined
  937. lskdjf has left
  938. Ge0rG has left
  939. lskdjf has left
  940. lskdjf has left
  941. daniel has left
  942. Valerian has left
  943. Valerian has joined
  944. Ge0rG has left
  945. matlag has left
  946. daniel has joined
  947. Ge0rG has left
  948. moparisthebest Why hasn't anyone taken my bbcode suggestion seriously?
  949. moparisthebest On an actual serious note, there are markdown standards, we could just pick one
  950. moparisthebest http://commonmark.org/ is the best I know of
  951. Ge0rG has left
  952. Guus has joined
  953. SamWhited has left
  954. alacer has joined