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


  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


  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


  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.


  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


  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


  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.


  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


  464. Link Mauve

    Reminds me of a Gajim plugin I once wrote, which would render Lilypond markup inline. <3

  465. Link Mauve


  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


  505. Link Mauve


  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