XSF Discussion - 2017-11-07

  1. Ge0rG has left

  2. Ge0rG has left

  3. efrit has left

  4. Arc

    no its pretty much what we already have. as long as the characters are shown i think its good. KISS.

  5. Arc

    escape characters make it overly complex

  6. Ge0rG has left

  7. moparisthebest

    I always want to say something is KISS but I wasn't sure if it translated or might insult someone :)

  8. Arc

    Keep It Simple Stupid

  9. Steve Kille has left

  10. Arc

    thats a very old one.

  11. SouL has left

  12. SamWhited

    *nods* sounds good to me.

  13. lumi has left

  14. @Alacer has joined

  15. Ge0rG has left

  16. Arc

    i was putting together a media attachements xep last winter

  17. Arc

    i think we even added support for it

  18. Arc


  19. Arc

    what we didnt resolve is ensuring that <thumb> accurately reflected the media being shared.

  20. Arc

    URLs are difficult regardless. you certainly cant have clients autoloading them because they can unmask anonymity

  21. Ge0rG has left

  22. Syndace has joined

  23. Valerian has left

  24. Valerian has joined

  25. bjc has left

  26. Ge0rG has left

  27. vanitasvitae has left

  28. Guus has left

  29. Ge0rG has left

  30. Valerian has left

  31. daniel has left

  32. daniel has joined

  33. Guus has left

  34. Ge0rG has left

  35. Ge0rG has left

  36. pep.

    SamWhited, I honestly wonder if you are ignoring all feedback from the previous XHTML-IM thread. but then it's time to sleep, I'll try to post on the list tomorrow

  37. daniel has left

  38. daniel has joined

  39. SamWhited

    I was wondering if everyone was ignoring my responses to all feedback from the previous thread.

  40. pep.


  41. SamWhited

    But maybe we shouldn't get into that, because that's going to be an unproductive discussion. Please explain what you think was ignored instead of making inflamatory statements.

  42. pep.

    Sure, I'll post on the list, going to bed now

  43. daniel has left

  44. daniel has joined

  45. Tobias has joined

  46. Ge0rG has left

  47. daniel has left

  48. Ge0rG has left

  49. daniel has joined

  50. la|r|ma has joined

  51. Steve Kille has left

  52. daniel has left

  53. Tobias has joined

  54. daniel has joined

  55. Ge0rG has left

  56. daniel has left

  57. daniel has joined

  58. Arc

    I'm really not interested in arguments that xhtml-im can be hypothetically implemented in a secure manner. its been in use for a long, long time and I'm not aware of a single secure implementation of it.

  59. Arc

    the thin benefits it provides to users cannot possible outweigh the risks

  60. Ge0rG has left

  61. Ge0rG has left

  62. Steve Kille has left

  63. Ge0rG has left

  64. sonny has left

  65. sonny has joined

  66. bjc has left

  67. bjc has joined

  68. daniel has left

  69. daniel has joined

  70. Steve Kille has left

  71. Ge0rG has left

  72. moparisthebest

    Xhtml-im's main benefit is it's easy

  73. moparisthebest

    That's also it's main downfall, easy to shoot yourself in the foot

  74. Ge0rG has left

  75. Guus has left

  76. Ge0rG has left

  77. la|r|ma has joined

  78. Syndace has joined

  79. Syndace has joined

  80. lskdjf has joined

  81. Ge0rG has left

  82. daniel has left

  83. jere has joined

  84. daniel has joined

  85. Ge0rG has left

  86. daniel has left

  87. daniel has joined

  88. Ge0rG has left

  89. Arc

    we had a presentation at ctrlh two weeks ago on "sanitized" html

  90. Steve Kille has left

  91. Arc

    different browsers parse slightly different, and in those differences, you can sneak script through

  92. Arc

    in one of the examples he used a utf8 quote inside <img width=> to get the sanitizer to believe it was all part of the value, but then include a ton of extra stuff

  93. SamWhited

    that's a good one I haven't seen before

  94. Steve Kille has left

  95. Arc

    it was one of the trickier ones, and they all were limited to certain browsers

  96. daniel has left

  97. daniel has joined

  98. Arc

    the other presentation was on a USB charging cable a guy had made with a GSM modem and SIM card slot hidden in it, and it would start uploading data from the users phone when they plugged it in

  99. Ge0rG has left

  100. Zash

    Arc: Would that still work after some round trips through an XML parser?

  101. Arc

    idk, i guess it depends on the exploit

  102. Arc

    some of them had quotes within quoted values

  103. Arc

    at least one of them relied on the sanitizer modifying the value to remove escapes

  104. Steve Kille has left

  105. Arc

    anyway they were all web-based examples and the main takeaway was if you need to allow html, put it in an iframe loaded from outside your trusted domain. such as every message from the same user from <user>.usermsg.mydomain so if they do manage to run javascript, it won't be able to access anything else

  106. Arc

    thats actually not a solution i had considered in dealing with the candy problem

  107. Arc

    ive been trying to find the video of the presentation but i dont think its been uploaded yet

  108. nyco has left

  109. nyco has joined

  110. Ge0rG has left

  111. uc has joined

  112. daniel has left

  113. daniel has joined

  114. Ge0rG has left

  115. SamWhited has left

  116. daniel has left

  117. daniel has joined

  118. Guus has left

  119. bjc has left

  120. Zash has left

  121. Zash has left

  122. Ge0rG has left

  123. Zash has joined

  124. @Alacer has left

  125. Ge0rG has left

  126. Guus has left

  127. @Alacer has joined

  128. Ge0rG has left

  129. Ge0rG has left

  130. bjc has left

  131. bjc has joined

  132. waqas has joined

  133. moparisthebest

    Arc: plain old CSP header doesn't protect you?

  134. daniel has left

  135. daniel has joined

  136. Ge0rG has left

  137. tux has joined

  138. Ge0rG has left

  139. moparisthebest has joined

  140. Tobias has joined

  141. Ge0rG has left

  142. Guus has left

  143. @Alacer has left

  144. waqas has left

  145. @Alacer has joined

  146. Ge0rG has left

  147. jcbrand has joined

  148. Ge0rG has left

  149. jcbrand has left

  150. Arc

    afaik that only works with an iframe

  151. Arc

    which means every msg must be in an iframe

  152. Arc has left

  153. Arc has joined

  154. intosi has joined

  155. jcbrand has joined

  156. jcbrand has left

  157. Steve Kille has left

  158. daniel has left

  159. daniel has joined

  160. Ge0rG has left

  161. Guus has left

  162. arc has left

  163. arc has joined

  164. Arc has left

  165. Guus has left

  166. tux has joined

  167. tux has joined

  168. arc has left

  169. arc has joined

  170. Guus has left

  171. Ge0rG has left

  172. daniel has left

  173. daniel has joined

  174. Guus has left

  175. Guus has left

  176. Steve Kille has left

  177. Ge0rG has left

  178. Steve Kille has left

  179. daniel has left

  180. daniel has joined

  181. jonasw

    CSP could work, I think, if you say that no inline script whatsoever is allowed and all scripts you need for operation come via script tags

  182. jonasw

    (and then some strict policy where those scripts can come from etc.)

  183. arc has left

  184. arc has joined

  185. arc has left

  186. arc has joined

  187. Ge0rG has left

  188. Steve Kille has left

  189. Steve Kille has left

  190. daniel has left

  191. daniel has joined

  192. Guus has left

  193. Steve Kille has left

  194. Steve Kille has left

  195. daniel has left

  196. daniel has joined

  197. Ge0rG has joined

  198. Ge0rG has joined

  199. Ge0rG has left

  200. Ge0rG has left

  201. Ge0rG has joined

  202. Ge0rG has joined

  203. Zash has left

  204. Ge0rG has left

  205. Ge0rG has joined

  206. Arc has joined

  207. Ge0rG has left

  208. Steve Kille has left

  209. Ge0rG has left

  210. jcbrand has joined

  211. nyco has left

  212. daniel has left

  213. daniel has joined

  214. nyco has joined

  215. mimi89999 has left

  216. Ge0rG has left

  217. Ge0rG has left

  218. Ge0rG has left

  219. Ge0rG has left

  220. daniel has left

  221. daniel has joined

  222. Ge0rG has joined

  223. daniel has left

  224. daniel has joined

  225. Steve Kille has left

  226. intosi has left

  227. daniel has left

  228. daniel has joined

  229. daniel has left

  230. daniel has joined

  231. goffi has joined

  232. Steve Kille has left

  233. Steve Kille has joined

  234. daniel has left

  235. daniel has joined

  236. daniel has left

  237. daniel has joined

  238. Steve Kille has left

  239. intosi has joined

  240. vanitasvitae has left

  241. arc has left

  242. arc has joined

  243. Arc has left

  244. vanitasvitae has joined

  245. Ge0rG has left

  246. ralphm has left

  247. @Alacer has left

  248. daniel has left

  249. @Alacer has joined

  250. Martin has joined

  251. daniel has left

  252. daniel has left

  253. daniel has left

  254. daniel has left

  255. daniel has left

  256. daniel has left

  257. ralphm has left

  258. Zash has left

  259. Martin has left

  260. Martin has joined

  261. jonasw has left

  262. Martin has left

  263. zinid has left

  264. marc has joined

  265. la|r|ma has joined

  266. daniel has left

  267. Ge0rG has joined

  268. daniel has left

  269. lskdjf has joined

  270. Alex has joined

  271. daniel has left

  272. intosi has left

  273. la|r|ma has left

  274. la|r|ma has left

  275. la|r|ma has joined

  276. la|r|ma has left

  277. la|r|ma has left

  278. la|r|ma has left

  279. Ge0rG has left

  280. la|r|ma has left

  281. Syndace

    About the proposed styling XEP: What do you need service discovery for? I thought a key point of this spec was, that it doesn't matter whether the receiver supports this XEP or not.

  282. vanitasvitae has left

  283. Ge0rG has left

  284. la|r|ma has left

  285. Ge0rG has left

  286. jere has joined

  287. daniel

    Syndace, yes I agree. I was meaning to propose getting rid of that. but it doesn't really hurt either so and there were more important things to talk about

  288. daniel has left

  289. daniel has left

  290. sonny has left

  291. sonny has joined

  292. Kev has joined

  293. Zash has left

  294. Tobias has left

  295. lumi has joined

  296. Kev has left

  297. daniel has left

  298. daniel has left

  299. tux has left

  300. Alex has left

  301. Guus has left

  302. Alex has joined

  303. Zash has left

  304. daniel has left

  305. mimi89999 has joined

  306. jere has left

  307. jere has joined

  308. la|r|ma has left

  309. Guus has left

  310. jabberatdemo has joined

  311. Alex has left

  312. Alex has joined

  313. Alex has left

  314. Alex has joined

  315. Guus has left

  316. Flow

    Syndace, even if disco is not required by the protocol, it's still nice that you can use it to get an idea how widespread it is implemented

  317. Syndace

    Flow, but it's a MUST

  318. Valerian has joined

  319. Flow

    Syndace, and that is problematic because? (Although I can see that a SHOULD may be ok too)

  320. jabberatdemo has left

  321. Syndace

    I just personally don't see how the discovery should be used. My $client won't behave any different if it detects support or not. It won't strip out asterisks just because the reveicing person does not advertise support.

  322. Syndace

    IMO it's always a good idea to keep specifications as thin as possible, only including things that are needed for it to work.

  323. Syndace

    And disco is definitely not required for it to work

  324. Syndace

    I mean, all clients available probably support XEP-0030 so its no additional work in that specific case but still, why require something you don't need.

  325. Guus has left

  326. Syndace

    Though I'm fine with looking at more important things first, as danial said

  327. jere has joined

  328. jubalh has joined

  329. jubalh has left

  330. Alex has left

  331. Flow

    Syndace, as I said, it allows you to get an impression how widespread the xep is implemented

  332. Flow

    You may argue that it's more overhead for little benefit, but I think I would disagree with that

  333. moparisthebest

    if it's just for "an impression for how widespread it's implemented" then it should go away

  334. moparisthebest

    that's what looking at code is for, it's not like there are so many clients you can't tell

  335. Guus

    Discussions like these are why we can't have nice things, guys. Lets fine-tune later.

  336. zinid

    Guus: for example? :)

  337. Guus

    zinid: we (myself included) are bikeshedding to much, in my opinion. That causes us to not be very productive, which in turn fuels the argument that XMPP is outdated / obsolete.

  338. Guus

    I feel that we need to build momentum.

  339. Syndace has left

  340. moparisthebest

    rushing crappy specs to production is a problem at the other end of the spectrum though

  341. zinid

    isn't all this xhtml/mardown rantings a bikeshedding? :)

  342. dwd

    moparisthebest, I'd love our problem to be that we design and implement things too quickly.

  343. dwd

    zinid, Much of it, yes.

  344. zinid

    like this is the most serious problem in xmpp?

  345. zinid

    where are the priorities?

  346. zinid

    we don't have avatars working goddamit

  347. Guus

    moparisthebest: now that I have you: could you enlighten me on a SSHL confusion that I have

  348. Guus

    did the config file syntax change between 17 and 18, or am I missing a file?

  349. moparisthebest

    it didn't change, but the sni/alpn stuff was added in 18

  350. moparisthebest

    and you used to be able to get away without a config file and specify everything as command line args, but with alpn/sni you need the config file

  351. Guus

    aaah! Then that's likely it.

  352. moparisthebest

    I need to write up the page on the wiki again, I just lost everything and haven't got around to it

  353. Guus

    I think I got confused by the duplicate file name of /etc/default/sslh.conf and a missing file that likely should go in /etc/sslh ?

  354. lskdjf has joined

  355. lskdjf has joined

  356. moparisthebest

    normally it's /etc/default/sslh (which is a shell script) and /etc/sslh.conf or /etc/sslh/sslh.conf which is the config file

  357. moparisthebest

    not sure how debian packages it these days though

  358. Flow

    Guus, I don't think that this is the reason we are not productive

  359. moparisthebest

    Guus, until I get around to it there is a bit of an explanation here: https://wiki.debian.org/InstallingProsody#XMPP_over_HTTPS

  360. moparisthebest

    even though the section title is totally wrong, just ignore that :)

  361. Guus


  362. Guus

    Flow: every bit helps.

  363. Flow

    The reason is that we try to reach consensus on an to early stage. It should be normal to have multiple (partly) competiting experimental XEPs

  364. Flow

    It would probably help to get the MUC-NG thing that is currently restricted to just what MIXs experiments with

  365. Alex has left

  366. dwd

    We should write a new file transfer protocol, too. Been a while since we did one of those.

  367. intosi has joined

  368. moparisthebest

    also how about SRV records for connecting over QUIC

  369. Kev

    Bittorrent is hot, I hear.

  370. dwd

    Kev, Not obscure enough for us. Maybe IPFS over XMPP?

  371. Valerian has left

  372. Ge0rG

    Can't we just add our chat messages to the blockchain and call it a day?

  373. Kev

    dwd: I'm referring to a particular summit discussion. 2007, maybe.

  374. Guus

    Kev: pics or it didn't happen.

  375. Kev

    It's a discussion that would have been better to not have happened.

  376. Kev

    So I'm ok with that.

  377. Guus


  378. dwd

    Kev, Ah... I think that might be the summit before I started doing anything serious.

  379. Kev has left

  380. Alex has left

  381. Guus

    You've been serious for 10 years now? auch!

  382. daniel has left

  383. dwd

    Guus, Well, serious with XMPP is around 2004, actually. But I don't think I turned up to Summits straight away. Serious with Open Standards more generally goes back to 1997 or so.

  384. edhelas

    serious dwd is serious since 1997

  385. dwd

    Well, when I say "serious"...

  386. lovetox has joined

  387. jere has left

  388. jere has joined

  389. waqas has joined

  390. bjc has left

  391. lskdjf has joined

  392. lskdjf has joined

  393. bra has joined

  394. mathieui

    https://events.ccc.de/2017/11/04/people-34c3/ btw

  395. jubalh has joined

  396. daniel

    mathieui: the people I talked to thus far aren't really interested in an actual assembly. (=having a physical space). I just submitted my xmpp talk to the fsfe assembly

  397. mathieui

    well, saying "let’s meet up at time X" should be good enough

  398. Valerian has joined

  399. Alex has joined

  400. bjc has left

  401. Guus

    oh, that's to bad. There's plenty of you going

  402. bjc has joined

  403. Alex has left

  404. bjc has left

  405. Alex has joined

  406. bjc has joined

  407. daniel has left

  408. daniel has left

  409. Ge0rG

    What is the accepted behavior for candidates in the vote on themselves? abstain once and vote 4 others? Vote 5 others? Not vote at all?

  410. daniel

    Just vote for yourself. Who cares

  411. MattJ

    As far as I understand, you're allowed to vote for yourself, so if you think you should be in, vote

  412. daniel

    Except if you believe you aren't suited for the job of course

  413. Ge0rG

    isn't that pretty awkward to candidate for a position you think you are not well-suited for?

  414. daniel

    That's the trump way

  415. Ge0rG

    that's a candidacy everyone else thinks you are not well-suited for.

  416. Ge0rG

    Okay, might be me for Council as well

  417. efrit has joined

  418. dwd

    Ge0rG, We have had people stand before specifically to make an election contested.

  419. Ge0rG

    dwd: wow. That's pretty crazy

  420. dwd

    Ge0rG, Presumably they felt they could do the job if selected, but I could see they might vote against themselves.

  421. dwd

    Or might have voted. It was some time ago.

  422. daniel has left

  423. daniel has left

  424. Kev has left

  425. intosi has left

  426. intosi has joined

  427. moparisthebest has joined

  428. Zash has left

  429. daniel has left

  430. la|r|ma has left

  431. la|r|ma has joined

  432. intosi has left

  433. intosi has joined

  434. efrit has left

  435. lumi has left

  436. uc has left

  437. mathieui

    if I understand correctly I have a flamewar to catchup

  438. moparisthebest

    I tried to revive this page if anyone is interested https://wiki.xmpp.org/web/Tech_pages/XEP-0368

  439. sonny has left

  440. sonny has joined

  441. Syndace has joined

  442. nyco has left

  443. nyco has joined

  444. jcbrand has left

  445. zinid has left

  446. Kev has left

  447. jubalh has left

  448. tux has joined

  449. Guus has left

  450. ralphm has left

  451. zinid has left

  452. jubalh has left

  453. waqas has left

  454. daniel has left

  455. Valerian has left

  456. nyco

    found this paper, has it been discussed already? https://eprint.iacr.org/2017/666.pdf

  457. Tobias has joined

  458. waqas has joined

  459. waqas has left

  460. jubalh has joined

  461. Guus has left

  462. jjrh has left

  463. SamWhited

    RE Styling, the thing I haven't gotten feedback on so far is the type of styling itself. Does this encompase peoples needs as far as IM goes? (I know some people want a full formatting and layout engine, but that's out of scope)

  464. SamWhited

    Or is it too much even? Eg. is there any point in having ~strikeout~ which I doubt anyone will ever use?

  465. Zash has left

  466. Zash has left

  467. Zash has left

  468. Zash has left

  469. Zash has left

  470. Zash has left

  471. Zash has left

  472. Zash has left

  473. Zash has left

  474. Zash has left

  475. jjrh has left

  476. jjrh has left

  477. sonny has left

  478. sonny has joined

  479. jjrh has left

  480. jjrh has left

  481. Syndace has left

  482. sonny has left

  483. sonny has joined

  484. Guus

    SamWhited: I

  485. Guus


  486. Guus

    I must admit I've not read it in detail, but as far as I'm concerned, a basic set (bold, underline, italic, with perhaps a couple of others) is more than enough for a boatload of usecases, therefor making it a practical XEP

  487. Guus

    There's likely other use-cases, but there's no need for one XEP to rule them all, right?

  488. Steve Kille has left

  489. Steve Kille has left

  490. Steve Kille has joined

  491. jonasw

    SamWhited, under the assumption that proper layouting is not possible, I think the things you include there are sufficient.

  492. Steve Kille has left

  493. jjrh has left

  494. jjrh has left

  495. Valerian has joined

  496. Guus has left

  497. Steve Kille has left

  498. Steve Kille has left

  499. intosi has left

  500. arc has left

  501. Steve Kille has left

  502. Steve Kille has left

  503. arc has joined

  504. Kev has left

  505. SamWhited

    Guus: is underline a requirement for you? Having that makes more sense to me than strikeout, but I don't have it right now

  506. arc has left

  507. valo has joined

  508. arc has joined

  509. jonasw

    I don’t think that underline is a good idea in general.

  510. SamWhited

    yah, I'm not sure how useful that one is either; just slightly more useful than centerline

  511. SamWhited


  512. jonasw

    I’d say the opposite.

  513. jonasw

    we already have two ways to emphasise things in that protoxep

  514. SamWhited

    That's fair too, semantically they're probably the same

  515. SamWhited

    Now I'm even less sure :)

  516. arc has left

  517. arc has joined

  518. sonny has left

  519. sonny has joined

  520. sonny has left

  521. sonny has joined

  522. sonny has joined

  523. sonny has joined

  524. sonny has joined

  525. sonny has joined

  526. sonny has joined

  527. sonny has joined

  528. valo has joined

  529. arc has left

  530. arc has joined

  531. lumi has joined

  532. arc has left

  533. lovetox has left

  534. lovetox has joined

  535. moparisthebest

    I think _underline_ is supported in gajim though

  536. moparisthebest

    yep, that underlined it

  537. jonasw

    that some client supports it doesn’t make it a good thing

  538. moparisthebest

    why not, specify what's already implemented most places, make them all optional, done

  539. Zash

    you keep repeating "most places/clients"

  540. jonasw

    > We are not typing on typewriters any more. We are using computers. Word processors, HTML, CSS. Underlining means a hyperlink. Period. If you want to emphasize something, use bold, italics, indents, all caps, or any combination thereof.

  541. edhelas has left

  542. jonasw

    https://writers.stackexchange.com/a/4680 kinda funny

  543. Guus

    SamWhited: underline is not a requirement for me, but it's somewhat of a default featureset, right?

  544. Guus

    but, to be honest, I don't care to much. My point was: keeping it simple is good.

  545. jonasw

    I don’t think you can do that anymore in e.g. Markown or rST

  546. SamWhited

    Guus: I'm not sure; Slack and Whatsapp don't support it.

  547. SamWhited

    And I think they count as "most things" more than Gajim does.

  548. SamWhited

    I'll leave it off for now for the sake of simplicity; we can add something later if it's a problem.

  549. edhelas has joined

  550. SamWhited

    Might take strikeout out too

  551. Steve Kille has left

  552. arc has joined

  553. moparisthebest

    SamWhited, what about disco

  554. Guus

    SamWhited: as I said: I'm not bothered by the exact set. I'm just gratefull you're keeping it short/simplish.

  555. arc has left

  556. arc has joined

  557. arc has left

  558. arc has joined

  559. SamWhited

    moparisthebest: oh yah, I saw that discussion. I'm fine with removing it.

  560. SamWhited

    Doesn't matter to me either way

  561. SamWhited

    I was going to wait to see if it was accepted or not before pushing more changes

  562. Guus has left

  563. arc has left

  564. arc has joined

  565. arc has left

  566. arc has joined

  567. arc has left

  568. arc has joined

  569. tux has left

  570. arc has left

  571. arc has joined

  572. arc has left

  573. arc has joined

  574. ralphm has joined

  575. daniel

    > Might take strikeout out too I think the ~ character is rare enough that it won't cause trouble and slack and whatsapp are doing it. So in the interest of making transports work I'd just leave it in.

  576. daniel has left

  577. Zash

    Let me tell you about my ~/stuff

  578. moparisthebest

    that's fine you didn't put it twice

  579. moparisthebest

    wait is ~/stuff/~ a valid path?

  580. daniel

    Zash: that's lacking the closing keyword though

  581. moparisthebest

    I don't think I want to know...

  582. jonasw

    moparisthebest, it is

  583. Flow

    why shouldn't it be a valid path?

  584. Valerian has left

  585. moparisthebest

    dangerous to delete :)

  586. Guus has left

  587. intosi has joined

  588. Flow

    jonasw, just upvoted https://writers.stackexchange.com/a/4680, nobody needs underline if you don't write on a board or on a paper

  589. jonasw

    Guus, could you cancel the second-newest build please? https://hub.docker.com/r/xmppxsf/xeps/builds/

  590. jonasw

    I may be stupid, but (re styling): > Matches MUST NOT extend over newlines and MUST start with a whitespace character or be the beginning of the line or the byte stream. how does that match with the example "*emphasized*foo*emphasized*" where "foo" is not emphasized?

  591. daniel has left

  592. daniel has left

  593. Guus


  594. arc has left

  595. jonasw

    Guus, thanks -- even though I don’t see it in the UI yet.

  596. SamWhited

    good eye, that's broken

  597. SamWhited

    I have those rules tweaked a bit based on feedback locally anyways

  598. daniel has left

  599. jonasw

    SamWhited, re standards@: > A 100% solution with no false positives would be great, but I > can't think of a way to do it without significantly more complexity or a > formal markup language (which is against the requirements I drew up > based on previous discussions). what’s wrong with a formal markup language if we’re gonna need a parser which can handle context-free grammars anyways?

  600. daniel

    I'd love to know what matrix is doing and eventually try to convince them to use the same syntax (to make transports) but matrix is impossible to Google

  601. Guus

    (now I _really_ cancelled it)

  602. SamWhited

    jonasw: duplicate content, even more complexity, etc.

  603. arc has joined

  604. jonasw

    IIRC from my compiler construction lectures you need an LR parser for a CFG which is already quite a complex beast.

  605. SamWhited

    It's really not

  606. SamWhited

    I don't think you need an LR parser here though

  607. jonasw

    would have to take a deeper look. In any case, writing down the grammar formally is probably a good idea

  608. SamWhited

    I think we're over thinking this. I've got an implementation which I'll push somewhere soon and it's relatively straight forward.

  609. SamWhited

    I'm not even bothering to build an AST (though doing that would make things much faster)

  610. jonasw

    Guus, yay :-)

  611. Zash

    What's that, just s/\*.*\*/<b>&</b>/ and stick it in innerHTML?

  612. Zash

    Good idea

  613. jonasw

    Zash, you forgot the \b before the \*, they must be on word boundaries (essentially)

  614. SamWhited

    Actually, if I remove escaping and strike out it may be possible to make a few minor tweaks and make this regular

  615. SamWhited

    That would simplify things a lot

  616. Kev has joined

  617. jonasw

    hm, doesn’t the precedence of block over monospace over other inline already make this non-regular?

  618. SamWhited

    ah yah, you're right, having block level things probably still make that impossible

  619. Valerian has joined

  620. goffi has left

  621. Alex has left

  622. Ge0rG

    Just for reference. The last time I tried to escape on slack, I have given up after three futile correction attempts.

  623. SamWhited

    That's probably a good reason to remove the escape chars

  624. Ge0rG

    Maybe there are no escape chars on slack, and this is why I failed. We'll never know.

  625. SamWhited

    I did look at their docs and I don't remember any mention of a way to escape formatting chars

  626. Guus

    At this point, let's publish something and start experimenting with implementations

  627. Ge0rG

    Yeah. You can't escape slack

  628. SamWhited

    Guus: There are at least two implementations already :) (Daniel and I both have one)

  629. Guus

    awesome. This is in Conversations

  630. Guus


  631. Guus


  632. Guus

    Foo *bar*

  633. SamWhited

    Guus: https://github.com/siacs/Conversations/tree/styling

  634. Guus has left

  635. SamWhited

    It's just an experimental branch

  636. Guus

    ah ok :)

  637. SamWhited

    I don't think it's complete either. I also have one in library form that I will push somewhere "soon"

  638. Alex has joined

  639. Guus

    Cool. Let's start gaining experience with this, and discuss it from there.

  640. daniel

    Guus, SamWhited: the current beta has this.

  641. Ge0rG

    I'm sure it will freak out admins, developers and mathematicians

  642. Guus

    let's see if I can hack this in Spark real quick

  643. arc has left

  644. arc has joined

  645. intosi has left

  646. Guus has left

  647. Guus

    test _foo_ *bar* ~foobar~

  648. Guus

    why's ~this~ bold and strikethrough?

  649. Guus

    ah, doesn't reset

  650. Valerian has left

  651. Guus has left

  652. Guus has left

  653. Guus

    okay. Split by whitespace, checking first and last character only - Not what's in the xep, but it'll give me some feelign on how this looks

  654. Guus

    so far, I'm not unhappy.

  655. Kev

    I've not looked at the protoXEP yet, been busy. Is it basically *bold* /italics/ _underline_ ?

  656. lskdjf has left

  657. SamWhited

    *bold*, _italics_, and ~strikethrough~

  658. SamWhited

    (although I was thinking of removing ~strikethrough~)

  659. Kev

    Can we have /italics/ and _underline_ please? :)

  660. Kev

    If we do that, I have an implementation that predates the protoXEP by about 15 years.

  661. SamWhited

    /italics/ seems nice but also likely to conflict with paths and URLs, Slack and Whatsapp both do _italics_ so I felt it was best to immitate what they were doing, but I coudl be convinced otherwise

  662. Kev

    Slack and Whatsapp both annoy me for getting this wrong :)

  663. SamWhited

    I'd rather follow convention unless there's a compelling reason not to

  664. SamWhited

    (but I do agree that I think those make more sense)

  665. Kev

    See above - I've got about 15 years of convention for you :D

  666. Guus has left

  667. Kev

    But it depends what you want.

  668. Tobias

    but silicon valley knows better

  669. Kev

    If what you want is an input format, it doesn't matter much.

  670. Kev

    If what you want is something that falls back to plain text gracefully, then /italic/ and _underline_ are better.

  671. dwd

    Kev, Gajim also does *bold* /italics/ and _underline_, but no ~strikethrough~.

  672. Guus

    /italics/ is sooo 1997

  673. Guus

    I've not seen that since.

  674. dwd

    Guus, Yes, and your point?

  675. Guus

    who said I had a point?

  676. SamWhited

    I'm not sure that they are better though, regardless of how nice they look people are used to Slack and Whatsapp I think. Then again, I'm not sure it really matters all that much either way.

  677. Kev

    SamWhited: Except Slack never renders this.

  678. Guus has left

  679. Kev

    If you send *something* in Slack, you only ever see the bold, not the surrounding *

  680. Kev

    So people aren't used to seeing _somethingitalic_

  681. SamWhited

    Oh yah, it's a tiny bit different, but as far as the characters that people type goes they're used to writing _italic_

  682. Guus

    (I like how this is rendering for me now :P )

  683. SamWhited

    I assume… I haven't used Slack except very briefly, I just read their docs.

  684. Zash

    You beat

  685. Kev

    I'm used to writing /this/ in Slack and wondering why they don't support italics.

  686. Zash

    You mean <i>hello</i>path/ is what you see in places

  687. Kev

    This is not a hill for me to die on, but if we've got a 15 year old convention in existing clients, it seems weird to break that.

  688. SamWhited

    yah, I would say this is entirely bike sheddy, except that I do think the /path/to/foo is potentially an actual problem

  689. SamWhited

    What clients do this convention?

  690. SamWhited

    Gajim? Any others?

  691. dwd

    Kev, I have to admit that although /italics/ is far more natural to me, I never use it (or _underline_ either).

  692. Kev

    I put it in Psi about 15 years ago.

  693. moparisthebest

    it's not a problem if you leave all the characters always though SamWhited

  694. SamWhited

    That's also fair

  695. jubalh has joined

  696. SamWhited

    I'm not saying that this should necessarily be a trendy popularity contest, but I suspect more people use Whatsapp and Slack than Psi and Gajim, so if it's just a matter of "people are used to this, it's a convention" then I'd still want to stick with what's in the protoxep now.

  697. jonasw

    people are used to the input convention, not to the wire format (they don’t care about it, but we should)

  698. jonasw

    finally the build finished: https://xmpp.org/extensions/inbox/markup.html

  699. SamWhited

    jonasw: what is the number in span start/end?

  700. jonasw

    it’s explained.

  701. jonasw

    (codepoint in XML character data)

  702. dwd

    jonasw, Read that already when I noticed the github notification. I'm undecided on that approach. I do think some of the failure cases with overlapping spans and blocks and so on are going to be weird.

  703. SamWhited

    ah sorry, I was just looking for that earlier and didn't see it

  704. SamWhited

    What happens if I put it in the middle of a grapheme cluster composed of multiple code points?

  705. jonasw

    SamWhited, it gets split when rendering.

  706. jonasw

    I presume

  707. dwd

    SamWhited, We've used a similar approach in <references/>, BTW.

  708. SamWhited


  709. jonasw

    depends on your rendering engine I think

  710. SamWhited

    I wondered about it in references too actually

  711. jonasw

    I was already wondering whether that is something which can be used as an exploit, but aside from splitting emojis and possibly cutting of accents from letters I don’t see how this could be abused

  712. jonasw

    but then again, unicode is weird.

  713. vanitasvitae

    jonasw: looks nice

  714. Guus

    good job on formulating an alternative, jonasw

  715. vanitasvitae

    jonasw: the introduction seems weird. I'm missing a "this approach thrives to solve the mentioned issues in the following way: ..."

  716. Guus

    on first glance, I'm inclined to prefer the less complex version, but I love to see a documented alternative

  717. jonasw

    vanitasvitae, I always forget that :)

  718. daniel has left

  719. SamWhited

    minor nit: if you're sending an encrypted body this leaks information about the body. Probably not in any significant way, but it seems worth mentioning in the security considerations or somewhere.

  720. jonasw

    Guus, I like the simplicity of the *input format* Sam suggests. I don’t like having it as the wire foramt.

  721. Valerian has joined

  722. Guus

    jonasw, understood

  723. goffi has joined

  724. Guus

    (also, should that have been bold?)

  725. jonasw

    no, my client can only into XHTML-IM and I’m too lazy to do that

  726. Ge0rG

    SamWhited: I think the biggest design failure of omemo is to only encrypt the body...

  727. daniel

    > minor nit: if you're sending an encrypted body this leaks information about the body. Probably not in any significant way, but it seems worth mentioning in the security considerations or somewhere. This is a problem with all the references and annotations XEPs

  728. jonasw

    SamWhited, good point. Admittedly, I was in a bit of a hurry because I only thought of this last night and I felt it’d be good to have the idea out before next council meeting.

  729. daniel

    But as Ge0rG said this is rather a problem with omemo than with those xeps

  730. Kev

    daniel: I think the reverse is actually true.

  731. Kev

    This is a problem with any encryption scheme that only encrypts the body.

  732. Kev

    Ah, which you then said :)

  733. jonasw

    isn’t that what daniel said?

  734. SamWhited

    As I've previously expressed, I think it only makes sense for OMEMO (or anything really) to encrypt text nodes, not actual XML (now you've got a weird mixed-mode stream and that's going to lead to worse security issues later)

  735. jonasw


  736. Ge0rG

    We need to encrypt the meta data finally. That's what the services are after!

  737. Kev

    My hotel wifi here is *not* fast.

  738. SamWhited

    So even if it encrypted more than the body, I don't think it could encrypt this.

  739. arc has left

  740. arc has joined

  741. SamWhited

    But that's a discussion for another time.

  742. Guus

    I'm off. goodnight everyone.

  743. Kev


  744. SamWhited


  745. jonasw

    nighty Guus

  746. daniel

    > As I've previously expressed, I think it only makes sense for OMEMO (or anything really) to encrypt text nodes, not actual XML (now you've got a weird mixed-mode stream and that's going to lead to worse security issues later) It's a quite complicated problem. That's probably why nobody has solved it yet

  747. Ge0rG

    Mixing data and meta data is known to fail security since Captain Crunch. We should have learned from that by now.

  748. goffi

    jonasw: fantastic proposal, I really love it, thanks a lot for that !

  749. Arc has joined

  750. jonasw

    goffi, you’re welcome

  751. SamWhited

    jonasw: we've already discussed this a little bit I think, but what do you see as the benefits of doing it this way?

  752. moparisthebest

    it would be quite neat to do hop-based encryption, like encrypt entire thing so your server knows to send it to otherserver.net but not who@otherserver.net, and that server can see who to send it to but not who it came from or whatever

  753. jonasw

    SamWhited, I’m going to head to bed in a few minutes, so I don’t think we can discuss this at length now.

  754. moparisthebest

    that's getting more onion-routing-y though and is starting to sound like a protocol not-xmpp

  755. SamWhited

    sounds good

  756. Ge0rG

    moparisthebest: that fails for presence

  757. Ge0rG

    moparisthebest: there are protocols not xmpp that do it, like tox

  758. moparisthebest

    well tox is p2p without any hops right?

  759. moparisthebest

    no servers anyway, I think

  760. jonasw

    SamWhited, it provides the protocol break we need to make rich text safer (compared to XHTML-IM) and provides the formality which is needed to make it future-proofer (compared to ad-hoc text formats).

  761. Zash

    moparisthebest: p2p in the real world has servers, only they call them super nodes or something

  762. jonasw

    SamWhited, I think that we shouldn’t be mixing input conventions with wire-level markup.

  763. SamWhited

    jonasw: why not?

  764. jonasw

    this is somewhere between a matter of design principle and concern about interoperability.

  765. jonasw

    because input conventions only matter for humans, and may differ between different user interfaces

  766. SamWhited

    I don't see why interoperability would be better or worse with an XML based wire format vs. a plain-text-with-magic-characters based wire format

  767. moparisthebest

    I'm saying like xmpp setup is like A (client) -> B (server) -> C (server) -> D(client)

  768. moparisthebest

    B only needs to know it's coming from A and going to C, not about D, C only needs to know it's coming from B and going to D, not about A

  769. SamWhited

    I'm actually worried that making it more extensible and "future proof" as you put it will be a bad thing here. It's not necessary and I suspect will just lead to feature bloat in the long run

  770. jonasw

    SamWhited, when you start to define new meta-characters or obsolete existing ones, the messages are interpreted differently.

  771. andrey.g has left

  772. moparisthebest

    and any content besides those specific routing instructions can be encrypted e2e so only A and D can see them

  773. SamWhited

    jonasw: that doesn't bother me at all

  774. jonasw

    SamWhited, I know.

  775. jonasw

    that’s what worries me.

  776. SamWhited

    that's already what happens when I add a new smiley or something, and it's a minor anoyance at worst

  777. Ge0rG

    It's a consistent annoyance.

  778. SamWhited

    True, but still a minor one.

  779. jonasw

    I don’t see why we have to buy that minor annoyance which is simply going to happen (I don’t approve of messengers which replace text with emoticons either, by the way) if there are alternatives.

  780. daniel

    fwiw i do see the benefit of jonasw approach. but i don't see me implementing this anytime soon due to the omemo problem

  781. SamWhited

    If there were good alternatives I'd agree, but I think the trade offs on the alternatives are worse.

  782. SamWhited

    And if it weren't such a minor problem that doesn't affect most people

  783. Ge0rG

    daniel: fix omemo then...

  784. jonasw

    SamWhited, let’s turn this around, what’s your problem with my approach?

  785. daniel

    Ge0rG, i do make some money with Conversations. but unfortunatly not enough to go down *that* rabbit hole

  786. SamWhited

    jonasw: It's a lot more complexity. How does it interact with message editing, for example?

  787. SamWhited

    How does it interact with OMEMO, OTR, etc? Does it leak information?

  788. jonasw

    SamWhited, do you mean message correction?

  789. SamWhited

    yah, that one

  790. jonasw

    message correction is clear on that one: the new <message/> replaces the old

  791. jonasw

    so you’d include the markup again.

  792. Ge0rG

    SamWhited: the corrected message needs to have its own markup xml

  793. SamWhited

    ah yah, that one actually makes sense I suppose

  794. jonasw

    SamWhited, interaction with OMEMO and OTR etc. is at least better than with XHTML-IM (instead of leaking the full plaintext (hi pidgin!) or having no markup at all, you can leak only the markup or have no markup at all. that’s a step forward or so...)

  795. daniel

    Ge0rG, also my last attempts in starting a discussion on stanza content encryption didn't go anywhere

  796. Ge0rG

    SamWhited: also you can just strip the markup and still have human readable body

  797. SamWhited

    Ge0rG: You can do that in either case

  798. Ge0rG

    And screen reader readable

  799. moparisthebest

    or, with SamWhited 's approach, you can do nothing and still have a human readable body

  800. Ge0rG

    And no false positives

  801. Ge0rG

    moparisthebest: for a limited subset of "human readable"

  802. jonasw

    daniel, can you point me to it? I can’t find it in my local archives.

  803. jonasw

    (a subject line or keyword to search for will do)

  804. moparisthebest

    works for everything else so

  805. SamWhited

    Anyways, I'm not saying that this is bad, just more complex and I don't see any significant benefit that's not outweighed by the disadvantages.

  806. moparisthebest

    I might have just missed it but is &gt; 1 index/character with respect to start/end or 4 ?

  807. jonasw

    moparisthebest, 1.

  808. jonasw

    "XML character data" => entities are already decoded

  809. jonasw

    sane XML parsers won’t hand you entities anyways

  810. Ge0rG

    But it seems that different users apply different weights to different disadvantages

  811. moparisthebest

    I saw XML character data, I didn't know what that meant though

  812. jonasw

    moparisthebest, in short, that what your XML library hands you when you ask for an elements text.

  813. moparisthebest

    the main disadvantage is all clients have to implement this or any formatting is lost

  814. moparisthebest

    wheras if I say something *really* important

  815. moparisthebest

    you get it regardless

  816. daniel

    jonasw, mail is in the 'omemo discussion summary 2017' thread and my particular mail is from june 22nd

  817. jonasw

    moparisthebest, that’s the better case I think

  818. jonasw

    moparisthebest, with Message Styling, all *sending* clients have to implement it or their message may be incorrectly and unexpectedly formatted

  819. edhelas has joined

  820. moparisthebest

    no, sending clients don't have to implement it at all

  821. nyco has joined

  822. jonasw

    if we’re going to have incompatibilities between markup interpretation, I prefer them to be vanishing markup instead of markup which apperas out of nothing

  823. moparisthebest

    no one is using a WYSIWYG editor to bold something

  824. moparisthebest

    they are just typing *bold*

  825. jonasw

    moparisthebest, they do, if they don’t want their line which starts with "> " to be interpreted as blockquote.

  826. jonasw

    moparisthebest, you’re assuming that all clients are operated by humans.

  827. moparisthebest

    I feel like a broken record here, but again, everything has been doing it since way before xmpp

  828. moparisthebest

    so people are used to it, and it's fine

  829. jonasw


  830. jonasw

    as promised, heading to bed

  831. moparisthebest

    email for example, IRC for another

  832. Ge0rG

    moparisthebest: and the sending client can convert that to bold in the input line and send well defined wire format. Or you can press undo and send ** instead

  833. SamWhited

    Yah, it seems like it's been firmly in the "good enough" category for many, many years.

  834. moparisthebest

    hmm then I have to care though

  835. daniel

    i can see myself adding jonasw markup to outgoing unencrypted messages on top of SamWhited's styling

  836. daniel

    it doesn't hurt

  837. Arc

    Tobias: IRT xep0385, I have an objection to table 2. First and most notable, Opus is an IETF standard for audio and was left out entirely.

  838. moparisthebest

    I do immensly prefer jonasw's solution as opposed to duplicating the text in a different element

  839. SamWhited

    I agree with that

  840. moparisthebest

    in fact, add all the xhtml-im features to that and publish

  841. SamWhited

    I do not agree with that and see it as the most significant downside to the spec

  842. moparisthebest

    it feels like a mandatory whitelist kind of

  843. moparisthebest

    I suppose mr. evil could still include <script> directly in the body

  844. moparisthebest

    but I guess that's always a danger for a dev dumb enough to .innerHTML it

  845. jubalh has left

  846. Ge0rG

    And then a client needs to put styling into the body, markup into a related xml and add xhtmlim

  847. efrit has joined

  848. moparisthebest

    I don't think so

  849. jjrh has left

  850. goffi has left

  851. andrey.g has joined

  852. Guus has left

  853. andrey.g has joined

  854. andrey.g has joined

  855. pep.

    moparisthebest, what you type as your input doesn't have to be what the client sends verbatim. If you want to use markdown (or whatever else, poezio uses ^C<key>) as your input format, fine. But don't send that on the wire and let the receiving client decide on what/how to display it

  856. andrey.g has joined

  857. moparisthebest

    pep., I get it, and totally agree for complicated formats, but don't overcomplicate something simple that has existed since before xmpp

  858. pep.

    How does that change anything to what I just said above. As a client I still want to decide what I display

  859. andrey.g has joined

  860. jjrh has left

  861. moparisthebest

    pep., do you understand that I meant to emphasize *this* in my message though?

  862. pep.

    "it's always been how we've done and it works fine". I don't have an example offhand but I'm sure this is not the best argument out there

  863. moparisthebest

    or do you need some fancy wire protocol to understand that?

  864. moparisthebest

    for the limited subset of markup in that one particular xep, it works perfectly fine

  865. pep.

    Still, what if I don't want to understand it, what if I can't understand it

  866. moparisthebest

    if you want to get more complicated, do so in some other way

  867. pep.

    As it's been said on the list already

  868. andrey.g has joined

  869. moparisthebest

    then I guess tough?

  870. moparisthebest

    at least you had a better chance than if you didn't get ** because your client didn't implement fancy-new-xep

  871. pep.

    Nice for an eXtensible protocol

  872. jjrh has left

  873. andrey.g has joined

  874. sezuan has joined

  875. jjrh has left

  876. Alex has left

  877. andrey.g has joined

  878. pep.

    SamWhited, Example 8, isn't the nested version missing a space?

  879. Guus has left

  880. Guus has joined

  881. pep.

    Or maybe the sentence above can be reforumlated a bit

  882. SamWhited

    pep. no, I need to clarify that. If you parse the outer quote as a block, then parse the inner quote then it's the "start of the byte stream"

  883. pep.

    Or maybe the sentence above can be reformulated a bit

  884. pep.


  885. SamWhited

    at least, that's how it ended up working in my little parser which recursively parses inside blocks, and it seems sane

  886. SamWhited

    I was debating if I needed to be strict about specifying that though or if that's just going to confuse people. Overspecifying is sometimes as bad as underspecifying.

  887. pep.

    But then some clients might render "> > " different from ">> "

  888. daniel

    SamWhited: the XEP could probably use a few more complicated examples at some point. Like something people could copy past into their unit tests

  889. SamWhited

    daniel: agreed. I started on a unit test suite as well which I'll push when I push out my implementation

  890. daniel

    But we should nail down the syntax and test everything a little bit more before going through the troubles

  891. SamWhited


  892. SamWhited

    Conveniently, the commonmark parsing rules are basically the same (I mostly stole them), so you can test things (albeit with slightly different characters) using their tools more or less

  893. SamWhited


  894. moparisthebest

    pep., point is people have typed like this since before xmpp, type like this now, and will type like this later, whether someone standardizes the rules or not

  895. moparisthebest

    what exactly is the problem with it? not enough XML?

  896. jubalh has joined

  897. Zash has left

  898. SamWhited

    I think I'm going to move the block/span stuff into implementation details and make that non-normative. If a few clients have incompatible edge cases it's no worse than today (where lots of clients effectively implement this slightly differently), then I can still provide guidance without overly limiting people. </thinking outloud>

  899. pep.

    moparisthebest, you pollute the plaintext. As people have said already: it's not easily interoperable. Once you say italic is not // not __ anymore, what happens to __? people will still continue to display both because "tough luck"? (as you say) Not easily extensible. Adding more and more meta-characters removes choices from the selection of characters I can use to type text. Maybe for you it is "human readable", and for others in your own circles, but that's the extent of it. You are not taking into account other people, bots, you are not taking accessibility into account.

  900. SamWhited

    "not easily extensible" is a feature.

  901. pep.

    So you're fine cluttering client markups until the end of times

  902. SamWhited

    yes, although I wouldn't phrase it that way

  903. daniel has left

  904. moparisthebest

    right you don't want it extendable at all

  905. moparisthebest

    it's a de-facto standard anyway

  906. pep.

    no it's not

  907. pep.

    I was reading just above Kev uses // for italics

  908. pep.

    You are using __

  909. moparisthebest

    this happens and will happen regardless of if we standardize

  910. pep.

    moparisthebest, no that's the point

  911. moparisthebest

    yea, I don't think it matters, I also use /italics/

  912. pep.

    if we standardize it shouldn't happen

  913. moparisthebest

    gajim supports that by the way

  914. pep.

    That's the whole point

  915. SamWhited

    pep. I think he meant that most things are already using some kind of indicator in the text and people will keep doing that. Not the specific indicators

  916. Guus has left

  917. moparisthebest


  918. moparisthebest

    I mean most people write like that anyway, regardless of any client support

  919. moparisthebest

    and then also lots of xmpp and non-xmpp clients mark it up based on those

  920. pep.

    SamWhited, agreed, people have been using that, and as I said above I wouldn't mind the client using it as input, but I really not keen on sending that on the wire

  921. Guus has joined

  922. moparisthebest

    that's fine for something that isn't already widely used I guess

  923. SamWhited

    My IRC client, one of my XMPP clients, my email, and probably other things I'm forgetting already send that on the wire and it works pretty well.

  924. moparisthebest

    and as you said slack and whatscrap

  925. pep.

    No, it works for you and your circles, because they know

  926. moparisthebest

    I thought whatscrap was for the mom's of the world

  927. SamWhited

    It also works for every non-technical person who uses whatsapp that I know (and that's a lot more than the technical people in my XMPP circles)

  928. pep.

    Slack people don't know, Mattermost people don't know

  929. pep.

    They only have to click

  930. pep.

    normal people don't use IRC so I think I can safely discard that one. Or they use some fancy client that handles that for them, still you rarely see non-technically people willingly use it, Same for email actually, it's not the same usage at all between technical and non-technical people

  931. pep.

    Non-technical people often send html and there you have rich content

  932. la|r|ma has left

  933. pep.

    (and fancy colors, eww)

  934. moparisthebest

    are you saying XMPP has more users than email and IRC ?

  935. Ge0rG

    Non technical people don't use the markup characters in normal use, because they don't need to paste directory paths nor math formulas

  936. moparisthebest

    because uh, seems wrong

  937. pep.

    moparisthebest, not "more"

  938. pep.

    Different kind of users I believe, or at least aiui that's a target for the XEP

  939. Valerian has left

  940. pep.

    Because Slack and Whatsapp are cited a number of times

  941. moparisthebest

    what kind of users are you trying to target who's needs aren't met? I'm confused

  942. moparisthebest

    because you mentioned IRC which is more technical and whatsapp which is the exact opposite

  943. moparisthebest

    both implement this same thing

  944. pep.

    No I'm just trying to extrapolate who you are thinking the XEP is targetting

  945. pep.

    I didn't mention IRC, Sam did

  946. moparisthebest

    everyone on the internet does this type of thing

  947. moparisthebest

    ‎[04:48:57 PM] ‎pep.‎: normal people don't use IRC so I think I can safely discard that one.

  948. pep.

    Yes, read a sentence above now

  949. pep.

    SamWhited> My IRC client, one of my XMPP clients, my email, and probably other things I'm forgetting already send that on the wire and it works pretty well.

  950. moparisthebest

    I've never heard of an IRC client with a WYSIWYG editor

  951. moparisthebest

    they don't even have passwords without messaging a bot

  952. pep.

    maybe you don't know about sasl, but that's how of the scope for tonight

  953. Valerian has joined

  954. moparisthebest

    that's a super recent extension not everything implements though :)

  955. moparisthebest

    and server-side, it still gets passed through to the nickserv bot

  956. daniel has left

  957. SamWhited

    This went really off the rails in the time it took me to discuss something at work and then come back :)

  958. SamWhited

    I'll be interested to read the backlog and see how it got to SASL

  959. moparisthebest

    bottom line is if it's good enough for email, IRC, and whatsapp, then it's fair to say it's good enough for xmpp

  960. pep.

    SamWhited, same here :/

  961. moparisthebest

    because that covers the gamut of *all* internet users

  962. Kev

    SamWhited: No, it wouldn't.

  963. Kev

    No, you won't, rather.

  964. moparisthebest

    I'd love to hear about the internet user that doesn't use email or whatsapp

  965. Kev

    You might think you will, but it'll be a big disappointment when you get there.

  966. jjrh has left

  967. pep.

    Kev, :)

  968. SamWhited


  969. Guus has left

  970. Kev

    OTOH, I just found a presence leak in 6121, so that's nice.

  971. SamWhited

    oh fun

  972. Guus has joined

  973. andrey.g has joined

  974. Kev

    Actually, it's not a presence leak, just an inconsistency. Drat.

  975. daniel has left

  976. andrey.g has joined

  977. daniel has left

  978. pep.

    SamWhited, otherwise, if you have time to answer my direct reply to your comments that'd be nice

  979. jjrh has left

  980. lovetox

    i could live with both approaches, if Sams approach is *really* simple, so nothing fancy like lists and stuff, keep it simple and readable even if a client doesnt support it

  981. SamWhited

    pep. direct reply?

  982. andrey.g has joined

  983. pep.

    like the small block of text before moparisthebest barged in

  984. moparisthebest

    hey I've been here the whole time :P

  985. moparisthebest

    oops :P was sent as text and rendered as a smiley, need a xep and new wire format

  986. jjrh has left

  987. SamWhited

    pep. I don't see it

  988. lovetox

    jonasw, approach i like because i dont need to write parsers for that, seems simple and its more of a replacement for xhtml

  989. daniel has left

  990. pep.

    SamWhited, https://bpaste.net/raw/14760ce8f04d

  991. Kev has left

  992. moparisthebest

    lovetox, completely agree there

  993. SamWhited

    Please hold, asking a friend who knows nothing about computers "How do you make text bold in Whatsapp?" to see what they say

  994. daniel has left

  995. pep.

    SamWhited, yeah, one example won't discard all of this. I do agree I don't have statistics on this, but neither do you

  996. pep.

    SamWhited, yeah, one example won't discard all of this. I do admit I don't have statistics on this, but neither do you

  997. marc has left

  998. lovetox

    Sams approach also seems like a: Many clients do this anyway so lets make a XEP out of it

  999. moparisthebest

    yea, why not?

  1000. daniel has left

  1001. Guus has left

  1002. andrey.g has joined

  1003. edhelas

    because sometime it's not because a lot of persons are doing something that it's good ?

  1004. daniel has left

  1005. lovetox

    i dont really feel that this needs a xep, a client can show this that way and have a config option to turn it off like gajim has for proably a decade

  1006. Guus has joined

  1007. SamWhited

    lovetox: I more or less agree with you, but I was told that we can't deprecate XHTML-IM until there's an alternative (and maybe if nothing else this will introduce a little consistency or broaden support for simple formatting)

  1008. jjrh has left

  1009. SamWhited

    pep. in that case if you're allowed to argue with no data and I'm not allowed to at least ask around, I'm not sure how you want me to respond to that. I don't think it's a problem, people use whatsapp, it does this. I don't think it has a bold button on Android (unless they've added one), and people still send bold text.

  1010. daniel has left

  1011. SamWhited

    The people who really, really won't understand this aren't likely to use it, so no harm done. Unless you can demonstrate somewhere with a high rate of false positives where it would cause confusion?

  1012. daniel has left

  1013. SamWhited

    Or, alternatively, people who really won't understand this can use a client with a bold button.

  1014. pep.

    re: no data, fair enough.

  1015. pep.

    Then I don't understand why you absolutely want to pass this on the wire

  1016. lovetox

    i dont feel strong as other people about your approach because i simply think it will change nothing

  1017. lovetox

    clients use this formatting already, and will conitnue

  1018. daniel has left

  1019. SamWhited

    pep. because it's less complicated than adding an entirely new wire format, does what clients already do and what (I suspect, with limited data as you pointed out) people are already used to

  1020. SamWhited

    It also follows a convention that's been in use for a long time across multiple types of media

  1021. daniel has left

  1022. lovetox

    i think people will likely accept it more if its a : lets write down the status quo

  1023. daniel has left

  1024. lovetox

    but if you mean, lets extend it later and add all kinds of stuff

  1025. lovetox

    then i think jonas approach is better

  1026. SamWhited

    I specifically want it to *not* be extended later with all kinds of stuff.

  1027. daniel has left

  1028. pep.

    SamWhited, why?

  1029. jere has joined

  1030. SamWhited

    pep. because that's the trap we always fall into: make everything as complicated and as extensible as possible. This leads to incompatibilities between clients, makes things harder to implement, etc.

  1031. andrey.g has joined

  1032. lovetox

    pep. because you get more and more styling elements into the plaintext

  1033. SamWhited

    I want styleing, not layout

  1034. SamWhited

    *styling, even

  1035. pep.

    SamWhited, I am not willing to sacrifice <body> over a "I don't want to complicate things", I don't think that's something we can come back from

  1036. SamWhited

    pep. it's already something people are doing, you're not changing or sacrificing anything.

  1037. SamWhited

    It works today, it's simple, people are used to it. That's "good enough" as far as I'm concerned.

  1038. daniel has left

  1039. Guus has left

  1040. Valerian has left

  1041. Guus has joined

  1042. edhelas

    jonasw interesting approach :)

  1043. pep.

    I definitely prefer it to Styling as well. I find the whole thing futile in the first place, but I understand the security concerns and I think jonasw's proposal covers it

  1044. Arc

    SamWhited: I think jonasw's approach is overcomplicated, however, it has some interesting side effects.

  1045. bjc has left

  1046. nyco has left

  1047. Arc

    im trying to remember it, but there was a XEP published about a year ago (?) that allowed you to updated a previous message

  1048. nyco has joined

  1049. SamWhited

    Arc: we briefly discussed the message replacing one, you'd have to fully replace the message and the new one would have to have its own offsets

  1050. daniel has left

  1051. SamWhited

    Unless this was something different?

  1052. Arc

    what if it only updated the markup, or added to it.

  1053. Arc

    something like this would have to survive numerous tests, such as whiteboarding

  1054. bjc has joined

  1055. Arc

    yours is obviously simpler, and I agree that its a good thing.

  1056. Arc

    frankly i think this whole issue is a bikeshed that's only going to rage on until everyone's exhausted and the issue is dropped again

  1057. daniel has left

  1058. Arc

    im sitting next to our UX guy and he's hard eyerolling at the whole issue

  1059. pep.

    I think that's just a waste of time and we have other more interesting things to tackle

  1060. Arc

    i think tackling xhtml-IM is important. but yes there's so many other issues.

  1061. Arc

    the construction workers still need their bikeshed.

  1062. SamWhited

    Yah, really this whole thing only exists because for some reason people think we can't deprecate XHTML-IM until there's something else vaguely similar

  1063. moparisthebest has joined

  1064. Arc

    i like that inline images are no longer included in either proposal.

  1065. pep.

    SamWhited, I think deprecating XHTML-IM is not the answer in the first place and that's what started this whole holy war.

  1066. Arc

    pep.: there's strong feelings on either side of it. but the core point remains, until someone has solved the core issue with xhtml-im it is *not* worth user security for the rarely used features it offers

  1067. Arc

    xhtml-im has had a decade of real world use, and the security issues are yet to be solved. most don't even try. that's the issue.

  1068. SamWhited

    Indeed :(

  1069. pep.

    Well if they don't even try they're not going to try much more with other implementations. But I've already been told to shut up for whatever reasons

  1070. SamWhited

    pep. that's why we need specs that just don't have the same fundamental flaws, so that people who just don't try (or who do try but make a mistake) are less likely to shoot themselves in the foot

  1071. Arc

    or in this case, shoot all their users in the foot.

  1072. pep.

    Then I guess XHTML-IM is not the only XEP you should tackle, I hope you have time for the rest of every single XEP that tries to display something to the user

  1073. Arc

    we're getting slaughtered on the UX front.

  1074. daniel

    By the way. Conversations now supports code blocks as well. The next stable release will probably be tomorrow or the day after. And then we will get some real world feedback on the styling thing

  1075. pep.

    And more cluttury interface :( I already hate the blockquote thing

  1076. pep.

    When I don't explicitely ask for it

  1077. Arc

    pep.: i agree there are many. and I think there's a large interest in addressing them, xhtml-im is just a low hanging fruit with massive security issues

  1078. pep.

    I think jonasw's proposal answers the security concerns fairly well though

  1079. pep.

    It may still be improved, but that's a step forward

  1080. SamWhited

    pep. yes, both address the concerns with XHTML-IM as far as I can see.

  1081. Arc

    I don't dislike his proposal. I see merits in it. We're not going to resolve it today, there'll be some time to consider and discuss.

  1082. SamWhited

    daniel: nice, that was quick. I still haven't built the branch so maybe I'll just wait now

  1083. jubalh has joined

  1084. pep.

    Arc, as you said earlier, I only see this resolve itself when everybody gets tired of it and one of the sides gives way

  1085. pep.

    (or maybe it wasn't exactly what you meant)

  1086. Arc

    there's a number of young XEPs now that deal with ranges demarking substrings within message bodies

  1087. sonny has joined

  1088. Arc

    pep.: not exactly. you and I? we're not client authors.

  1089. Arc

    daniel is. he and others have the final say, regardless of whatever is published in the XEP. ideally the XEP that gets promoted reflects the consensus that evolves out of this discussion.

  1090. pep.

    I liked goffi's point btw, against the "You can have the plaintext version differ from the rich content if you include both".

  1091. pep.

    Arc, well he gets the final say for his client

  1092. pep.

    And his client only. That will probably influence other clients though, or the war might continue to rage, I don't know

  1093. Arc

    pep.: do you author a client?

  1094. pep.

    In the process of

  1095. Arc

    oh neat, what platform is it for

  1096. Arc

    everything we're working on is web-based, tho i have next to no involvement with the frontend.

  1097. pep.

    We're still a bit far to say that, I guess it'll run on whatever the authors use primarily. The code is in Rust, I'm not sure about the frontends yet, we're sorting the xmpp stuff out first

  1098. Arc

    great to hear about someone using Rust, its a very cool language

  1099. pep.

    It is indeed :)

  1100. SamWhited

    nice; my little toy client is also in Rust, but I've never gotten it far enough along to want to publish it.

  1101. Arc

    its a shame they haven't trimmed it down for embedded use tho, I'm still waiting on that

  1102. pep.

    Arc, there are quite a few use cases for it in embedded already from what I hear, but I have no experience in it

  1103. SamWhited

    Arc: you can actually build without the standard library which is where all the stuff that relies on the OS lives and you end up with a minimal core library which works great on embedded hardware

  1104. Arc

    SamWhited: oh really? do you have a link to that?

  1105. SamWhited

    yah, just a moment

  1106. pep.

    You heard about TockOS? Also as SamWhited says, have a look at https://github.com/japaric/xargo

  1107. Tobias has joined

  1108. SamWhited

    I'm not sure if there's a section in the rust book yet, but the stripped down version of the standard library with no OS stuff is called "core"

  1109. pep.

    There's a guy that's quite keen on doing embedded stuff in the Cambridge Meetup

  1110. SamWhited

    Arc: https://doc.rust-lang.org/book/first-edition/using-rust-without-the-standard-library.html might help

  1111. SamWhited has left

  1112. pep.


  1113. Arc

    Cambridge UK or Boston?

  1114. pep.


  1115. Arc

    SamWhited: that's excellent, i'll run some tests later

  1116. Arc

    oh, and can you bundle assembly with rust?

  1117. Arc

    either in-line or linked in different source files

  1118. Arc

    sorry im lazywebbing

  1119. SamWhited

    You can, search for the "rust nomicon", I think that has a chapter

  1120. Arc


  1121. Arc

    very nice.

  1122. SamWhited

    Obviously all safety guarantees go out the window at that point :)

  1123. SamWhited

    Rust is a cool language, I wish I had more reason to use it day to day

  1124. pep.

    I wish I had more opportunities, reasons I have plenty of :P

  1125. Arc

    SamWhited: things like bitpacking and hashing routines are things i regularly optimize for

  1126. Arc

    well. "regularly" is an overstatement. but still.

  1127. jjrh has left

  1128. jjrh has left

  1129. jjrh has left

  1130. jjrh has left

  1131. jjrh has left

  1132. Tobias has joined

  1133. Valerian has joined

  1134. la|r|ma has joined

  1135. la|r|ma has joined

  1136. la|r|ma has joined

  1137. jjrh has left

  1138. Arc

    SamWhited: move to Portland, lets give you reasons to use it daily :-)

  1139. SamWhited

    Arc: I can't, I watched the TV show and now I can't go to Portland without laughing uncontrollably

  1140. SamWhited

    Also, I'm reasonably sure that it's a fictional place and that no one actually lives in Oregon.

  1141. Arc

    Portlandia is unfortunately closer to the truth than any of us are comfortable with, but it is a real place.

  1142. Tobias has joined

  1143. SamWhited

    If that show is any indication it actually reminds me a lot of Austin

  1144. Arc

    I've heard that as a comparison, but Portland is certainly weirder. For example, Austin doesn't have nude beaches that are a central social spot to just hang out

  1145. lovetox has left

  1146. vanitasvitae

    Is anyone else getting the permanent notification that Flow isnt typing anymore in conversations?

  1147. Arc

    or this (NSFW) https://pdxwnbr.org in which naked people basically take over the city, walk into a random convenience store or cafe and you're likely behind someone in their birthday suit

  1148. SamWhited

    Arc: hah, I've heard of that, sounds… interesting.

  1149. Arc

    CTRL-H held an after-party this year where naked people took over the hacker space

  1150. SamWhited

    In a hacker space full of laiths and laser cutters a naked after party just seems dangerous …

  1151. Arc

    the main room is a big coworking space and lounge. that's where I am now. all we have here is an occulus rift and a few 3d printers, totally fine for parties

  1152. Arc

    ctrl-h is 5 buildings and a shared backyard.

  1153. jjrh has left

  1154. Arc


  1155. daniel has left