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 https://pastebin.ca/3905635
  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 Thanks
  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 oops
  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 (maybe)
  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 cancelled
  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 *nods*
  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 right
  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 Night.
  744. SamWhited o/
  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 anyways
  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. k
  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 Indeed
  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 http://spec.commonmark.org/dingus/?text=no%20format%0A%0A%3E%20%60%60%60%0A%3E%20Preformatted%20text%20to%20the%20end%20of%0A%3E%20the%20block%20quote%0A%60%60%60ignored%20(not%20sure%20about%20adding%20this%20to%20the%20XEP%20or%20not)%0A%3E%20preformatted%20to%20the%20end%20of%20the%20body%20(not%20a%20block%20quote)
  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 yes
  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 drat
  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. https://github.com/thejpster/stellaris-launchpad
  1113. Arc Cambridge UK or Boston?
  1114. pep. UK
  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 https://doc.rust-lang.org/1.12.0/book/inline-assembly.html
  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 http://www.sheut.net/CTRLH-2017-11-07.jpg
  1155. daniel has left