XSF Discussion - 2017-10-19


  1. jjrh has left
  2. jjrh has left
  3. jjrh has left
  4. Tobias has joined
  5. uc has joined
  6. sonny has joined
  7. sonny has joined
  8. sonny has joined
  9. sonny has joined
  10. Tobias has joined
  11. efrit has joined
  12. Valerian has left
  13. xnyhps has left
  14. tux has left
  15. tux has joined
  16. vanitasvitae has left
  17. jere has joined
  18. Syndace has joined
  19. jere has left
  20. jere has joined
  21. lumi has left
  22. vanitasvitae has joined
  23. nyco has left
  24. daniel has left
  25. lskdjf has joined
  26. lskdjf has joined
  27. la|r|ma has left
  28. jjrh has left
  29. jjrh has left
  30. jjrh has left
  31. Syndace has joined
  32. Syndace has joined
  33. Syndace has joined
  34. daniel has joined
  35. jjrh has left
  36. la|r|ma has joined
  37. lskdjf has joined
  38. Valerian has joined
  39. Arc has joined
  40. efrit has left
  41. emxp has joined
  42. Guus has left
  43. Guus has joined
  44. jere has left
  45. dwd has left
  46. dwd has left
  47. Valerian has left
  48. Valerian has joined
  49. uc has joined
  50. uc has joined
  51. dwd has left
  52. tux has left
  53. tux has joined
  54. goffi has joined
  55. Valerian has left
  56. Zash has left
  57. daniel has left
  58. Guus has left
  59. Guus has joined
  60. daniel has joined
  61. edhelas has left
  62. edhelas has left
  63. jubalh has joined
  64. Guus has left
  65. Guus has joined
  66. Guus has left
  67. Guus has joined
  68. jubalh has left
  69. Flow jonasw, no worries
  70. Flow I hope that Link Mauve eventually reconsiders his vote, because maybe he was also on the wrong track about what BMH is about…
  71. mimi89999 has joined
  72. lovetox has joined
  73. Guus has left
  74. Guus has joined
  75. daniel has left
  76. Guus has left
  77. jubalh has joined
  78. Guus has joined
  79. jubalh has left
  80. jubalh has joined
  81. jubalh has left
  82. Steve Kille has left
  83. Zash has left
  84. Zash has joined
  85. Steve Kille has left
  86. Steve Kille has joined
  87. pep. Flow: I don't think so
  88. jonasw Flow, to be honest, I think you picked a really bad time for this
  89. jonasw the worst imaginable
  90. jonasw I now understand your use-case, but in light of the XHTML-IM obsoletion discussion ...
  91. Zash I had that thought as well
  92. pep. And I said that on the ML already
  93. pep. Plus, I don't see what your XEP brings that's not already possible for you to do in your gateway, instead of pushing that effort on every. single. client.
  94. Steve Kille has left
  95. Steve Kille has joined
  96. dwd has left
  97. tim@boese-ban.de has left
  98. dwd has left
  99. pep. If the XSF wants to avoid flawed implementations BTW (seeing the xhtml-im thread), I suggest we start here
  100. tux has left
  101. dwd has left
  102. dwd has left
  103. Flow jonasw, Zash: Yep you are right. I blame our Ignite Realtime community for switching to Discourse and triggering the whole BMH idea. And by the time I realized that it could be seen as suggestion for a potential XHTML-IM replacement, the XEP was already announced without a good introduction providing a motivation. I would be happy to change that, but as long as there is a -1 vote from Link Mauve I'm not sure if I should put any more effort into it.
  104. dwd has left
  105. jonasw blaming the people who switch to Discourse is in any case the right thing to do
  106. Flow (of course I'm the only one to blame here, can't tell you how excited I'm that Ignite Realtime finally switched to discoures)
  107. jonasw (I’m not sarcastic here :))
  108. Zash Like I said earlier, I blame the web.
  109. jonasw blaming the web wfm too :)
  110. Flow yeah, everyting was better when we still had gopher
  111. Zash Flow: A very clear problem statement in the introduction probably helps.
  112. jonasw gopher was amazing
  113. Zash I never used it, but everything *was* better
  114. zinid what's wrong with discourse?
  115. jonasw I wrote a gopher server once, in freepascal.
  116. jonasw then firefox dropped gopher support :(
  117. Zash I looked into the specs and almost started implementing it in Prosody :)
  118. Ge0rG can't we just go back to NNTP?
  119. jonasw NNTP over NTP
  120. Zash From what I gather, NNTP was perfection.
  121. Arc has left
  122. zinid NNTP was quite good indeed
  123. Ge0rG Zash: except for the spam.
  124. jonasw it’s always the spam
  125. Zash Not quite clear on the distinction between NNTP, Newsgroups and usenet.
  126. Ge0rG Oh wait. XMPP is the NNTP of the 2000s.
  127. Ge0rG Zash: similar to the distinction between XMPP and Jabber.
  128. jonasw XMPP, Jabber, conversations.im?
  129. Zash It was pure perfection anyways. Therefor it must die.
  130. dwd has left
  131. Zash The Web will win and consume the world, because it is terrible.
  132. Zash Can't have nice things.
  133. Zash Worse is better.
  134. Ge0rG So I've spent two hours tracking the special place where Android devices store their factory-reset-protection data, just to realize that I have no actual device supporting it.
  135. dwd has left
  136. dwd has left
  137. dwd has left
  138. dwd has left
  139. dwd has left
  140. dwd has left
  141. daniel has left
  142. dwd has left
  143. dwd has left
  144. dwd has left
  145. dwd has left
  146. dwd has left
  147. dwd has left
  148. dwd has left
  149. dwd has left
  150. dwd has left
  151. dwd has left
  152. daniel has left
  153. daniel has joined
  154. dwd has left
  155. dwd has left
  156. dwd has left
  157. dwd has left
  158. dwd has left
  159. dwd has left
  160. dwd has left
  161. dwd has left
  162. sonny has left
  163. sonny has joined
  164. dwd has left
  165. dwd has left
  166. nyco https://twitter.com/saghul/status/920934733147787264
  167. nyco Real-Time Communications dev-room: deadline 23:59 UTC on 30th of November.
  168. dwd has left
  169. dwd has left
  170. la|r|ma has joined
  171. dwd has left
  172. lskdjf has joined
  173. daniel has left
  174. daniel has joined
  175. dwd has left
  176. pep. has left
  177. pep. has left
  178. pep. has left
  179. pep. has left
  180. pep. has left
  181. pep. has left
  182. pep. has left
  183. pep. has left
  184. pep. has left
  185. pep. has left
  186. pep. has left
  187. pep. has left
  188. pep. has left
  189. pep. has left
  190. pep. has left
  191. pep. has left
  192. pep. has left
  193. dwd has left
  194. pep. has left
  195. pep. has left
  196. pep. has left
  197. pep. has left
  198. pep. has left
  199. pep. has left
  200. pep. has left
  201. pep. has left
  202. pep. has left
  203. pep. has left
  204. pep. has left
  205. pep. has left
  206. pep. has left
  207. pep. has left
  208. pep. has left
  209. pep. has left
  210. pep. has left
  211. pep. has left
  212. pep. has left
  213. pep. has left
  214. pep. has left
  215. pep. has left
  216. pep. has left
  217. pep. has left
  218. Wiktor has left
  219. nyco has left
  220. dwd has left
  221. goffi has left
  222. jere has joined
  223. dwd has left
  224. dwd has left
  225. mimi89999 has joined
  226. dwd has left
  227. dwd has left
  228. emxp has joined
  229. goffi has joined
  230. dwd has left
  231. dwd has left
  232. emxp has joined
  233. tux Ge0rG: you mean there are Android devices with a special storage area for malware?
  234. dwd has left
  235. Ge0rG tux: no, it's more of a trojan horse when you sell your android device.
  236. dwd has left
  237. tux 👍
  238. Ge0rG tux: after a factory reset, the device can only be unlocked with the gmail account that was used on it before resetting.
  239. tux Effectively opening a market for Gmail account data.
  240. dwd has left
  241. daniel has left
  242. jere has left
  243. jere has joined
  244. lumi has joined
  245. dwd has left
  246. ralphm has left
  247. dwd has left
  248. dwd has left
  249. dwd has left
  250. dwd has left
  251. ralphm has left
  252. Alex has joined
  253. dwd has left
  254. jubalh has joined
  255. ralphm has joined
  256. dwd has left
  257. dwd has left
  258. tim@boese-ban.de has left
  259. tim@boese-ban.de has left
  260. tim@boese-ban.de has left
  261. tim@boese-ban.de has left
  262. tim@boese-ban.de has joined
  263. tim@boese-ban.de has left
  264. tim@boese-ban.de has joined
  265. tim@boese-ban.de has left
  266. dwd has left
  267. dwd has left
  268. dwd has left
  269. valo has joined
  270. dwd has left
  271. dwd has left
  272. valo has joined
  273. dwd has left
  274. dwd has left
  275. nyco has left
  276. dwd has left
  277. Zash has left
  278. dwd has left
  279. dwd has left
  280. sonny has joined
  281. sonny has joined
  282. dwd has left
  283. daniel has joined
  284. dwd has left
  285. dwd has left
  286. jubalh has left
  287. dwd has left
  288. dwd has left
  289. dwd has left
  290. dwd has left
  291. jere has joined
  292. jere has joined
  293. jubalh has left
  294. daniel has left
  295. dwd has left
  296. daniel has joined
  297. dwd has left
  298. dwd has left
  299. dwd has left
  300. dwd has left
  301. dwd has left
  302. dwd has left
  303. Wiktor has left
  304. jere has left
  305. dwd has left
  306. dwd has left
  307. Zash has left
  308. emxp has left
  309. jubalh has joined
  310. stefandxm has left
  311. zinid has left
  312. emxp has joined
  313. ralphm has left
  314. jubalh has joined
  315. vanitasvitae has joined
  316. jubalh has joined
  317. jjrh has left
  318. lskdjf has left
  319. Guus has left
  320. Guus has joined
  321. jere has joined
  322. jjrh has left
  323. jjrh has left
  324. dwd has left
  325. jjrh has left
  326. tim@boese-ban.de has left
  327. jubalh has left
  328. jjrh has left
  329. dwd has left
  330. dwd has left
  331. Arc has joined
  332. dwd has left
  333. lskdjf has left
  334. lskdjf has joined
  335. dwd has left
  336. lskdjf has left
  337. lskdjf has joined
  338. dwd has left
  339. jjrh has left
  340. jjrh has left
  341. stefandxm has joined
  342. dwd has left
  343. jjrh has left
  344. dwd has left
  345. dwd has left
  346. dwd has left
  347. dwd has left
  348. dwd has left
  349. dwd has left
  350. dwd has left
  351. dwd has left
  352. dwd has left
  353. daniel has left
  354. daniel has joined
  355. dwd has left
  356. dwd has left
  357. stefandxm has left
  358. dwd has left
  359. dwd has left
  360. dwd has left
  361. dwd has left
  362. sonny has left
  363. sonny has joined
  364. sonny has joined
  365. dwd has left
  366. sonny has joined
  367. dwd has left
  368. mimi89999 has left
  369. daniel has left
  370. daniel has joined
  371. dwd has left
  372. tux has left
  373. tux has left
  374. dwd has left
  375. dwd has left
  376. dwd has left
  377. dwd has left
  378. tux has left
  379. dwd has left
  380. dwd has left
  381. dwd has left
  382. emxp has joined
  383. emxp has joined
  384. tux has joined
  385. tux has left
  386. dwd has left
  387. dwd has left
  388. daniel has left
  389. daniel has joined
  390. Zash has left
  391. dwd has left
  392. dwd has left
  393. Zash has left
  394. dwd has left
  395. sonny has joined
  396. dwd has left
  397. zinid has left
  398. waqas has joined
  399. jubalh has joined
  400. jjrh has left
  401. vanitasvitae has left
  402. stefandxm has joined
  403. jjrh has left
  404. jjrh has left
  405. vanitasvitae has joined
  406. intosi has joined
  407. Guus has left
  408. daniel has left
  409. daniel has joined
  410. Guus has joined
  411. matlag has joined
  412. jjrh has left
  413. zinid has left
  414. uc has joined
  415. jjrh has left
  416. uc has joined
  417. Guus has left
  418. boothj5 has joined
  419. Guus has joined
  420. ralphm has joined
  421. boothj5 has left
  422. dwd has left
  423. dwd has left
  424. dwd has left
  425. vanitasvitae has left
  426. dwd has left
  427. dwd has left
  428. emxp has left
  429. dwd has left
  430. dwd has left
  431. lumi has left
  432. dwd has left
  433. dwd has left
  434. dwd has left
  435. dwd has left
  436. jubalh has left
  437. jjrh has left
  438. jere has joined
  439. dwd has left
  440. Valerian has joined
  441. dwd has left
  442. dwd has left
  443. stefandxm has left
  444. emxp has joined
  445. Kev has left
  446. jjrh has left
  447. jere has joined
  448. dwd has left
  449. jubalh has joined
  450. jubalh has left
  451. dwd has left
  452. vanitasvitae has joined
  453. lskdjf has left
  454. lskdjf has left
  455. dwd has left
  456. dwd has left
  457. dwd has left
  458. dwd has left
  459. dwd has left
  460. dwd has left
  461. dwd has left
  462. jjrh has left
  463. dwd has left
  464. dwd has left
  465. dwd has left
  466. sonny has joined
  467. dwd has left
  468. dwd has left
  469. waqas has left
  470. dwd has left
  471. dwd has left
  472. dwd has left
  473. dwd has left
  474. Arc has left
  475. dwd has left
  476. dwd has left
  477. lumi has joined
  478. arc has left
  479. arc has joined
  480. stefandxm has joined
  481. arc has left
  482. arc has joined
  483. dwd has left
  484. Link Mauve “19:13:59 Flow> What do clients use these days to embed image-urls into a message (e.g. for stickers)?”, Movim uses XHTML-IM, alongside BoB.
  485. sonny has joined
  486. dwd has left
  487. Flow Link Mauve, k, thanks. I wonder if at least OOB should be mentioned in https://xmpp.org/extensions/xep-0387.html#im
  488. Link Mauve I doubt so, it’s one of these XEPs that should be deprecated imo, it brings pretty much no information.
  489. SamWhited I think one of those two things (SIMS or OOB) could be included (in the next version which I will start on as soon as this one is advanced). It makes the experience significantly nicer.
  490. Flow what was SIMS again?
  491. SamWhited Flow: Slightly more advanced OOB, I think. I need to read both again and compare.
  492. Link Mauve Flow, about Discourse, I really fail to see the issue with doing exactly the same thing as every other gateway before yours, that is to convert whatever input markup you get from the legacy service into both plain text and XHTML-IM.
  493. dwd has left
  494. SamWhited Eg. allows for multiple media types.
  495. Link Mauve Flow, 0385.
  496. jonasw Flow: Stateless Inline Media Sharing
  497. Flow Link Mauve, how do you image a plain text version of CommonMark look like?
  498. Link Mauve Basically, a description of the file, with metadata, and multiple possible sources to retrieve it.
  499. Link Mauve Flow, for example “this is **bold**” into “this is bold”.
  500. Link Mauve That way the receiver won’t have to understand CommonMark to understand a sentence.
  501. Flow so I need to converters and loose stylistic/semantic information if the recipient can only look at the body?
  502. dwd has left
  503. Flow Do we also convert lists?
  504. Link Mauve Right, that’s the definition of plain text.
  505. Flow And headings?
  506. Link Mauve Indeed, you should convert the usual Markdown list (this one: 1. first item 1. second item 1. third item ) into something that can be better understood by the user.
  507. Flow And why would I convert at all? CommonMark is nicely readable as plain text
  508. Link Mauve Here, renumbering them into 1. 2. 3.
  509. moparisthebest why isn't commonmark in the body with some clients displaying it raw and some translating it on the recieving end like every email/chat client ever fine?
  510. Link Mauve Flow, it’s not always, I just gave you two examples.
  511. dwd has left
  512. SamWhited Messing with the message the user sent seems like a bad idea, especially when it's already perfectly readable plain tex.t
  513. moparisthebest gajim, all IRC clients, most email clients, they all do that
  514. goffi has left
  515. Flow Link Mauve, that's a corner case, and I believe you will get normalized CommonMark out of Discourse
  516. dwd has left
  517. moparisthebest also the *huge* problem with not putting things in body, or different representations, is from a security perspective, how do you ensure they are the same? jonasw I think you were the most concerned with using body
  518. Link Mauve moparisthebest, email clients overwhelmingly display the text/html version of a multipart attachment first, some of them display the text/plain version and add colour for common idioms, such as the “-- ” signature or the ”>” quotes but that’s due to legacy.
  519. sonny has joined
  520. moparisthebest due to legacy sure, but it works great and everyone understands it
  521. Flow hopes that the text/plain MIME part never becomes legacy
  522. Link Mauve If I want to display you a broken ordered list, what I just posted you, will you also transform that into a normalised one creating incomprehension between us, just because you happen to throw every incoming message into your CommonMark parser?
  523. moparisthebest what flow just did, /me, is that a XEP someplace or is that convention?
  524. Link Mauve Flow, same. ^^
  525. SamWhited More importantly, people who have never seen it before intuatively understand it. If you read "Wow, that's *amazing*!" you just get it… it makes sense that it's a for of emphasis.
  526. SamWhited *form of
  527. dwd has left
  528. jonasw moparisthebest: consistency of user experience, fracturing of the ecosystem and complexity of supporting possibly numerous markups
  529. SamWhited moparisthebest: https://xmpp.org/extensions/xep-0245.html
  530. moparisthebest yea, and gajim bolded that for me as well, equally I would have understood if it didn't
  531. jonasw I'm on the phone now
  532. jonasw so hard to go into details
  533. Zash Flow: You didn't see the thing where some Mozilla person wanted to remove plain text because it didn't have tracking images?
  534. moparisthebest ah nifty SamWhited , also just in body, and if the client didn't support it it'd still be mostly readable
  535. Flow Zash, I read about it :)
  536. Flow bbl
  537. moparisthebest imho that's what you want for instant message markup, simple things that don't matter if they are actually interpreted or not *bold* /italic/ etc
  538. moparisthebest publishing blog posts is a different use-case with different needs
  539. dwd has left
  540. dwd has left
  541. Zash Formatting vs semantics again
  542. Link Mauve moparisthebest, that’s a Gajim bug, not something we should encourage.
  543. Link Mauve (Bolding something.)
  544. moparisthebest don't many other clients do the same?
  545. moparisthebest seems like it should be a feature we should encourage to me
  546. Link Mauve moparisthebest, I’ve never seen any other client, and it sounds misguided at best.
  547. stefandxm has left
  548. moparisthebest it's at minimum in basically every irc client and most email clients
  549. moparisthebest surely it's in other xmpp clients
  550. dwd has left
  551. pep. I agree with Link Mauve, that's not something that should be encouraged. Or at best gajim could translate that to xhtml-im
  552. lskdjf has left
  553. moparisthebest my point is it's readable whether the client special-cases it or not
  554. moparisthebest no fragmenting or confusion
  555. dwd has left
  556. SamWhited I disagree, it's simple, effective, and a very nice experience. We should absolutely encourage it.
  557. pep. moparisthebest, it's not because you understand it that everybody does. My parents don't, they might understand *foo*, but maybe not _bar_ nor /baz/
  558. pep. Also if a client translates that, how do I write IPA now? :(
  559. SamWhited (or we should absolutely encourage something similar, I'm not advocating for exactly what Gajim does, whatever that may be)
  560. dwd has left
  561. Link Mauve (I just reported that bug to Gajim, fyi.)
  562. SamWhited I don't even think that needs to be standardized though; it could be completely separate from whatever new formatting thing comes out. It's just nice to have either way and can be client specific without harming anything.
  563. Steve Kille has left
  564. pep. By using common characters as meta characters you are removing many things that were possible and won't be anymore. Have your client allow you to write rich text, sure, don't clutter <body>
  565. dwd has left
  566. moparisthebest pep., but then evil alice can send 1 message with something different in <body> and <somefancymarkup>, it opens up a bad can of worms
  567. moparisthebest pep., won't they understand _bar_ or /baz/ , and if not, why exactly does it matter?
  568. pep. because I want to express something if I use that?
  569. moparisthebest by the way I'm using gajim now and it still *shows* all the characters, just additionally underlines/bolds/italics them
  570. pep. I want their client to convey it for me, they know what italic is, what bold it, they might not know what **, __, or // are
  571. pep. Or whatever other markup you fancy
  572. moparisthebest here's the other thing, I don't want to read your fancy markup, so I can turn it off on my client
  573. dwd has left
  574. moparisthebest if your client sends it in <newfancymarkup> then I have to view that
  575. moparisthebest I don't have an option not to see it
  576. goffi has joined
  577. Link Mauve moparisthebest, err, Markup isn’t plain text, it just isn’t.
  578. Link Mauve moparisthebest, err, Markdown isn’t plain text, it just isn’t.
  579. dwd has left
  580. moparisthebest it is though, it's made to be perfectly readable as plain text
  581. moparisthebest and maybe parts are a bit questionable but that's fine, we only want the super simple obvious parts
  582. Link Mauve If I don’t want to display formatting and turn it off in my client, when there is a plain text alternative I can, when you confuse Markdown and plain text I can’t anymore.
  583. moparisthebest except markdown is plain text
  584. moparisthebest or at least the subset that every chat program has been happy with for years
  585. Link Mauve moparisthebest, you may want only the very simple part, someone else may want one other part, and a lazy dev will shove you whatever their fancy lib supports.
  586. dwd has left
  587. moparisthebest no, that's the entire point
  588. Link Mauve moparisthebest, Markdown is a superset of HTML.
  589. moparisthebest you don't use a lib to send anything
  590. pep. moparisthebest, markdown is not plaintext. If you say that I say we should use escaped XML as markup language
  591. Link Mauve It’s not plain text, has never been.
  592. dwd has left
  593. pep. <strong>Hey!</strong>
  594. moparisthebest you send the exact text the user writes
  595. moparisthebest the recieving client displays it, optionally with a bit of formatting
  596. moparisthebest here I'll send a screenshot of what gajim displays so we are all on the same page *bold* _underlined_ /italic/
  597. Link Mauve moparisthebest, so how do you interpret what pep. just sent?
  598. Link Mauve moparisthebest, ah, but *bold* is actually italic in Markdown.
  599. Link Mauve Now what do you do?
  600. sonny has joined
  601. moparisthebest I interpret it as, why the hell is he writing xml in a text chat
  602. Link Mauve While what pep. wrote is actually bold in Markdown.
  603. Link Mauve moparisthebest, but that’s Markdown he just wrote.
  604. sonny has joined
  605. pep. I did write markdown indeed.
  606. Link Mauve Not XML.
  607. sonny has joined
  608. sonny has joined
  609. Zash Are you rehashing all the same things?
  610. pep. Zash, yes, because nobody understands apparently
  611. Link Mauve Zash, seems so. :/
  612. moparisthebest https://burtrum.org/up/30079903-aaa9-43c1-b08f-2642b7e7764d/open-screeny-23190.png
  613. dwd has left
  614. arc has left
  615. moparisthebest see no information is lost, all characters are displayed
  616. Link Mauve moparisthebest, except it looks bad.
  617. moparisthebest and it's readable with and without fancy parsing
  618. moparisthebest then turn it off, or make your client display it differently for you
  619. pep. *But* this _is_ not what I /meant/, at ~all~. < I'm just sending plaintext, this is not markup.
  620. moparisthebest that's fine, I still saw everything
  621. pep. How does your client deal with that now
  622. moparisthebest pep., https://burtrum.org/up/5eebca0a-a420-494c-816b-b0907998107b/open-screeny-23265.png
  623. pep. moparisthebest, I know exactly how it rendered it, that doesn't reflect at all what I wanted
  624. moparisthebest having a WYSIWYG editor wouldn't have done a better job
  625. moparisthebest and would be terrible
  626. pep. That's the issue when you don't separate <body> and $markup
  627. Zash pep.: You should have included a body hint saying text/plain
  628. Zash :)
  629. pep. Zash, a, too bad
  630. pep. Zash, ah, too bad
  631. dwd has left
  632. dwd has left
  633. Link Mauve moparisthebest, in Mattermost, markup is correctly displayed without these ugly * and / and whatnot, the user can focus on the text and not on * which pollute the reading.
  634. moparisthebest pep and then you opened the can of worms, you are in a contract dicussion, and alice sends <body>that'll be $10,000</body><fancymarkup>that'll be $1,000</fancymarkup> and since you use fancyclient you agree, but oops the xsf log bot only supports <body> sucks to be you in court
  635. moparisthebest and a million other things
  636. SamWhited How does that not reflect what you wanted?
  637. SamWhited Or, put another way, why does it matter to you that on the other thing a thing you weren't expectint to be bold ended up bold?
  638. pep. How does gajim deal with both *foo*
  639. SamWhited (or italics, or whatever)
  640. Link Mauve pep., you mean this and *that*? :)
  641. pep. SamWhited, because that could be interpreted as an emphasis, which I didn't want
  642. pep. Link Mauve, no I meant both at the same time
  643. Zash moparisthebest: same with email and xhtml-im and everything
  644. moparisthebest then you shouldn't have used the characters that have meant emphasis for 20+ years pep.
  645. arc has joined
  646. Link Mauve I’d suppose it displays it normally-bolded.
  647. dwd has left
  648. SamWhited pep. what did you want then? Even if there is no bolding or highlighting, *this* looks like emphasis to me.
  649. moparisthebest and to everyone else
  650. moparisthebest that's why everyone uses them
  651. pep. SamWhited, moparisthebest, that's the magic of having markup separated from plaintext
  652. SamWhited I didn't understand that.
  653. pep. I used ** but it could have been __ or ^^ for all I care
  654. Link Mauve SamWhited, because you have been thinking with computers since forever, go in the street and ask a random person who seldom use a computer what * means, you’d be surprised.
  655. moparisthebest I highly doubt that
  656. Link Mauve (I know my mother once asked me about something similar, which I had always been using without thinking about it, I think it was the * used for corrections.)
  657. moparisthebest I think you send anyone something like *this* it's pretty apparant
  658. SamWhited I disagree, even if I've never seen it I'll probably see *wow!* and assume someone meant emphasis; your mother wouldn't even think of it, she'd just read it and naturally ignore it.
  659. moparisthebest and if they don't know about it, they should learn, cause it's everywhere and always will be
  660. SamWhited I mean, I say "I assume they meant emphasis", it's not even something you'd think about reading that. It just parses fine.
  661. pep. SamWhited, so what if I use /foo/ now and it's interpreted as an emphase when in fact I'm writing IPA
  662. lskdjf has joined
  663. dwd has left
  664. pep. If you want concrete examples
  665. SamWhited I'm reasonably sure most people won't write IPA, or regular expressions, or anything else where the conflict will matter.
  666. sonny has joined
  667. Link Mauve moparisthebest, haha, you wish.
  668. SamWhited Even if it did, okay, your IPA might be italics on some clients. It doesn't break it though.
  669. dwd has left
  670. SamWhited That seems like a tiny edge case to me.
  671. pep. The point of a client is not to "not break"
  672. pep. "Ah I'm fine it barely works!"
  673. Link Mauve SamWhited, I know a room where people have been sending a lot of IPA over the years.
  674. Link Mauve (It’s about linguistics.)
  675. pep. Anyway, have to go
  676. moparisthebest pep., but it doesn't break anything including regex cause all characters are there
  677. Link Mauve moparisthebest, it just looks bad, while it could have been avoided altogether by simply separating formatting from input.
  678. moparisthebest I don't think so it's just a natural way to add emphasis without a huge WYSIWYG editor
  679. moparisthebest I don't have room for one of those on my phone screen
  680. dwd has left
  681. Link Mauve And remember that it’s the way Gajim misguidedly did it, think about a random dev throwing that at their Markdown library which would strip any such character as soon as it is parsed, which would replace unescaped snake_case_words with italic in the middle of variable names, etc.
  682. arc has left
  683. arc has joined
  684. dwd has left
  685. SamWhited I'm sure you do know a room about that, but that room is also a tiny edge case and it's a tiny edge case that's not even broken
  686. Arc has joined
  687. Link Mauve moparisthebest, if your client considers it the natural way to add emphasis, that’s fine, it should just both expose the formatted one and the plain text one properly.
  688. sonny has joined
  689. Link Mauve And that way you also see that it oops transformed that variable name in snakecaseword, and can edit your message to fix it.
  690. Arc has left
  691. Link Mauve SamWhited, for now, just wait until clients start using Markdown instead.
  692. SamWhited Yah sure, but that's a different issue. We should absolutely provide guidance and try to make sure that the easiest way to do it is also a good UX.
  693. Ge0rG Function names, path names and enumerations are in my experience the things most often misidentified by xmpp clients. Enumerations like (a)
  694. Link Mauve Bbl Rust meetup! \o_
  695. dwd has left
  696. Link Mauve moparisthebest, SamWhited, I would totally welcome a XEP describing guidelines for input markup, to tell how clients could treat input to transform it into XHTML-IM or succ(XHTML-IM), just sending it as-is on the wire is a no-go.
  697. dwd has left
  698. SamWhited I disagree, translating it into XHTML-IM is a terrible idea.
  699. sonny has joined
  700. SamWhited I don't know if translating to succ(XHTML-IM) is a good idea or not, of course, since it doesn't exist yet.
  701. Link Mauve I’ll send an email to the list later, in the meantime I’m going to be late for a Rust pizza. :)
  702. dwd has left
  703. Ge0rG This subject is really bringing up emotions...
  704. dwd has left
  705. Steve Kille has joined
  706. dwd has left
  707. tux has joined
  708. dwd has left
  709. dwd has left
  710. valo has joined
  711. dwd has left
  712. dwd has left
  713. sonny has left
  714. sonny has joined
  715. dwd has left
  716. dwd has left
  717. dwd has left
  718. Steve Kille has left
  719. Valerian has left
  720. Valerian has joined
  721. dwd has left
  722. vanitasvitae has left
  723. dwd has left
  724. dwd has left
  725. ralphm has left
  726. dwd has left
  727. dwd has left
  728. dwd has left
  729. sonny has left
  730. sonny has joined
  731. sonny has left
  732. Valerian has left
  733. sonny has joined
  734. dwd has left
  735. dwd has left
  736. emxp has joined
  737. sonny has joined
  738. sonny has joined
  739. dwd has left
  740. sonny has left
  741. sonny has joined
  742. lskdjf has left
  743. sonny has left
  744. sonny has joined
  745. sonny has left
  746. sonny has joined
  747. daniel Ge0rG: it's not very technical. So everyone has an opinion
  748. Ge0rG daniel: and I'm getting less and less sure what my opinion is.
  749. sonny has left
  750. sonny has joined
  751. sonny has left
  752. sonny has joined
  753. dwd has left
  754. sonny has left
  755. sonny has joined
  756. jjrh has left
  757. sonny has joined
  758. sonny has joined
  759. dwd has left
  760. jonasw great, I missed the party
  761. stefandxm has joined
  762. sonny has left
  763. sonny has joined
  764. sonny has joined
  765. sonny has joined
  766. Valerian has joined
  767. dwd has left
  768. jjrh has left
  769. dwd has left
  770. jjrh has left
  771. sonny has left
  772. dwd has left
  773. dwd has left
  774. sonny has joined
  775. dwd has left
  776. dwd has left
  777. dwd has left
  778. dwd has left
  779. Tobias has joined
  780. stefandxm has left
  781. dwd has left
  782. dwd has left
  783. daniel has left
  784. daniel has joined
  785. ralphm has joined
  786. dwd has left
  787. dwd has left
  788. dwd has left
  789. dwd has left
  790. dwd has left
  791. dwd has left
  792. dwd has left
  793. dwd has left
  794. dwd has left
  795. dwd has left
  796. dwd has left
  797. alacer has joined
  798. goffi has left
  799. dwd has left
  800. arc has left
  801. arc has joined
  802. dwd has left
  803. dwd has left
  804. jonasw so, I’d like to add a few bits
  805. dwd has left
  806. jonasw moparisthebest, re differences between body/non-body: yes, that’s a problem in some cases. I’m not sure how to fix that. However, I’d argue that if you’re doing transactions like that only over unsigned XMPP, you may be doing something wrong.
  807. jonasw (same thing holds for email)
  808. jonasw moparisthebest, re "/me", which is in body: funny thing about that. Pidgin hat a vulnerability where messages starting with /me would not be encrypted with OTR. That’s what you get from adding interesting semantics to body parts (pun not intended).
  809. moparisthebest yea email suffers from the same, probably other things
  810. jonasw otherwise, I tend to agree with Link Mauve, except that HTML email is an abomination which should be killed with fire.
  811. moparisthebest why would the sending side ever process that at all?
  812. jonasw SamWhited, I’ve seen people ask me what I mean with the underscores in "_foo_".
  813. SamWhited I don't see how that Pidgin bug is relavant; if we're going to argue for that being a reason never to interpret text in body then shouldn't we never put text outside the body because it's never encrypted because OTR only encrypts the body?
  814. moparisthebest isn't /me and what I'm talking about a 100% reciever feature?
  815. jonasw SamWhited, I just wanted to throw in the fun fact :)
  816. jonasw moparisthebest, yes, pidgin is broken
  817. moparisthebest anyway the biggest argument might be about fragmentation
  818. jonasw it uses /foo for commands, and I bet they implemented /me as "send the text behind /me with '/me' as prefix", circumventing the layers which added encryption.
  819. moparisthebest putting text in body makes it *just work* in all clients whether they make it fancy or not
  820. dwd has left
  821. ralphm has left
  822. jonasw moparisthebest, now of course we can’t stop make people type things like *just work* in body (I’m with Link Mauve on that that we might want to specify how that’s supposed to work), but this shouldn’t be used as transport
  823. jonasw because it is not extensible, and most markups only have limited features, and at some point things become not-so-readable in plaintext.
  824. jonasw and yes, much of this may not matter for the typical IM user sending things, but it matters for automated services such as Flows bridge or bots sending high-density content which simply needs formatting to be easily parsable
  825. jonasw we need a format for that, and if we’re going to have a markup format in XMPP, it should work everywhere in XMPP..
  826. SouL has left
  827. moparisthebest I know this is xmpp and such and I might get fried for saying this
  828. moparisthebest but not everything needs to be extensible
  829. dwd has left
  830. jonasw (this is, again, for transport only. I’m not at all arguing that people shouldn’t be able to type *foo* and have it come up as emphasised, but the transport shouldn’t convey "*foo*" in that case)
  831. SamWhited I was about to write that. I'm not convinced the markup needs to be (I'm not convinced it shouldn't be either, mind)
  832. moparisthebest I think the sender shouldn't do any processing at all
  833. moparisthebest and reciever decides if it wants to emphasize stuff or not
  834. moparisthebest now also I'm only talking about the IM usecase
  835. jonasw only the sender can possibly know which semantics and styling was intended. trying to recover that at the receiver is going to be a mess.
  836. SamWhited has left
  837. moparisthebest I think the microblogging use-case is entirely seperate and needs a seperate XEP and such
  838. jonasw yes, I’m with you on the IM usecase -- just not only IM between humans. also machines and humans, which is still IM.
  839. jonasw I’m not talking about microblogging.
  840. moparisthebest I don't think you want or need complicated markup in IM
  841. jonasw sure, the receiver can decide to strip all markup, and we totally should encourage implementations to allow that.
  842. dwd has left
  843. jonasw I don’t want to be able to write it, but I want to be able to receive it. Yes, (and I’m going to be killed for that), this includes headings.
  844. moparisthebest does anyone enjoy MIRC colors for instance
  845. jonasw colors are tricky -- I made a proposal how to make them right.
  846. jonasw (actually colors and fonts are the reason I ban XHTML-Im in my clients, and I totally think that succ(XHTML-IM) should not support arbitrary colors and fonts.)
  847. jonasw what I think it sohuld support I already mentioned on the ML: Non-semantic things: - Colorise things with colors from a palette (e.g. 360 colors from the XEP-0392 palette) (via Georg Lukas) Semantic things: - Emphasis (typically italics), Strong (typically boldface) - Pre-formatted text (code), including a way to specify the language (this may make the colorisation of things obsolete, the only use-case I’ve heard so far is syntax-highlighting) - Blockquotes - Paragraphs - Enumerations and unordered lists - Links (but possibly without the possibility to change the text shown), with a whitelist of URL schemas Other things which may be useful, but I’m not sure if we don’t have better ways to do that by now: - Embedding multimedia content, like images, audio, video (a SIMS-message may be better suited for that)
  848. moparisthebest I think it should only support *bold* and /italics/ and _underline_ and, oh look, gajim and most other things already do, problem solved
  849. dwd has left
  850. waqas has joined
  851. moparisthebest everything else is just regular text
  852. jonasw moparisthebest, sure, I’m fine if clients support that as input.
  853. jonasw but those "trivial" markups get complicated as heck in not-so-trivial situations like words which include one or more the meta-characters
  854. jonasw or sentences which happen to include them twice
  855. moparisthebest I think this is a solution in search of a problem
  856. jonasw I laid out use-cases on the ML.
  857. Ge0rG moparisthebest: when you enter that in gajim, can you see the markup?
  858. zinid tl;dr: have you decided yet what markup to use?
  859. jonasw zinid, no.
  860. jonasw zinid, you’re a server dev, you must look away :P
  861. zinid ok :D
  862. moparisthebest Ge0rG, what markup?
  863. Ge0rG Actually, the server should be able to convert the markup from one client format to the other
  864. moparisthebest I just have a box to type in in gajim
  865. zinid jonasw: yeah, nobody is asking server devs nowadays :)
  866. dwd has left
  867. Ge0rG moparisthebest: my problem with adhoc pseudo markdown is lack of interop
  868. moparisthebest Ge0rG, except it works with or without processing equally
  869. Ge0rG Anyway, gotta run now. CU tomorrow
  870. jonasw it doesn’t
  871. moparisthebest so free perpetual interop
  872. jonasw in the cases I mentioned abve
  873. jonasw if it fails at the only thing it’s supposed to do, it doesn’t work.
  874. moparisthebest where does it fail?
  875. zinid I don't think a server can modify body due to e2ee
  876. jonasw zinid, tips hat, that’s a well-placed troll.
  877. jonasw moparisthebest, sentences which happen to contain multiple meta-characters which happen to have some special meaning despite that meaning not being intended.
  878. jonasw as an example
  879. moparisthebest jonasw, and something is bolded erroneously, and no one cares?
  880. moparisthebest what am I missing
  881. jonasw yes but that’s really the only thing this is supposed to do.
  882. moparisthebest it's perfectly fine
  883. jonasw conveying semantics by bold/italics/underline/whatever. it literally fails to do its sole purpose.
  884. Ge0rG moparisthebest: I wrote earlier that some clients replace (a), (b), (c) style enumerations with smileys
  885. jubalh has joined
  886. jonasw also, tell my mother how to make a word containing an "*" italics/bold with Markdown.
  887. moparisthebest if I say the regex is .*bob.* and that ends up being bolded, you still get the message
  888. jonasw Ge0rG, go and kill pidgin with fire already.
  889. dwd has left
  890. Ge0rG moparisthebest: no, because I can't copy paste that regex any more
  891. moparisthebest Ge0rG, uh yes you can
  892. moparisthebest it doesn't remove the *
  893. moparisthebest Ge0rG, https://burtrum.org/up/30079903-aaa9-43c1-b08f-2642b7e7764d/open-screeny-23190.png
  894. jonasw moparisthebest, emphasize "Trainer*Innen" please.
  895. moparisthebest jonasw, *Trainer*Innen* works
  896. moparisthebest that the bold'ing code missed it doesn't matter
  897. moparisthebest it's still obvious in the reading
  898. dwd has left
  899. jonasw it’s super-awkward to read
  900. moparisthebest only because your a programmer that likes ASTs :P
  901. jonasw and no it doesn’t matter when a thing invented to do only exactly one thign literally doesn’t do that thing.
  902. jonasw and no it does matter when a thing invented to do only exactly one thign literally doesn’t do that thing.
  903. Ge0rG I'm an experienced user of markdown and I regularly fail to quote a formula with two multiplication signs.
  904. moparisthebest I disagree, it still conveys the same meaning whether it's highlighted or not
  905. SamWhited *this is bold* and so is **Trainer*Innen**, maybe? Just a thought (actual character doesn't matter obviously)
  906. jonasw SamWhited, sure, but this is the point where you don’t want humans to write that.
  907. dwd has left
  908. jonasw that’s also exactly the kind of thing I meant by "not extensible". You’d normally have to bump namespaces for this type of change.
  909. jonasw we can’t do that if we put things in <body/>.
  910. moparisthebest it's not a problem that needs solved
  911. SamWhited Yah, fair, it's really not
  912. jonasw moparisthebest, also, pandoc would highlight the first part and leave the second unhighlighted.
  913. moparisthebest you don't need a spec or standard that solves every single edge case ever
  914. moparisthebest that's also fine, gajim highlights nothing
  915. jonasw moparisthebest, but it’s comparatively easy to do so!
  916. moparisthebest I guess if you give me a huge editor with a ton of buttons maybe
  917. moparisthebest I don't want that, I'll just type *trainer*innen* anyway
  918. moparisthebest how does the sending client even know what I mean
  919. jonasw you’re free to have a client which supprots that type of input (I’m going to write one, for sure). But that’s not what should be in the transport.
  920. moparisthebest then you run into UI issues and such
  921. jonasw the sending client can offer you neat in-line markdown preview support.
  922. moparisthebest I have limited space on my phone screen as it is
  923. Valerian has left
  924. jonasw I’m thinking like some tools do auto-completion. I can’t describe that in just one line, but the flow is amazing.
  925. Ge0rG With LMC you just retry multiple times to fix the markup you never wanted, giving up in frustration after the fifth attempt
  926. jonasw you really care to add any kidn of markup on the phone? I’d be too lazy to search for "*".
  927. moparisthebest basically that, then I'd have to try to get it to look right
  928. SamWhited FWIW, if I ever were to release one of my toy clients it would have something like the toolbar in this in it: https://simplemde.com/
  929. moparisthebest where as if you display what I send exactly, and maybe bold/italic/underline part, it's fine
  930. dwd has left
  931. jonasw SamWhited, looks great
  932. SamWhited Maybe not with markdown, but something similar.
  933. SamWhited It's just a pleasant experience; I type **, my mother hits the "B" button. It all works out in the end.
  934. jonasw SamWhited, I was more thinking like: 1. You type *foo* 2. Client makes "foo" boldfaced and removes the asterisks. 3. You find that you didn’t want *foo* boldfaced, so you type backspace. 4. Client changes back to *foo*, but does not delete the *. 5. You can continue to type as normal.
  935. jonasw (in addition to a lightweight formatting toolbar)
  936. jonasw (of course, turning off any kind of formatting would work too. and stuff pasted from clipboard would never get formatted automatically.)
  937. moparisthebest or, you just type *foo*, recieving client may or may not bold it, everyone is happy, far less work, 100% interoperable
  938. jonasw moparisthebest, if everybody sees different things that’s not interoperable.
  939. jonasw that’s "it works"
  940. moparisthebest it's different regardless
  941. jonasw but not "it’s interoperable and works great"
  942. moparisthebest I typed this in courier new and you are seeing arial, maybe
  943. SamWhited Yah, Jira does the backspace thing and it never works as expected. I'm unsure why though.
  944. moparisthebest maybe we should start sending fonts and DPI values over xmpp too then?
  945. jonasw SamWhited, hm. I’d put some effort to make it work, if you care to test at some point? :)
  946. SamWhited Sure
  947. jonasw moparisthebest, of course not.
  948. jonasw SamWhited, also, you can then try to exploit my webview-based message view :)
  949. SamWhited I am always game for that.
  950. jonasw moparisthebest, in fact, killing off any kind of font change support is one of the reasons why I’m in favour of obliterating @style in XHTML-IM or obliterating XHTML-Im altogether.
  951. jonasw but I don’t have XHTML-IM support yet, so ;-)
  952. moparisthebest I just don't buy the argument that me seeing *foo* without bold and you seeing *foo* bold is any sort of problem at all
  953. jonasw I’ll put the accessibility argument back in the ring.
  954. jonasw those asterisks and underlines are annoying for a11y software.
  955. jonasw and slashes etc.
  956. dwd has left
  957. SamWhited If you didn't click it, also click the little eye icon in that web editor. It's the best part.
  958. jonasw SamWhited, :)
  959. jonasw much of this would be overkill for day-to-day IM use. but I definitely can see use-cases.
  960. jonasw and again, I think if we have these use-cases, I see no reason to have three different types of markup in XMPP if we can simply use the same thing for every use-case in the transport.
  961. SamWhited I don't think we can. Someone will always want a full blown layout engine for blogs. IM on the other hand just needs basic styling.
  962. moparisthebest jonasw, a11y software presumably would ignore those strange characters, I don't really know
  963. jonasw moparisthebest, I happen to know a few people who use a11y software.
  964. moparisthebest what does it say when it gets to *foo* or "bolded foo"
  965. jonasw SamWhited, I tend to agree that we might need some XHTML (but more than just the IM subset we had) for blogging cases.
  966. jonasw but for IM, I see something like XHTML-IM + possibly A/V embedding minus the @style as useful.
  967. jonasw moparisthebest, bolded "foo" leads to emphasis
  968. jonasw the other thing depends on the implementation
  969. jonasw but some will read out "asterisk foo asterisk"
  970. moparisthebest what kind of emphasis?
  971. jonasw tonal
  972. moparisthebest I'm not sure what you mean
  973. moparisthebest like it screams at you?
  974. jonasw no, but like you would emphasize a word in a sentence. the whole point you use emphasis.
  975. moparisthebest so I think my argument holds and is the same
  976. moparisthebest someone who uses that software, depending on their client, would hear 'star foo star' or FOO with emphasis
  977. jonasw I don’t think so?
  978. moparisthebest and either way get the same meaning
  979. jonasw no
  980. jonasw they would get "asterisk foo asterisk" with spoken emphasis.
  981. jonasw (if the client boldfaces the "*foo*")
  982. moparisthebest still they know what that means
  983. moparisthebest same as you or I know what it means when we read it
  984. jonasw that’s bad accessibility.
  985. jonasw really.
  986. jonasw that’s the type of thing people dependent on a11y software switch softwares for.
  987. moparisthebest it's identical to your plan of the sending client guessing all these things
  988. jonasw no
  989. jonasw the sender can revise and make sure it actually reflects their intentions.
  990. jonasw they can’t do that on the receiving side.
  991. moparisthebest but no their software would either say "asterisk foo asterisk" or "foo" with emphasis
  992. moparisthebest either way they understand, no problems
  993. jonasw why would they omit the asterisks if the client has them in the text view?
  994. jonasw they understand, but it wastes time.
  995. SamWhited Yah, that sounds bad. Accessibility is definitely the thing I'm most concerned about if we were to recommend something like this. Maybe I'll see what androids reader does later.
  996. moparisthebest now I'm curious how does a11y software read xhtml-im
  997. moparisthebest it would have to be way worse
  998. jonasw no
  999. jonasw they read it like they read webpages
  1000. jonasw for which they are basically optimised
  1001. jonasw (you do realize that a11y software scrapes the widgets of applications, don’t you?)
  1002. moparisthebest BLUE FONT BLACK BACKROUND BOLD MARQUEE FOO
  1003. jonasw (of course, applications help with that via a11y APIs and such)
  1004. dwd has left
  1005. dwd has left
  1006. ralphm has left
  1007. Valerian has joined
  1008. dwd has left
  1009. dwd has left
  1010. dwd has left
  1011. stefandxm has joined
  1012. dwd has left
  1013. jubalh has joined
  1014. Valerian has left
  1015. dwd has left
  1016. Valerian has joined
  1017. dwd has left
  1018. arc has left
  1019. ralphm has left
  1020. dwd has left
  1021. Syndace has joined
  1022. stefandxm has left
  1023. arc has joined
  1024. ralphm has joined
  1025. uc has joined
  1026. dwd has left
  1027. dwd has left
  1028. uc has joined
  1029. dwd has left
  1030. dwd has left
  1031. dwd has left
  1032. ralphm has left
  1033. moparisthebest has joined
  1034. dwd has left
  1035. uc has joined
  1036. dwd has left
  1037. jonasw has left
  1038. dwd has left
  1039. valo has joined
  1040. dwd has left
  1041. jubalh has joined
  1042. la|r|ma has left
  1043. ralphm has left
  1044. dwd has left
  1045. dwd has left
  1046. dwd has left
  1047. dwd has left
  1048. arc has left
  1049. arc has joined
  1050. dwd has left
  1051. dwd has left
  1052. zinid has left
  1053. dwd has left
  1054. dwd has left
  1055. dwd has left
  1056. dwd has left
  1057. ralphm has left
  1058. dwd has left
  1059. jere has joined
  1060. jere has joined
  1061. dwd has left
  1062. dwd has left
  1063. dwd has left
  1064. dwd has left
  1065. dwd has left
  1066. dwd has left
  1067. dwd has left
  1068. dwd has left
  1069. dwd has left
  1070. dwd has left
  1071. dwd has left
  1072. dwd has left
  1073. dwd has left
  1074. dwd has left
  1075. dwd has left
  1076. dwd has left
  1077. jere has left
  1078. jere has joined
  1079. dwd has left
  1080. dwd has left
  1081. daniel has left
  1082. dwd has left
  1083. dwd has left
  1084. dwd has left
  1085. dwd has left
  1086. dwd has left
  1087. lskdjf has left
  1088. dwd has left
  1089. dwd has left
  1090. dwd has left
  1091. dwd has left
  1092. jubalh has joined
  1093. jubalh has left
  1094. dwd has left
  1095. dwd has left
  1096. Guus has left
  1097. valo has left
  1098. dwd has left
  1099. dwd has left
  1100. Guus has joined
  1101. dwd has left
  1102. dwd has left
  1103. dwd has left
  1104. stefandxm has joined
  1105. dwd has left
  1106. dwd has left
  1107. dwd has left
  1108. dwd has left
  1109. dwd has left
  1110. dwd has left
  1111. dwd has left
  1112. SamWhited has left
  1113. dwd has left
  1114. dwd has left
  1115. Valerian has left
  1116. dwd has left
  1117. dwd has left
  1118. dwd has left
  1119. uc has joined
  1120. dwd has left
  1121. dwd has left
  1122. dwd has left
  1123. Valerian has joined
  1124. Arc has joined
  1125. jjrh has left
  1126. dwd has left
  1127. uc has joined
  1128. Link Mauve jonasw, not supporting font-family, color or color-background in @style is fine, but not supporting @style altogether is a bit bad imo.
  1129. dwd has left
  1130. Link Mauve And it’s trivial to parse and whitelist correctly.
  1131. dwd has left
  1132. Link Mauve “21:09:44 SamWhited> I don't think we can. Someone will always want a full blown layout engine for blogs. IM on the other hand just needs basic styling.”, that’s why I’ve been proposing to extend XHTML-IM with other profiles in the past, maybe I should go forward with that.
  1133. Link Mauve Not only for microblogging, which wasn’t even my use-case back then.
  1134. Alex has left
  1135. Link Mauve “21:10:57 jonasw> but for IM, I see something like XHTML-IM + possibly A/V embedding minus the @style as useful.”, @style is definitely useful, amongst the real-world examples of colour being used properly I’ve seen over the years were titles which include colour, sending a big red heart to someone, rainbows, spoilers, and in general style effects.
  1136. Link Mauve You can argue that we all have to be professional in our communications and all, but being able to do playful things is also useful.
  1137. Link Mauve That’s why I would dislike to see @style disappear altogether, whether in XHTML-IM or in a next spec.
  1138. Link Mauve Not all of us are sad grown-ups. :)
  1139. dwd has left
  1140. dwd has left
  1141. jjrh has left
  1142. Zash <style color='rainbow'>hello</style>
  1143. jere has joined
  1144. Zash And you seem to forget that using color in IRC is a crime against humanity and only annoying trolls and spammers use it
  1145. Link Mauve Zash, currently we’re using span@style for that, per-letter, it works well and allows as much or as little control as you want.
  1146. dwd has left
  1147. Link Mauve Zash, I’m actually enjoying when IRC people send spoilers in spoiler-style, and biboumi renders them as wanted.
  1148. dwd has left
  1149. jjrh has left
  1150. waqas has left
  1151. SamWhited I'm sure someone will need a layout engine, but that thing needs to not be XHTML-IM.
  1152. SamWhited We need to figure out how to create something that won't end up with such an abysmal security record.
  1153. SamWhited Extending the broken thing we have won't make that better.
  1154. Link Mauve SamWhited, I once wrote a web implementation of XHTML-IM, approximately on the same model as poezio’s, and due to that I’m quite certain it didn’t have any kind of security issue.
  1155. SamWhited Good for you, it would be the first I've ever seen.
  1156. SamWhited As always, I'm not saying it's impossible (it's not). But most people aren't going to do it right the first time.
  1157. Link Mauve That argument that it’s broken by definition is quite dubious.
  1158. Link Mauve SamWhited, we need better security guidelines, two days ago I reviewed the current ones and they are abysmal.
  1159. SamWhited Obviously, I disagree. The only way to have any inkling of security is to make the default secure and make it require work for developers to screw it up, not make the default broken and make it require work to fix.
  1160. SamWhited I agree the current ones are terrible and could be improved, but it won't fix anything.
  1161. dwd has left
  1162. Link Mauve You just discarded any web client here.
  1163. SamWhited (although we should do it either way, hopefully it will help at least a little bit)
  1164. Link Mauve The defaults of these APIs is to be insecure.
  1165. SamWhited Yes, but unfortunately I can't change that spec.
  1166. Link Mauve XHTML-IM isn’t any more or less insecure than RFC6121 here.
  1167. SamWhited If we could deprecate the web I assure you, I'd be all over it, but this arguent isn't about the web. It's about how we interop with it.
  1168. Link Mauve (Yes, I’ve seen implementations shove <{jabber:client}body/> into the DOM.)
  1169. Link Mauve SamWhited, sure.
  1170. Link Mauve It’s just a bogus argument because as a web dev you have to code extremely defensively all the time.
  1171. SamWhited Sure, you should, but I don't see what that has to do with anything
  1172. SamWhited But sure, for the sake of argument let's ignore the people that will do the obviously wrong and broken thing
  1173. SamWhited Let's talk about the people who will try to do it right, and will implement the whitelist and be careful about elements and attributes
  1174. Zash I'm not convinced we can make the web not be broken by default
  1175. SamWhited Any tiny logic bug in the XHTML-IM whitelist implementation leads to a critical issue. It doesn't matter how good you are, you will make mistakes.
  1176. SamWhited We can make something where any trivial mistake isn't a critical security issue.
  1177. Link Mauve You’re saying that argument in loop, that people will do the broken way by not reading the spec, and then that it isn’t their fault and we should make a spec that can’t be gotten wrong, but then all specs will be gotten wrong by people who don’t read them, and the loop is looped.
  1178. SamWhited I am not saying anything of the sort
  1179. SamWhited Of course you can always get something wrong, you can always introduce security issues, etc.
  1180. Link Mauve SamWhited, implementing XHTML-IM by a simple whitelist is imo not the correct way to go, see poezio’s implementation (sadly that web implementation I did was proprietary, and AFAIK never deployed publicly).
  1181. SamWhited I'm saying *we* should be writing specs defesivesly, not relying that web devs will develop defensively, or that they will never make any mistakes.
  1182. SamWhited Link Mauve: I agree, that is the correct way to go.
  1183. Link Mauve SamWhited, we can’t make any spec if the goal is to make web devs develop non-defensively.
  1184. SamWhited That's also not what I said
  1185. Link Mauve Zash, same. :(
  1186. SamWhited I said we shouldn't be *relying* on the fact that web devs will code defensively and make no mistakes.
  1187. SamWhited Everyone has to be defensive, including us. We can't just assume the burden lies entirely on the application developer.
  1188. Link Mauve Right, by providing them tested implementations, by providing them clear security guidelines, by encouraging them to do the correct thing.
  1189. Link Mauve Not by rewriting what works into something which works less well already.
  1190. Link Mauve SamWhited, sure.
  1191. SamWhited That's not good enough. I'm not disagreeing, by all means, improve the security considerations, that would be great, but it's not going to help in any significant fashion.
  1192. SamWhited We need something where the default isn't broken and where every mistake isn't an issue.
  1193. Link Mauve I disagree on that.
  1194. Link Mauve You can’t have a non-broken default on the web.
  1195. dwd has left
  1196. Link Mauve It’s just impossible.
  1197. Link Mauve Because it’s broken by design.
  1198. dwd has left
  1199. SamWhited Sure you can, a number of techniques have been discussed.
  1200. Link Mauve What we currently have works, has no intrinsic security issue, can be implemented securely (by us if any), and we should encourage that instead of replacing it with something with exactly the same potential security issues.
  1201. SamWhited Please read the mailing list thread, we're literally just reiterating the exact same things that have been said on it.
  1202. Link Mauve I have read it entirely already.
  1203. Link Mauve And no matter what you replace it with, div.innerHTML = parse_markdown(message.body); will exist.
  1204. SamWhited Why do you think we would encourage replacing it with something with the exact same issues?
  1205. SamWhited What does that have to do with anything? Yes, we can't stop people from doing non-standard and broken things with the body, that has nothing do with deprecating XHTML-IM though.
  1206. Link Mauve Deprecating XHTML-IM means people will find other ways to do formatting, the discussion we had earlier has terrifying examples of that.
  1207. Link Mauve And replacing XHTML-IM (and subsequently deprecating it) has exactly the same issues as XHTML-IM has currently.
  1208. mathieui SamWhited, because deprecating XHTML-IM without a replacement is something I am not looking upon favorably; and any replacement still has the exact same kind of issues you want to avoid
  1209. SamWhited No, again, read the list, there have been multiple suggestions that do not have the exact same kind of issues.
  1210. Link Mauve I have, and they all have them, even the JSON-based protocol break solution has them, if you don’t sanitise your input properly.
  1211. SamWhited anyways, I've got to run
  1212. Link Mauve And I, to sleep.
  1213. Link Mauve See you! \o_
  1214. dwd has left
  1215. dwd has left
  1216. dwd has left
  1217. lumi has left
  1218. SamWhited has left
  1219. Arc has left
  1220. dwd has left
  1221. arc has left
  1222. arc has joined