jdev - 2022-02-26


  1. syrupthinker has left
  2. SouL has left
  3. oxtyped has left
  4. paul has joined
  5. FireFly has left
  6. thomaslewis has joined
  7. spectrum has left
  8. cdcode has left
  9. 9lakes has left
  10. spectrum has joined
  11. marc has left
  12. spectrum has left
  13. oxtyped has joined
  14. spectrum has joined
  15. 9lakes has joined
  16. oxtyped has left
  17. spectrum has left
  18. spectrum has joined
  19. Alex has left
  20. spectrum has left
  21. spectrum has joined
  22. wurstsalat has left
  23. oxtyped has joined
  24. spectrum has left
  25. moparisthebest has left
  26. moparisthebest has joined
  27. spectrum has joined
  28. spectrum has left
  29. spectrum has joined
  30. spectrum has left
  31. spectrum has joined
  32. spectrum has left
  33. spectrum has joined
  34. debacle has left
  35. spectrum has left
  36. spectrum has joined
  37. xnamed has left
  38. abdullah has left
  39. emus has left
  40. oxtyped has left
  41. oxtyped has joined
  42. oxtyped has left
  43. selurvedu has left
  44. oxtyped has joined
  45. pasdesushi has left
  46. oxtyped has left
  47. atomicwatch has joined
  48. oxtyped has joined
  49. abdullah has joined
  50. oxtyped has left
  51. atomicwatch has left
  52. goffi has joined
  53. jgart has joined
  54. SouL has joined
  55. junaid has left
  56. junaid has joined
  57. emus has joined
  58. marc0s has left
  59. marc0s has joined
  60. mac has joined
  61. oxtyped has joined
  62. Yagizа has joined
  63. oxtyped has left
  64. nephele has joined
  65. nephele has left
  66. jgart has left
  67. nephele has joined
  68. nephele has left
  69. nephele has joined
  70. SouL has left
  71. SouL has joined
  72. stuart.j.mackintosh has left
  73. nephele has left
  74. nephele has joined
  75. stuart.j.mackintosh has joined
  76. mirux has joined
  77. oxtyped has joined
  78. nephele has left
  79. oxtyped has left
  80. selurvedu has joined
  81. Vaulor has left
  82. selurvedu has left
  83. kfv has left
  84. kfv has joined
  85. nephele has joined
  86. oxtyped has joined
  87. nephele has left
  88. marc has joined
  89. sonny has left
  90. sonny has joined
  91. marc has left
  92. marc has joined
  93. oxtyped has left
  94. nephele has joined
  95. Alex has joined
  96. nephele has left
  97. Alex has left
  98. nephele has joined
  99. Alex has joined
  100. nephele has left
  101. Vaulor has joined
  102. jalal has left
  103. nephele has joined
  104. nephele has left
  105. nephele has joined
  106. nephele has left
  107. nephele has joined
  108. nephele has left
  109. nephele has joined
  110. jalal has joined
  111. nephele has left
  112. pasdesushi has joined
  113. oxtyped has joined
  114. Dele Olajide has joined
  115. nephele has joined
  116. debacle has joined
  117. nephele has left
  118. jalal has left
  119. Dele Olajide has left
  120. Dele Olajide has joined
  121. jalal has joined
  122. msavoritias has joined
  123. oxtyped has left
  124. wurstsalat has joined
  125. nephele has joined
  126. oxtyped has joined
  127. marmistrz has joined
  128. nephele has left
  129. oxtyped has left
  130. oxtyped has joined
  131. mac has left
  132. mac has joined
  133. nephele has joined
  134. nephele has left
  135. debacle has left
  136. nephele has joined
  137. debacle has joined
  138. nephele has left
  139. antranigv has joined
  140. nephele has joined
  141. oxtyped has left
  142. nephele has left
  143. nephele has joined
  144. nephele has left
  145. nephele has joined
  146. nephele has left
  147. nephele has joined
  148. nephele has left
  149. nephele has joined
  150. nephele has left
  151. Laura has left
  152. goffi has left
  153. xecks has left
  154. xecks has joined
  155. kikuchiyo has left
  156. oxtyped has joined
  157. kikuchiyo has joined
  158. antranigv has left
  159. FireFly has joined
  160. debacle has left
  161. jalal has left
  162. jalal has joined
  163. pasdesushi has left
  164. me9 has joined
  165. emus has left
  166. emus has joined
  167. Alex has left
  168. Laura has joined
  169. Alex has joined
  170. rafasaurus has left
  171. pasdesushi has joined
  172. goffi has joined
  173. Laura has left
  174. pasdesushi has left
  175. rafasaurus has joined
  176. Yagizа has left
  177. Yagizа has joined
  178. Laura has joined
  179. Millesimus has left
  180. Yagizа has left
  181. emus has left
  182. Millesimus has joined
  183. debacle has joined
  184. emus has joined
  185. jalal has left
  186. xecks has left
  187. xecks has joined
  188. thomaslewis has left
  189. TheCoffeMaker has left
  190. al has joined
  191. pulkomandy hello, I am implementing xhtml-im in my client and currently adding hyperlinks management, is there a recommendation for how to handle phishing attempts like <a href="http://evilwebsite.org">http://totally-legit-looking.org</a> ? For example Thunderbird (on the email side) has a dialog offering to use the href url or the one in the text when this happens, do XMPP client have similar checks?
  192. Millesimus has left
  193. jonas’ mind that XHTML-IM is officially deprecated because of how easy it is to shoot yourself in the foot with stuff like this
  194. Link Mauve In poezio we always display both.
  195. nephele has joined
  196. nephele has left
  197. Link Mauve Web browsers usually display the target URI in the bottom left (or right depending on where the pointer is), I’d assume this design has been put to the test.
  198. Sam That seems like a bad assumption :) (but I also assume people are used to it at this point, at least even if they never actually look at it and click through anyways)
  199. pulkomandy web browsers used to do this, yes. These days they do everything so that the user never sees an URL :
  200. Link Mauve Uh really?
  201. Link Mauve Firefox still does so.
  202. pep. Yeah I confirm
  203. Link Mauve Sam, do you know how else to handle that?
  204. pep. jonas’, and that's still the only solution to do rich text formatting without polluting body, that's actually implemented :)
  205. Sam Link Mauve: Lower left seems like a good idea to me. In addition if the link text and actual link both appear to be URLs it couldn't hurt to show a big warning as someone suggested.
  206. Link Mauve Indeed.
  207. pulkomandy yes, I don't really care if it's deprecated, it's used by various things I need
  208. Sam Well, it could hurt because in commercial systems everything is always behind a tracking link, but making that more painful won't make me lose much sleep.
  209. goffi has left
  210. Sam (and no one is using XMPP commercially in that sense anyways that I know of; eg. there's no newsletters or anything over XMPP)
  211. pulkomandy yes, funnily I mainly know of Thunderbird doing this because outlook changes the content of emails to redirect everything through some "safe links" system
  212. mac has left
  213. Sam What things do you need, maybe we can suggest alternatives that don't have such a bad user experience?
  214. pulkomandy and then thunderbird complains that the link doesn't match the text anymore
  215. Millesimus has joined
  216. jalal has joined
  217. pulkomandy well the 3 things I saw using xhtml-im so far are: biboumi to forward IRC formatting, some matrix bridge using blockquotes for cited messages, and a notification bot using a href to put links to a forum whenever a message is posted there
  218. Link Mauve And poezio!
  219. Sam For the notification bot I'd start with auto-linking URLs in the plain text body first. That will give you a nice experience on both ends of the connection if users are chatting and I suspect the bot also has a plain text body that will work fine with this
  220. pulkomandy as far as I know, none of the replacements for xhtml-im allow using colors in the text. So they are all worse than IRC...
  221. Sam The other two are harder obviously as they'd need change to the bridges, so maybe we can't solve that problem unfortunately
  222. TheCoffeMaker has joined
  223. pulkomandy is there a spec for autolinking urls? Or do I need to figure out my own way to detect URLs?
  224. Sam No, they're better than IRC because people dont' insist on sending you yellow text that looks great against their dark background but can't be read on your light background :)
  225. Sam I'm sure there's a URL detection library out there, but no, there's no documented algorithm for doing so in XEPs at least
  226. Sam But it's a common enough thing that's easy enough to do
  227. nephele has joined
  228. Link Mauve [citation required]
  229. pulkomandy still can't be as easy as parsing <a href=""></a>
  230. Sam Maybe, maybe not. It's pretty easy either way.
  231. Sam Anyways, just saying that might go ahead and solve that problem for you and be a useful thing to the users of your client.
  232. Sam I think most people just use a regexp copied from the internet. This will never be 100% correct with no false positives or negatives, but it generally does well enough 99% of the time.
  233. Link Mauve In my experience, it’s very annoying when it doesn’t.
  234. Link Mauve Counting parentheses is one such infuriating example regexp can’t do.
  235. pep. While we could just tell the receiving client it's meant to be a url so that it gets it 100% of the time. But no
  236. pep. Better to get it 99% of the time
  237. qy Perl grammars could though...
  238. Link Mauve :)
  239. Link Mauve Reminds me of that time I tried to implement <a/> using poezio’s paste.
  240. Sam Sure, it's a bit annoying. If you have a nice UI for creating links that you can use definitely add an OOB or something too, but either way for people who just type in mysite.example.com you probably want to autolink that, so you'd likely want to do it either way even if you support XHTML-IM or whatever
  241. Link Mauve But then I hate the timer paste it does, so I fell into the rabbit hole that ncurses doesn’t support the proper bracketed paste…
  242. Link Mauve Sam, wut, no, you definitely don’t.
  243. Link Mauve Some websites try to do so, with hilariously bad results.
  244. nephele has left
  245. nephele has joined
  246. Sam If I quickly type, "hey, this video was funny <pastes link>" you don't try to autolink that? Seems like a bad experience. I dunno, Conversations does it and it works pretty well. Not saying it's 100%, sure it's annoying sometimes, but mostly it's a much nicer experience when I can just click on it.
  247. Link Mauve For instance in French we have many words ending in -s if masculine, -es if feminine, and using a dot to mean either undeterministically, these systems always think these are links to Spanish websites. ^^'
  248. Sam Although this is probably more important on Android where you don't have a cursor and can't just copy/paste the text into the address bar
  249. nephele has left
  250. Link Mauve Sam, actually in poezio we don’t control what the terminal will autolink (although I’ve seen a proposal for proper HTML-style links recently, but it is not implemented in tmux…).
  251. Sam Sure, not every possible system can do it.
  252. Sam I'm just saying, if you've got a bot sending you links that might be a good first step.
  253. jalal has left
  254. pep. As a client I'd prefer to tell my terminal what is a link though, because I've got more context than the terminal
  255. Link Mauve Sam, if you quickly type "hey, this video was funny <pastes link>" and your client creates a proper <a/> link on paste, there is no issue and no need for other clients to guess what is or isn’t a URI.
  256. Link Mauve pep., yup.
  257. Sam That's the same thing, your client just had to guess.
  258. Sam Instead of the other side.
  259. Link Mauve pep., https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
  260. pep. Sam, it wouldn't, if the sender told it.
  261. nephele has joined
  262. Sam Sure, but the sender didn't tell it, they just typed in some text.
  263. Link Mauve Sam, as a sender you can fix it until it is correct.
  264. Link Mauve While as a recipient, if the markup is lost then you are condemned to guess.
  265. Sam I'm not saying not to do that; I agree, linkify it on both ends it will make for a way better experience.
  266. Link Mauve Sam, realistically, people very rarely type in URIs in text.
  267. pulkomandy I don't know about your OS, but in mine, the clipboard data has a mimetype so if I copypaste a link into my XMPP client, I can know it's a link, and probably get both the URL and the page title from the clipboard
  268. Link Mauve Copy/paste is a much more common feature for that.
  269. Sam But you probably also have to do it on the receiving end for when they have an old client that doesn't understand your XHTML-IM or OOB/references format or whatever you use anyways if you want a fallback.
  270. pulkomandy yes, I will handle legacy clients and OS as best as I can, but that's not a reason to stay locked in the 1990s
  271. pulkomandy otherwise I would be writing an IRC client not an XMPP one
  272. nephele has left
  273. nephele has joined
  274. Sam I didn't say you should, I said it might be a quick way to get that for a simple bot and might be good enough for now since we don't have a good link format.
  275. Link Mauve We actually do, it’s just that you deprecated it.
  276. Link Mauve But it’s still perfectly usable.
  277. jalal has joined
  278. pulkomandy yes I'll implement what we have now. I'm happy to replace it with something better if someones comes up with something better, which I don't think the new specs for rich text are
  279. nephele has left
  280. nephele has joined
  281. nephele has left
  282. nephele has joined
  283. pasdesushi has joined
  284. nephele I made a specification for formatted messages in matrix, if there is interest I will work on making a similar one for xmpp, if the concept is considered fine :)
  285. nephele https://github.com/tulir/matrix-doc/blob/formatting-entities/proposals/2427-json-based-message-formatting.md
  286. Link Mauve nephele, XEP-0071 is that but for XMPP.
  287. nephele has left
  288. nephele has joined
  289. moparisthebest > Matrix formatting is currently based on a subset of HTML. Sounds like most clients are probably vulnerable to what most xhtml-im clients are vulnerable to
  290. nephele Link mauve: no, that is differnt
  291. Zash nope, because json protects it!
  292. antranigv has joined
  293. nephele moparisthebest: yes... which is why i made this alternative formt :)
  294. Zash so something between xhtml-im and https://xmpp.org/extensions/xep-0394.html
  295. nephele has left
  296. nephele has joined
  297. SyrupThinker has joined
  298. nephele Eh, not that similar either
  299. Zash actually, closer to xhtml-im
  300. Zash modelled in json
  301. nephele has left
  302. nephele has joined
  303. nephele It's not html :) that was the main point anyhow
  304. pep. xhtml-im isn't "html" either
  305. pep. It's a strict subset of xhtml
  306. nephele Yes, but you cannot use an html paraer for this one
  307. Zash It can be translated to HTML, therefore vulnerable.
  308. MattJ Well, anything can be vulnerable
  309. pulkomandy unicode seems more dangerous than html :>
  310. Sam I would assume this would be less likely to be vulnerable?
  311. pasdesushi has left
  312. Zash The vulnerability is the web itself, not the format!
  313. moparisthebest In practice all clients just drop it into a browser that supports JavaScript etc
  314. MattJ I think a custom format that can't be passed to a renderer (i.e. not HTML, XHTML or Markdown) is less likely to cause implementation vulnerabilities
  315. moparisthebest I get that it "can be implemented securely"
  316. pulkomandy that's clearly not the case for the code I'm writing
  317. pep. moparisthebest, web* clients
  318. pulkomandy so "all clients" can't be true :)
  319. moparisthebest No, all
  320. pep. Also not poezio
  321. Sam but yah, adding the massive web footprint and platform is the real problem
  322. moparisthebest If you have a spec that all clients implement in an insecure way, it's a bad spec even if it can be secure in theory
  323. pulkomandy you don't need a web engine for this. I used libcss to parse the css and give me easy to use styling attributes. No HTML parser or DOM or anything crazy like that involved
  324. Zash good luck finding a decent rendering engine that doesn't come with a javascript engine bolted on
  325. pulkomandy you don't need a full rendering engine for this, that's why it's a subset of xhtml and not the full thing
  326. MattJ Ideal would be a new "safe" format, with reference implementations in multiple languages for translation to HTML and other common markup formats
  327. Zash there aren't a lot of rendering engine implementations afaik
  328. Link Mauve Yup, poezio’s rendering engine is decent and is written in about 500 lines of Python.
  329. Zash terminal is easier but turning text into pixels is hard
  330. Link Mauve For most toolkits this is a solved problem though.
  331. nephele has left
  332. nephele has joined
  333. Zash ... because they include HTML+CSS+JS based rendering engines
  334. Link Mauve Although with resolutions being bigger and bigger, the traditional way is starting to be a bit limited, so newer ways to turn text into pixels (using GPUs this time) are being explored.
  335. Link Mauve Zash, I’m most familiar with GTK, which only includes CSS out of these three, and pango implements a subset of HTML for its markup.
  336. Link Mauve There is no web engine nor JS available in there, without external libraries like webkit2gtk.
  337. Link Mauve Pidgin went for the latter, and this has been a massive drag since then.
  338. Zash Wasn't half of Gnome written in JS these days?
  339. pulkomandy here is my 800 lines of code to implement xhtml-im with just libcss and no javascript or html or dom involved: https://github.com/pulkomandy/Renga/blob/master/ui/Xhtml.cpp most of it is callbacks to tell libcss "no we don't need that here"
  340. pasdesushi has joined
  341. Link Mauve Zash, gnome-shell is written in JS, but that’s the host language, not a language you are forced to embed just because.
  342. nephele Anyhow, if there is interest let me know and I'd work on a new format for xmmp
  343. Zash And back when Swift was more actively developed it was said that there weren't any rendering engines available besides webkit
  344. moparisthebest How many vulns is in libcss?
  345. pep. nephele, I honestly recommend fastening up your seatbelt really tight if you go that way in the XMPP world. Haters are gonna hate
  346. Zash We have how many formats already?
  347. homebeach has left
  348. Matrix Traveler (bot) has left
  349. Matrix Traveler (bot) has joined
  350. homebeach has joined
  351. pep. 2 in use
  352. Zash we have enough war without another format war
  353. pep. Well they're not even the same thing, that's the worst. One is a wire format missing an input format, the other is an input format missing a wire format
  354. pep. Together they could go very far but for some reason one doesn't like the other. I'll let you guess which
  355. Link Mauve pep., probably just nobody did it so far.
  356. pep. Link Mauve, well the latter mandates input format == wire format, so it's not really possible. That's the trick :p
  357. Link Mauve Although I’d rather go for something a bit more widespread, such as Markdown, for such an input format.
  358. Link Mauve pep., not really no, does it?
  359. nephele has left
  360. nephele has joined
  361. pep. Isn't that the whole point
  362. pep. of 393
  363. SyrupThinker has left
  364. Link Mauve pep., it has some examples of it being used in {jabber:client}body, but that’s just examples, not standard text.
  365. Link Mauve You can perfectly well use that as your input format, and transform it before sending it to the recipients.
  366. nephele has left
  367. nephele has joined
  368. pep. Link Mauve, I know, see https://lab.louiz.org/poezio/poezio/-/issues/3455#note_7769
  369. homebeach has left
  370. Matrix Traveler (bot) has left
  371. Matrix Traveler (bot) has joined
  372. homebeach has joined
  373. Link Mauve Right.
  374. J Marinaro has left
  375. pulkomandy I'd rather go with https://xmpp.org/extensions/xep-0394.html than 393 if we really have to remove xhtml-im (but again, no support for colors there, yet?)
  376. pep. Reading 393, I just discovered: « Clients that do not support this specification MUST still be able to receive messages sent by clients using this specification and display them in a human-readable form. »
  377. pep. Is that really a thing? a MUST for non-supporting implementations?
  378. Link Mauve pep., it’s mu. :D
  379. Link Mauve A specification can’t force non-implementers to do anything.
  380. Sam Good catch; that's just a requirement, that "MUST" should be "must".
  381. nephele has left
  382. nephele has joined
  383. Sam Oh, no, nevermind
  384. Sam But still, it's not a requirement on the clients to do anything, it's a requirement on the spec to do something
  385. pep. Ok
  386. moparisthebest Markdown also requires a browser which in practice always comes with JavaScript
  387. nephele has left
  388. Sam It doesn't require a browser, but in a browser all the markdown libraries I looked at appeared to be vulnerable by default to injecting scripts or something executable which is part of the reason I didn't just go with that when writing 0393.
  389. pulkomandy yes I'm a lot more worried about me trying to write a parser for 0393 than about using libcss for 0071
  390. moparisthebest I wouldn't be
  391. nephele has joined
  392. Link Mauve moparisthebest, Markdown is a superset of HTML, it doesn’t “require a browser” nor JavaScript.
  393. moparisthebest Link Mauve: in practice it'll always be implemented that way
  394. Link Mauve moparisthebest, not really no.
  395. Sam I would be interested to see a spec that used XML for formatting similar to XHTML-IM but w/o the HTML part and w/o the "tries to link into the plain text body too" part of 0394. I dunno if it would be better or worse, and you end up with the "plaintext/formatted message bodies are entirely different problem", but I'd like to see it and would be curious what could be done with it.
  396. moparisthebest Again, I don't care what's theoretically possible, only what happens 99.9% of the time
  397. cdcode has joined
  398. Sam moparisthebest: I don't think that's true, none of the markdown parsers I've ever used required HTML (unless they were javascript ones). I mean, you're right about the problem, just wrong about that detail I think
  399. pulkomandy well, xhtml-im but we do a rot13 on all the xhtml element names to make sure they are not accidentally sent to an html parser?
  400. moparisthebest See also: _xmppconnect and XMPP XML being a "strict subset of XML" where all projects just use an XML parser and are vulnerable
  401. Link Mauve Sam, that would be exactly the same as XHTML-IM imo, clueless webdevs will just make it go through some XSLT or whatever and end up with the exact same vulnerabilities, while you have fragmented the ecosystem with one more wire format.
  402. Sam I'm not 100% sure that's true, but you might be right
  403. pulkomandy clueless webdevs don't know about XSLT, they would implement something similar, but slower in javascript
  404. Link Mauve Right.
  405. Link Mauve Sam, clueless webdevs have vulnerabilities in anything where plain text is used in the protocol, built-in the browser under the name innerHTML.
  406. Link Mauve Once the JS converter to HTML has been passed, they’ll put it in the DOM with innerHTML and get the same vulnerability they’ve used for years.
  407. Sam Yah, actually, you're probably right. The naive case would carry over the attributes and one of those will be javascript:onmouseover or whatever.
  408. Link Mauve Exactly.
  409. moparisthebest You could say the same about clueless C++ devs who think "I'm sure I can write secure c++ *this* time"
  410. pep. Maybe someday we'll stop betting that clueless webdevs be clueless and limit our specs and we'll start helping/training them instead and write our specs with less worries
  411. atomicwatch has joined
  412. Link Mauve Ha, I’m not gonna train a webdev.
  413. pep. :D
  414. Link Mauve I’m bad at webdev myself.
  415. Link Mauve Stuck about ten years ago.
  416. moparisthebest You need to write specs that can be implemented securely by anyone that can read them without knowing a ton of non obvious stuff
  417. pep. The point is, if you think people are dumb you're not gonna go very far
  418. Link Mauve pep., their very platform is offering them footguns.
  419. pep. Then let's change the platform
  420. Link Mauve moparisthebest, good luck with that.
  421. moparisthebest Link Mauve: *different footguns
  422. Link Mauve That would be a platform where exactly no wire text is present in the final UI.
  423. emus has left
  424. Link Mauve For a chat system for instance, you wouldn’t go very far.
  425. Sam It's not that we're just assuming web devs aren't intelligent, it's that literally every web client I ever tried that supported XHTML-IM (and I don't think "every" is me being hyperbolic) had trivial vulnerabilities. Sure, I reached out and helped fix a lot of them, but the point is that experience shows us that we handed them a gun pointed at their foot and then just told them "but be careful and don't pull the trigger"
  426. moparisthebest Have you ever used openssl?
  427. pulkomandy sadly, yes :(
  428. pep. Sam, you're mistaken on the footgun though
  429. pep. There is one in that story for sure
  430. moparisthebest All computer stuff is a dumpster fire, pointing out that different trash is burning on the webdev side vs native code doesn't feel helpful
  431. Link Mauve Sam, our specification might not have carried enough big blinking red warnings, but I’ve found similar vulnerabilities in multiple clients’ handling of MUC nicks, the thing in the resource. :D
  432. pulkomandy also we have specifically said "clueless webdevs" which is a subset of webdevelopers. There are skilled ones too, and there are clueless C++ developers too
  433. Link Mauve It’s explicitly specified as an opaque string.
  434. pep. pulkomandy, agreed
  435. marc has left
  436. Sam Sure, there are also other vulnerabilities and common problems; that doesn't mean we shouldn't fix the ones that can be fixed.
  437. Link Mauve Removing the ability to send formatted text was never a fix, even less a good one.
  438. marc has joined
  439. Sam No one removed the ability, we obsoleted the spec which means "the XSF doesn't recommend this particular spec".
  440. Link Mauve But we’ve had pages of emails on that topic, let’s not go over them again. :)
  441. Link Mauve Sam, right.
  442. pep. Yeah, pages of feedback on that topic which got ignored
  443. nephele has left
  444. pulkomandy well it seems the result is client devs like me thinking "the XSF is stupid, they don't provide any alternative so I'm going to implement this anyway"
  445. Link Mauve pep., not really, I mean people continue to implement it despite it being obsolete.
  446. Sam It was all discussed multiple times. Just because your way didn't get picked doesn't mean you were ignored.
  447. debacle has left
  448. Link Mauve pulkomandy, that’s approximately my stance on that too.
  449. emus has joined
  450. Sam The XSF isn't some magical body telling you what to do; the council just said "we don't recommend this one because experience has shown us it's difficult to do right". The XSF is *you*, other alternatives could be proposed (like 0393 and 0394). If one of them got implemented and the other didn't, it's the community that voted with their code, not the XSF. And you could always propose another that includes whatever formatting you think is missing
  451. Link Mauve Sam, no need for that, 0071 works.
  452. Link Mauve At best what I’d propose would be some bright blinking red warnings about our implementation experience.
  453. pulkomandy yes, what do we do, resubmit 0071 with a new xep number and rename it "totally-not-xhtml-im" ?
  454. Sam Well, that's fine, but the council at the time disagreed.
  455. al has left
  456. Sam In theory the council is experienced people who know a bit about XMPP. That's not to say that every decision will be perfect, and not to say that you can't ignore their warning and go implement it, just that it might be worth considering why they did it and that it wasn't because they ignored you.
  457. qy I like 0394 more but 0393 seems more usable, probably best implement them both
  458. pulkomandy well, there is this spec being used in the wild by at least 4 different xmpp things, there is no replacement (393 and 394 don't implement the two features I need: marking up links so I don't have to guess, and converting IRC styling so that IRC users can smoothly migrate to my client and not lose any features) and I'm not going to spend time writing more specs because I have enough work to do writing code supporting existing stuff. Do whateveryou want with that information :)
  459. Sam (FWIW, I think we need a linking spec in particular and would love to see that exist, I've thought about working on one a few times)
  460. qy i feel like oob is fine for linking, just that it has been implemented in such a wacky way
  461. jalal has left
  462. Sam Maybe I should finish my LaTeX-IM spec. It was meant to be published on April 1st last year, but I never got around to finishing/submitting it.
  463. Link Mauve :D
  464. Link Mauve Reminds me of a Gajim plugin I once wrote, which would render Lilypond markup inline. <3
  465. Link Mauve (0393-style)
  466. pep. Do I need to download a texlive distribution for the LaTeX-IM spec? :P
  467. Sam oooh, I would legit use that, not even as a joke. I used to write a lot of music and I *love* lilypond (even if every release breaks my old stuff and it's really confusing markup for anything more advanced than a simple staff)
  468. Link Mauve (Where a client which didn’t support this markup would still show you the { \treble \time 4/4 c8 d e f g2 }, while a client with support would render a lovely score.
  469. Link Mauve The main issue with that is that Scheme support means you basically own the remote computer.
  470. Sam I left the note on codeblocks undefined in 0393, but I keep hoping clients that implement it will do things like that, eg. gajim might let plugins hook into ```note and if it sees ```lilypond it could try to render it, etc.
  471. Sam But yah, that opens a whole other can of worms.
  472. Link Mauve Preformatted text (<pre><code/></pre> in HTML) is by no means made to actually render or run the thing.
  473. Link Mauve Although you could add a Run button in your client, so that for instance a Python snippet can be executed inline.
  474. Link Mauve Hopefully, only with proper sandboxing in place.
  475. pulkomandy a good way to check if there are also clueless python devs :')
  476. Link Mauve Are you willing to bet on most clients doing security properly? :)
  477. xnamed has joined
  478. nephele has joined
  479. nephele has left
  480. nephele has joined
  481. qy > so that for instance a Python snippet can be executed inline.
  482. qy 😱️
  483. marc has left
  484. marc has joined
  485. goffi has joined
  486. marc has left
  487. xnamed has left
  488. nephele has left
  489. marc has joined
  490. al has joined
  491. nephele has joined
  492. moparisthebest > Hopefully, only with proper sandboxing in place. You just described all of the web
  493. 9lakes has left
  494. nephele has left
  495. lovetox has left
  496. me9 has left
  497. nephele has joined
  498. Link Mauve The web is actually a very good sandbox. :)
  499. jalal has joined
  500. pulkomandy but that can't protect a website against itself :)
  501. al has left
  502. nephele has left
  503. Link Mauve Actually there are quite a few mechanisms for that, iframe for one, combined with HTTP headers.
  504. moparisthebest CSP?
  505. Link Mauve Yeah.
  506. Link Mauve And a few other ones.
  507. moparisthebest It's just piles upon piles of hacks to try to make it secure
  508. moparisthebest Well, all of computing is
  509. homebeach has left
  510. Matrix Traveler (bot) has left
  511. Matrix Traveler (bot) has joined
  512. homebeach has joined
  513. 9lakes has joined
  514. qy some parts more than others though
  515. cdcode has left
  516. lovetox has joined
  517. nephele has joined
  518. jalal has left
  519. jalal has joined
  520. nephele has left
  521. nephele has joined
  522. 9lakes has left
  523. Dele Olajide has left
  524. Dele Olajide has joined
  525. nephele has left
  526. nephele has joined
  527. nephele has left
  528. Dele Olajide has left
  529. Dele Olajide has joined
  530. Dele Olajide has left
  531. marc0s has left
  532. marc0s has joined
  533. marc has left
  534. atomicwatch has left
  535. larma has joined
  536. nephele has joined
  537. mh has left
  538. mh has joined
  539. xnamed has joined
  540. goffi has left
  541. goffi has joined
  542. atomicwatch has joined
  543. nephele has left
  544. Dele Olajide has joined
  545. nephele has joined
  546. marc has joined
  547. goffi has left
  548. Dele Olajide has left
  549. nephele has left
  550. Dele Olajide has joined
  551. Dele Olajide has left
  552. nephele has joined
  553. 9lakes has joined
  554. atomicwatch has left
  555. marmistrz has left
  556. goffi has joined
  557. debacle has joined
  558. atomicwatch has joined
  559. Ingolf has left
  560. nephele has left
  561. debacle has left
  562. debacle has joined
  563. kfv has left
  564. selurvedu has joined
  565. kfv has joined
  566. mac has joined
  567. Ingolf has joined
  568. thomaslewis has joined
  569. thomaslewis has left
  570. thomaslewis has joined
  571. oxtyped has left
  572. thomaslewis has left
  573. Laura has left
  574. thomaslewis has joined
  575. kfv has left
  576. kfv has joined
  577. nephele has joined
  578. Laura has joined
  579. nephele has left
  580. nephele has joined
  581. larma has left
  582. thomaslewis has left
  583. kfv has left
  584. kfv has joined
  585. Laura has left
  586. nephele has left
  587. kfv has left
  588. kfv has joined
  589. Laura has joined
  590. selurvedu has left
  591. mac has left
  592. mac has joined
  593. xnamed has left
  594. homebeach has left
  595. Matrix Traveler (bot) has left
  596. Matrix Traveler (bot) has joined
  597. homebeach has joined
  598. xnamed has joined
  599. me9 has joined
  600. marc has left
  601. marc has joined
  602. marc has left
  603. marc has joined
  604. larma has joined
  605. nephele has joined
  606. nephele has left
  607. nephele has joined
  608. cdcode has joined
  609. nephele has left
  610. mac has left
  611. mac has joined
  612. selurvedu has joined
  613. PapaTutuWawa has joined
  614. marc has left
  615. marc has joined
  616. larma has left
  617. thomaslewis has joined
  618. mac has left
  619. thomaslewis has left
  620. mac has joined
  621. thomaslewis has joined
  622. thomaslewis has left
  623. nephele has joined
  624. nephele has left
  625. xnamed has left
  626. xnamed has joined
  627. nephele has joined
  628. Millesimus has left
  629. Millesimus has joined
  630. nephele has left
  631. nephele has joined
  632. thomaslewis has joined
  633. thomaslewis has left
  634. mirux has left
  635. me9 has left
  636. nephele has left
  637. nephele has joined
  638. kfv has left
  639. kfv has joined
  640. nephele has left
  641. cdcode has left
  642. larma has joined
  643. larma has left
  644. abdullah has left
  645. larma has joined
  646. abdullah has joined
  647. cdcode has joined
  648. thomaslewis has joined
  649. thomaslewis has left
  650. J Marinaro has joined
  651. marc has left
  652. marc has joined
  653. larma has left
  654. J Marinaro has left
  655. marc has left
  656. marc has joined
  657. mac has left
  658. J Marinaro has joined
  659. marc has left
  660. marc has joined
  661. antranigv has left
  662. nephele has joined
  663. nephele has left
  664. nephele has joined
  665. nephele has left
  666. nephele has joined
  667. nephele has left
  668. nephele has joined
  669. nephele has left
  670. thomaslewis has joined
  671. thomaslewis has left
  672. jgart has joined
  673. thomaslewis has joined
  674. thomaslewis has left
  675. msavoritias has left
  676. emus has left
  677. kfv has left
  678. kfv has joined
  679. J Marinaro has left
  680. msavoritias has joined
  681. nephele has joined
  682. J Marinaro has joined
  683. nephele has left
  684. SouL has left
  685. marc0s has left
  686. marc0s has joined
  687. thomaslewis has joined
  688. atomicwatch has left
  689. spectrum has left
  690. marc0s has left
  691. marc0s has joined
  692. cdcode has left
  693. msavoritias has left
  694. paul has left
  695. Millesimus has left
  696. marc has left
  697. Ingolf has left
  698. Ingolf has joined