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


  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


  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.


  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


  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


  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


  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


  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


  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


  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


  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


  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