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


  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.


  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.


  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


  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


  525. jonasw


  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


  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


  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


  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


  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


  662. jonasw

    oh god

  663. jonasw


  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


  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


  704. jonasw

    like we’ve been doing it with <xhtml-im/>

  705. Zash

    multipart/alternative basically

  706. jonasw


  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


  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


  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


  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


  827. jonasw

    probably not a good choice since probably underspecified

  828. jonasw

    but yeah, that’s the idea

  829. Zash


  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