XSF Discussion - 2017-10-19

  1. Flow

    jonasw, no worries

  2. Flow

    I hope that Link Mauve eventually reconsiders his vote, because maybe he was also on the wrong track about what BMH is about…

  3. pep.

    Flow: I don't think so

  4. jonasw

    Flow, to be honest, I think you picked a really bad time for this

  5. jonasw

    the worst imaginable

  6. jonasw

    I now understand your use-case, but in light of the XHTML-IM obsoletion discussion ...

  7. Zash

    I had that thought as well

  8. pep.

    And I said that on the ML already

  9. pep.

    Plus, I don't see what your XEP brings that's not already possible for you to do in your gateway, instead of pushing that effort on every. single. client.

  10. pep.

    If the XSF wants to avoid flawed implementations BTW (seeing the xhtml-im thread), I suggest we start here

  11. Flow

    jonasw, Zash: Yep you are right. I blame our Ignite Realtime community for switching to Discourse and triggering the whole BMH idea. And by the time I realized that it could be seen as suggestion for a potential XHTML-IM replacement, the XEP was already announced without a good introduction providing a motivation. I would be happy to change that, but as long as there is a -1 vote from Link Mauve I'm not sure if I should put any more effort into it.

  12. jonasw

    blaming the people who switch to Discourse is in any case the right thing to do

  13. Flow

    (of course I'm the only one to blame here, can't tell you how excited I'm that Ignite Realtime finally switched to discoures)

  14. jonasw

    (I’m not sarcastic here :))

  15. Zash

    Like I said earlier, I blame the web.

  16. jonasw

    blaming the web wfm too :)

  17. Flow

    yeah, everyting was better when we still had gopher

  18. Zash

    Flow: A very clear problem statement in the introduction probably helps.

  19. jonasw

    gopher was amazing

  20. Zash

    I never used it, but everything *was* better

  21. zinid

    what's wrong with discourse?

  22. jonasw

    I wrote a gopher server once, in freepascal.

  23. jonasw

    then firefox dropped gopher support :(

  24. Zash

    I looked into the specs and almost started implementing it in Prosody :)

  25. Ge0rG

    can't we just go back to NNTP?

  26. jonasw

    NNTP over NTP

  27. Zash

    From what I gather, NNTP was perfection.

  28. zinid

    NNTP was quite good indeed

  29. Ge0rG

    Zash: except for the spam.

  30. jonasw

    it’s always the spam

  31. Zash

    Not quite clear on the distinction between NNTP, Newsgroups and usenet.

  32. Ge0rG

    Oh wait. XMPP is the NNTP of the 2000s.

  33. Ge0rG

    Zash: similar to the distinction between XMPP and Jabber.

  34. jonasw

    XMPP, Jabber, conversations.im?

  35. Zash

    It was pure perfection anyways. Therefor it must die.

  36. Zash

    The Web will win and consume the world, because it is terrible.

  37. Zash

    Can't have nice things.

  38. Zash

    Worse is better.

  39. Ge0rG

    So I've spent two hours tracking the special place where Android devices store their factory-reset-protection data, just to realize that I have no actual device supporting it.

  40. nyco


  41. nyco

    Real-Time Communications dev-room: deadline 23:59 UTC on 30th of November.

  42. tux

    Ge0rG: you mean there are Android devices with a special storage area for malware?

  43. Ge0rG

    tux: no, it's more of a trojan horse when you sell your android device.

  44. tux


  45. Ge0rG

    tux: after a factory reset, the device can only be unlocked with the gmail account that was used on it before resetting.

  46. tux

    Effectively opening a market for Gmail account data.

  47. Link Mauve

    “19:13:59 Flow> What do clients use these days to embed image-urls into a message (e.g. for stickers)?”, Movim uses XHTML-IM, alongside BoB.

  48. Flow

    Link Mauve, k, thanks. I wonder if at least OOB should be mentioned in https://xmpp.org/extensions/xep-0387.html#im

  49. Link Mauve

    I doubt so, it’s one of these XEPs that should be deprecated imo, it brings pretty much no information.

  50. SamWhited

    I think one of those two things (SIMS or OOB) could be included (in the next version which I will start on as soon as this one is advanced). It makes the experience significantly nicer.

  51. Flow

    what was SIMS again?

  52. SamWhited

    Flow: Slightly more advanced OOB, I think. I need to read both again and compare.

  53. Link Mauve

    Flow, about Discourse, I really fail to see the issue with doing exactly the same thing as every other gateway before yours, that is to convert whatever input markup you get from the legacy service into both plain text and XHTML-IM.

  54. SamWhited

    Eg. allows for multiple media types.

  55. Link Mauve

    Flow, 0385.

  56. jonasw

    Flow: Stateless Inline Media Sharing

  57. Flow

    Link Mauve, how do you image a plain text version of CommonMark look like?

  58. Link Mauve

    Basically, a description of the file, with metadata, and multiple possible sources to retrieve it.

  59. Link Mauve

    Flow, for example “this is **bold**” into “this is bold”.

  60. Link Mauve

    That way the receiver won’t have to understand CommonMark to understand a sentence.

  61. Flow

    so I need to converters and loose stylistic/semantic information if the recipient can only look at the body?

  62. Flow

    Do we also convert lists?

  63. Link Mauve

    Right, that’s the definition of plain text.

  64. Flow

    And headings?

  65. Link Mauve

    Indeed, you should convert the usual Markdown list (this one: 1. first item 1. second item 1. third item ) into something that can be better understood by the user.

  66. Flow

    And why would I convert at all? CommonMark is nicely readable as plain text

  67. Link Mauve

    Here, renumbering them into 1. 2. 3.

  68. moparisthebest

    why isn't commonmark in the body with some clients displaying it raw and some translating it on the recieving end like every email/chat client ever fine?

  69. Link Mauve

    Flow, it’s not always, I just gave you two examples.

  70. SamWhited

    Messing with the message the user sent seems like a bad idea, especially when it's already perfectly readable plain tex.t

  71. moparisthebest

    gajim, all IRC clients, most email clients, they all do that

  72. Flow

    Link Mauve, that's a corner case, and I believe you will get normalized CommonMark out of Discourse

  73. moparisthebest

    also the *huge* problem with not putting things in body, or different representations, is from a security perspective, how do you ensure they are the same? jonasw I think you were the most concerned with using body

  74. Link Mauve

    moparisthebest, email clients overwhelmingly display the text/html version of a multipart attachment first, some of them display the text/plain version and add colour for common idioms, such as the “-- ” signature or the ”>” quotes but that’s due to legacy.

  75. moparisthebest

    due to legacy sure, but it works great and everyone understands it

  76. Flow hopes that the text/plain MIME part never becomes legacy

  77. Link Mauve

    If I want to display you a broken ordered list, what I just posted you, will you also transform that into a normalised one creating incomprehension between us, just because you happen to throw every incoming message into your CommonMark parser?

  78. moparisthebest

    what flow just did, /me, is that a XEP someplace or is that convention?

  79. Link Mauve

    Flow, same. ^^

  80. SamWhited

    More importantly, people who have never seen it before intuatively understand it. If you read "Wow, that's *amazing*!" you just get it… it makes sense that it's a for of emphasis.

  81. SamWhited

    *form of

  82. jonasw

    moparisthebest: consistency of user experience, fracturing of the ecosystem and complexity of supporting possibly numerous markups

  83. SamWhited

    moparisthebest: https://xmpp.org/extensions/xep-0245.html

  84. moparisthebest

    yea, and gajim bolded that for me as well, equally I would have understood if it didn't

  85. jonasw

    I'm on the phone now

  86. jonasw

    so hard to go into details

  87. Zash

    Flow: You didn't see the thing where some Mozilla person wanted to remove plain text because it didn't have tracking images?

  88. moparisthebest

    ah nifty SamWhited , also just in body, and if the client didn't support it it'd still be mostly readable

  89. Flow

    Zash, I read about it :)

  90. Flow


  91. moparisthebest

    imho that's what you want for instant message markup, simple things that don't matter if they are actually interpreted or not *bold* /italic/ etc

  92. moparisthebest

    publishing blog posts is a different use-case with different needs

  93. Zash

    Formatting vs semantics again

  94. Link Mauve

    moparisthebest, that’s a Gajim bug, not something we should encourage.

  95. Link Mauve

    (Bolding something.)

  96. moparisthebest

    don't many other clients do the same?

  97. moparisthebest

    seems like it should be a feature we should encourage to me

  98. Link Mauve

    moparisthebest, I’ve never seen any other client, and it sounds misguided at best.

  99. moparisthebest

    it's at minimum in basically every irc client and most email clients

  100. moparisthebest

    surely it's in other xmpp clients

  101. pep.

    I agree with Link Mauve, that's not something that should be encouraged. Or at best gajim could translate that to xhtml-im

  102. moparisthebest

    my point is it's readable whether the client special-cases it or not

  103. moparisthebest

    no fragmenting or confusion

  104. SamWhited

    I disagree, it's simple, effective, and a very nice experience. We should absolutely encourage it.

  105. pep.

    moparisthebest, it's not because you understand it that everybody does. My parents don't, they might understand *foo*, but maybe not _bar_ nor /baz/

  106. pep.

    Also if a client translates that, how do I write IPA now? :(

  107. SamWhited

    (or we should absolutely encourage something similar, I'm not advocating for exactly what Gajim does, whatever that may be)

  108. Link Mauve

    (I just reported that bug to Gajim, fyi.)

  109. SamWhited

    I don't even think that needs to be standardized though; it could be completely separate from whatever new formatting thing comes out. It's just nice to have either way and can be client specific without harming anything.

  110. pep.

    By using common characters as meta characters you are removing many things that were possible and won't be anymore. Have your client allow you to write rich text, sure, don't clutter <body>

  111. moparisthebest

    pep., but then evil alice can send 1 message with something different in <body> and <somefancymarkup>, it opens up a bad can of worms

  112. moparisthebest

    pep., won't they understand _bar_ or /baz/ , and if not, why exactly does it matter?

  113. pep.

    because I want to express something if I use that?

  114. moparisthebest

    by the way I'm using gajim now and it still *shows* all the characters, just additionally underlines/bolds/italics them

  115. pep.

    I want their client to convey it for me, they know what italic is, what bold it, they might not know what **, __, or // are

  116. pep.

    Or whatever other markup you fancy

  117. moparisthebest

    here's the other thing, I don't want to read your fancy markup, so I can turn it off on my client

  118. moparisthebest

    if your client sends it in <newfancymarkup> then I have to view that

  119. moparisthebest

    I don't have an option not to see it

  120. Link Mauve

    moparisthebest, err, Markup isn’t plain text, it just isn’t.

  121. Link Mauve

    moparisthebest, err, Markdown isn’t plain text, it just isn’t.

  122. moparisthebest

    it is though, it's made to be perfectly readable as plain text

  123. moparisthebest

    and maybe parts are a bit questionable but that's fine, we only want the super simple obvious parts

  124. Link Mauve

    If I don’t want to display formatting and turn it off in my client, when there is a plain text alternative I can, when you confuse Markdown and plain text I can’t anymore.

  125. moparisthebest

    except markdown is plain text

  126. moparisthebest

    or at least the subset that every chat program has been happy with for years

  127. Link Mauve

    moparisthebest, you may want only the very simple part, someone else may want one other part, and a lazy dev will shove you whatever their fancy lib supports.

  128. moparisthebest

    no, that's the entire point

  129. Link Mauve

    moparisthebest, Markdown is a superset of HTML.

  130. moparisthebest

    you don't use a lib to send anything

  131. pep.

    moparisthebest, markdown is not plaintext. If you say that I say we should use escaped XML as markup language

  132. Link Mauve

    It’s not plain text, has never been.

  133. pep.


  134. moparisthebest

    you send the exact text the user writes

  135. moparisthebest

    the recieving client displays it, optionally with a bit of formatting

  136. moparisthebest

    here I'll send a screenshot of what gajim displays so we are all on the same page *bold* _underlined_ /italic/

  137. Link Mauve

    moparisthebest, so how do you interpret what pep. just sent?

  138. Link Mauve

    moparisthebest, ah, but *bold* is actually italic in Markdown.

  139. Link Mauve

    Now what do you do?

  140. moparisthebest

    I interpret it as, why the hell is he writing xml in a text chat

  141. Link Mauve

    While what pep. wrote is actually bold in Markdown.

  142. Link Mauve

    moparisthebest, but that’s Markdown he just wrote.

  143. pep.

    I did write markdown indeed.

  144. Link Mauve

    Not XML.

  145. Zash

    Are you rehashing all the same things?

  146. pep.

    Zash, yes, because nobody understands apparently

  147. Link Mauve

    Zash, seems so. :/

  148. moparisthebest


  149. moparisthebest

    see no information is lost, all characters are displayed

  150. Link Mauve

    moparisthebest, except it looks bad.

  151. moparisthebest

    and it's readable with and without fancy parsing

  152. moparisthebest

    then turn it off, or make your client display it differently for you

  153. pep.

    *But* this _is_ not what I /meant/, at ~all~. < I'm just sending plaintext, this is not markup.

  154. moparisthebest

    that's fine, I still saw everything

  155. pep.

    How does your client deal with that now

  156. moparisthebest

    pep., https://burtrum.org/up/5eebca0a-a420-494c-816b-b0907998107b/open-screeny-23265.png

  157. pep.

    moparisthebest, I know exactly how it rendered it, that doesn't reflect at all what I wanted

  158. moparisthebest

    having a WYSIWYG editor wouldn't have done a better job

  159. moparisthebest

    and would be terrible

  160. pep.

    That's the issue when you don't separate <body> and $markup

  161. Zash

    pep.: You should have included a body hint saying text/plain

  162. Zash


  163. pep.

    Zash, a, too bad

  164. pep.

    Zash, ah, too bad

  165. Link Mauve

    moparisthebest, in Mattermost, markup is correctly displayed without these ugly * and / and whatnot, the user can focus on the text and not on * which pollute the reading.

  166. moparisthebest

    pep and then you opened the can of worms, you are in a contract dicussion, and alice sends <body>that'll be $10,000</body><fancymarkup>that'll be $1,000</fancymarkup> and since you use fancyclient you agree, but oops the xsf log bot only supports <body> sucks to be you in court

  167. moparisthebest

    and a million other things

  168. SamWhited

    How does that not reflect what you wanted?

  169. SamWhited

    Or, put another way, why does it matter to you that on the other thing a thing you weren't expectint to be bold ended up bold?

  170. pep.

    How does gajim deal with both *foo*

  171. SamWhited

    (or italics, or whatever)

  172. Link Mauve

    pep., you mean this and *that*? :)

  173. pep.

    SamWhited, because that could be interpreted as an emphasis, which I didn't want

  174. pep.

    Link Mauve, no I meant both at the same time

  175. Zash

    moparisthebest: same with email and xhtml-im and everything

  176. moparisthebest

    then you shouldn't have used the characters that have meant emphasis for 20+ years pep.

  177. Link Mauve

    I’d suppose it displays it normally-bolded.

  178. SamWhited

    pep. what did you want then? Even if there is no bolding or highlighting, *this* looks like emphasis to me.

  179. moparisthebest

    and to everyone else

  180. moparisthebest

    that's why everyone uses them

  181. pep.

    SamWhited, moparisthebest, that's the magic of having markup separated from plaintext

  182. SamWhited

    I didn't understand that.

  183. pep.

    I used ** but it could have been __ or ^^ for all I care

  184. Link Mauve

    SamWhited, because you have been thinking with computers since forever, go in the street and ask a random person who seldom use a computer what * means, you’d be surprised.

  185. moparisthebest

    I highly doubt that

  186. Link Mauve

    (I know my mother once asked me about something similar, which I had always been using without thinking about it, I think it was the * used for corrections.)

  187. moparisthebest

    I think you send anyone something like *this* it's pretty apparant

  188. SamWhited

    I disagree, even if I've never seen it I'll probably see *wow!* and assume someone meant emphasis; your mother wouldn't even think of it, she'd just read it and naturally ignore it.

  189. moparisthebest

    and if they don't know about it, they should learn, cause it's everywhere and always will be

  190. SamWhited

    I mean, I say "I assume they meant emphasis", it's not even something you'd think about reading that. It just parses fine.

  191. pep.

    SamWhited, so what if I use /foo/ now and it's interpreted as an emphase when in fact I'm writing IPA

  192. pep.

    If you want concrete examples

  193. SamWhited

    I'm reasonably sure most people won't write IPA, or regular expressions, or anything else where the conflict will matter.

  194. Link Mauve

    moparisthebest, haha, you wish.

  195. SamWhited

    Even if it did, okay, your IPA might be italics on some clients. It doesn't break it though.

  196. SamWhited

    That seems like a tiny edge case to me.

  197. pep.

    The point of a client is not to "not break"

  198. pep.

    "Ah I'm fine it barely works!"

  199. Link Mauve

    SamWhited, I know a room where people have been sending a lot of IPA over the years.

  200. Link Mauve

    (It’s about linguistics.)

  201. pep.

    Anyway, have to go

  202. moparisthebest

    pep., but it doesn't break anything including regex cause all characters are there

  203. Link Mauve

    moparisthebest, it just looks bad, while it could have been avoided altogether by simply separating formatting from input.

  204. moparisthebest

    I don't think so it's just a natural way to add emphasis without a huge WYSIWYG editor

  205. moparisthebest

    I don't have room for one of those on my phone screen

  206. Link Mauve

    And remember that it’s the way Gajim misguidedly did it, think about a random dev throwing that at their Markdown library which would strip any such character as soon as it is parsed, which would replace unescaped snake_case_words with italic in the middle of variable names, etc.

  207. SamWhited

    I'm sure you do know a room about that, but that room is also a tiny edge case and it's a tiny edge case that's not even broken

  208. Link Mauve

    moparisthebest, if your client considers it the natural way to add emphasis, that’s fine, it should just both expose the formatted one and the plain text one properly.

  209. Link Mauve

    And that way you also see that it oops transformed that variable name in snakecaseword, and can edit your message to fix it.

  210. Link Mauve

    SamWhited, for now, just wait until clients start using Markdown instead.

  211. SamWhited

    Yah sure, but that's a different issue. We should absolutely provide guidance and try to make sure that the easiest way to do it is also a good UX.

  212. Ge0rG

    Function names, path names and enumerations are in my experience the things most often misidentified by xmpp clients. Enumerations like (a)

  213. Link Mauve

    Bbl Rust meetup! \o_

  214. Link Mauve

    moparisthebest, SamWhited, I would totally welcome a XEP describing guidelines for input markup, to tell how clients could treat input to transform it into XHTML-IM or succ(XHTML-IM), just sending it as-is on the wire is a no-go.

  215. SamWhited

    I disagree, translating it into XHTML-IM is a terrible idea.

  216. SamWhited

    I don't know if translating to succ(XHTML-IM) is a good idea or not, of course, since it doesn't exist yet.

  217. Link Mauve

    I’ll send an email to the list later, in the meantime I’m going to be late for a Rust pizza. :)

  218. Ge0rG

    This subject is really bringing up emotions...

  219. daniel

    Ge0rG: it's not very technical. So everyone has an opinion

  220. Ge0rG

    daniel: and I'm getting less and less sure what my opinion is.

  221. jonasw

    great, I missed the party

  222. jonasw

    so, I’d like to add a few bits

  223. jonasw

    moparisthebest, re differences between body/non-body: yes, that’s a problem in some cases. I’m not sure how to fix that. However, I’d argue that if you’re doing transactions like that only over unsigned XMPP, you may be doing something wrong.

  224. jonasw

    (same thing holds for email)

  225. jonasw

    moparisthebest, re "/me", which is in body: funny thing about that. Pidgin hat a vulnerability where messages starting with /me would not be encrypted with OTR. That’s what you get from adding interesting semantics to body parts (pun not intended).

  226. moparisthebest

    yea email suffers from the same, probably other things

  227. jonasw

    otherwise, I tend to agree with Link Mauve, except that HTML email is an abomination which should be killed with fire.

  228. moparisthebest

    why would the sending side ever process that at all?

  229. jonasw

    SamWhited, I’ve seen people ask me what I mean with the underscores in "_foo_".

  230. SamWhited

    I don't see how that Pidgin bug is relavant; if we're going to argue for that being a reason never to interpret text in body then shouldn't we never put text outside the body because it's never encrypted because OTR only encrypts the body?

  231. moparisthebest

    isn't /me and what I'm talking about a 100% reciever feature?

  232. jonasw

    SamWhited, I just wanted to throw in the fun fact :)

  233. jonasw

    moparisthebest, yes, pidgin is broken

  234. moparisthebest

    anyway the biggest argument might be about fragmentation

  235. jonasw

    it uses /foo for commands, and I bet they implemented /me as "send the text behind /me with '/me' as prefix", circumventing the layers which added encryption.

  236. moparisthebest

    putting text in body makes it *just work* in all clients whether they make it fancy or not

  237. jonasw

    moparisthebest, now of course we can’t stop make people type things like *just work* in body (I’m with Link Mauve on that that we might want to specify how that’s supposed to work), but this shouldn’t be used as transport

  238. jonasw

    because it is not extensible, and most markups only have limited features, and at some point things become not-so-readable in plaintext.

  239. jonasw

    and yes, much of this may not matter for the typical IM user sending things, but it matters for automated services such as Flows bridge or bots sending high-density content which simply needs formatting to be easily parsable

  240. jonasw

    we need a format for that, and if we’re going to have a markup format in XMPP, it should work everywhere in XMPP..

  241. moparisthebest

    I know this is xmpp and such and I might get fried for saying this

  242. moparisthebest

    but not everything needs to be extensible

  243. jonasw

    (this is, again, for transport only. I’m not at all arguing that people shouldn’t be able to type *foo* and have it come up as emphasised, but the transport shouldn’t convey "*foo*" in that case)

  244. SamWhited

    I was about to write that. I'm not convinced the markup needs to be (I'm not convinced it shouldn't be either, mind)

  245. moparisthebest

    I think the sender shouldn't do any processing at all

  246. moparisthebest

    and reciever decides if it wants to emphasize stuff or not

  247. moparisthebest

    now also I'm only talking about the IM usecase

  248. jonasw

    only the sender can possibly know which semantics and styling was intended. trying to recover that at the receiver is going to be a mess.

  249. moparisthebest

    I think the microblogging use-case is entirely seperate and needs a seperate XEP and such

  250. jonasw

    yes, I’m with you on the IM usecase -- just not only IM between humans. also machines and humans, which is still IM.

  251. jonasw

    I’m not talking about microblogging.

  252. moparisthebest

    I don't think you want or need complicated markup in IM

  253. jonasw

    sure, the receiver can decide to strip all markup, and we totally should encourage implementations to allow that.

  254. jonasw

    I don’t want to be able to write it, but I want to be able to receive it. Yes, (and I’m going to be killed for that), this includes headings.

  255. moparisthebest

    does anyone enjoy MIRC colors for instance

  256. jonasw

    colors are tricky -- I made a proposal how to make them right.

  257. jonasw

    (actually colors and fonts are the reason I ban XHTML-Im in my clients, and I totally think that succ(XHTML-IM) should not support arbitrary colors and fonts.)

  258. jonasw

    what I think it sohuld support I already mentioned on the ML: Non-semantic things: - Colorise things with colors from a palette (e.g. 360 colors from the XEP-0392 palette) (via Georg Lukas) Semantic things: - Emphasis (typically italics), Strong (typically boldface) - Pre-formatted text (code), including a way to specify the language (this may make the colorisation of things obsolete, the only use-case I’ve heard so far is syntax-highlighting) - Blockquotes - Paragraphs - Enumerations and unordered lists - Links (but possibly without the possibility to change the text shown), with a whitelist of URL schemas Other things which may be useful, but I’m not sure if we don’t have better ways to do that by now: - Embedding multimedia content, like images, audio, video (a SIMS-message may be better suited for that)

  259. moparisthebest

    I think it should only support *bold* and /italics/ and _underline_ and, oh look, gajim and most other things already do, problem solved

  260. moparisthebest

    everything else is just regular text

  261. jonasw

    moparisthebest, sure, I’m fine if clients support that as input.

  262. jonasw

    but those "trivial" markups get complicated as heck in not-so-trivial situations like words which include one or more the meta-characters

  263. jonasw

    or sentences which happen to include them twice

  264. moparisthebest

    I think this is a solution in search of a problem

  265. jonasw

    I laid out use-cases on the ML.

  266. Ge0rG

    moparisthebest: when you enter that in gajim, can you see the markup?

  267. zinid

    tl;dr: have you decided yet what markup to use?

  268. jonasw

    zinid, no.

  269. jonasw

    zinid, you’re a server dev, you must look away :P

  270. zinid

    ok :D

  271. moparisthebest

    Ge0rG, what markup?

  272. Ge0rG

    Actually, the server should be able to convert the markup from one client format to the other

  273. moparisthebest

    I just have a box to type in in gajim

  274. zinid

    jonasw: yeah, nobody is asking server devs nowadays :)

  275. Ge0rG

    moparisthebest: my problem with adhoc pseudo markdown is lack of interop

  276. moparisthebest

    Ge0rG, except it works with or without processing equally

  277. Ge0rG

    Anyway, gotta run now. CU tomorrow

  278. jonasw

    it doesn’t

  279. moparisthebest

    so free perpetual interop

  280. jonasw

    in the cases I mentioned abve

  281. jonasw

    if it fails at the only thing it’s supposed to do, it doesn’t work.

  282. moparisthebest

    where does it fail?

  283. zinid

    I don't think a server can modify body due to e2ee

  284. jonasw

    zinid, tips hat, that’s a well-placed troll.

  285. jonasw

    moparisthebest, sentences which happen to contain multiple meta-characters which happen to have some special meaning despite that meaning not being intended.

  286. jonasw

    as an example

  287. moparisthebest

    jonasw, and something is bolded erroneously, and no one cares?

  288. moparisthebest

    what am I missing

  289. jonasw

    yes but that’s really the only thing this is supposed to do.

  290. moparisthebest

    it's perfectly fine

  291. jonasw

    conveying semantics by bold/italics/underline/whatever. it literally fails to do its sole purpose.

  292. Ge0rG

    moparisthebest: I wrote earlier that some clients replace (a), (b), (c) style enumerations with smileys

  293. jonasw

    also, tell my mother how to make a word containing an "*" italics/bold with Markdown.

  294. moparisthebest

    if I say the regex is .*bob.* and that ends up being bolded, you still get the message

  295. jonasw

    Ge0rG, go and kill pidgin with fire already.

  296. Ge0rG

    moparisthebest: no, because I can't copy paste that regex any more

  297. moparisthebest

    Ge0rG, uh yes you can

  298. moparisthebest

    it doesn't remove the *

  299. moparisthebest

    Ge0rG, https://burtrum.org/up/30079903-aaa9-43c1-b08f-2642b7e7764d/open-screeny-23190.png

  300. jonasw

    moparisthebest, emphasize "Trainer*Innen" please.

  301. moparisthebest

    jonasw, *Trainer*Innen* works

  302. moparisthebest

    that the bold'ing code missed it doesn't matter

  303. moparisthebest

    it's still obvious in the reading

  304. jonasw

    it’s super-awkward to read

  305. moparisthebest

    only because your a programmer that likes ASTs :P

  306. jonasw

    and no it doesn’t matter when a thing invented to do only exactly one thign literally doesn’t do that thing.

  307. jonasw

    and no it does matter when a thing invented to do only exactly one thign literally doesn’t do that thing.

  308. Ge0rG

    I'm an experienced user of markdown and I regularly fail to quote a formula with two multiplication signs.

  309. moparisthebest

    I disagree, it still conveys the same meaning whether it's highlighted or not

  310. SamWhited

    *this is bold* and so is **Trainer*Innen**, maybe? Just a thought (actual character doesn't matter obviously)

  311. jonasw

    SamWhited, sure, but this is the point where you don’t want humans to write that.

  312. jonasw

    that’s also exactly the kind of thing I meant by "not extensible". You’d normally have to bump namespaces for this type of change.

  313. jonasw

    we can’t do that if we put things in <body/>.

  314. moparisthebest

    it's not a problem that needs solved

  315. SamWhited

    Yah, fair, it's really not

  316. jonasw

    moparisthebest, also, pandoc would highlight the first part and leave the second unhighlighted.

  317. moparisthebest

    you don't need a spec or standard that solves every single edge case ever

  318. moparisthebest

    that's also fine, gajim highlights nothing

  319. jonasw

    moparisthebest, but it’s comparatively easy to do so!

  320. moparisthebest

    I guess if you give me a huge editor with a ton of buttons maybe

  321. moparisthebest

    I don't want that, I'll just type *trainer*innen* anyway

  322. moparisthebest

    how does the sending client even know what I mean

  323. jonasw

    you’re free to have a client which supprots that type of input (I’m going to write one, for sure). But that’s not what should be in the transport.

  324. moparisthebest

    then you run into UI issues and such

  325. jonasw

    the sending client can offer you neat in-line markdown preview support.

  326. moparisthebest

    I have limited space on my phone screen as it is

  327. jonasw

    I’m thinking like some tools do auto-completion. I can’t describe that in just one line, but the flow is amazing.

  328. Ge0rG

    With LMC you just retry multiple times to fix the markup you never wanted, giving up in frustration after the fifth attempt

  329. jonasw

    you really care to add any kidn of markup on the phone? I’d be too lazy to search for "*".

  330. moparisthebest

    basically that, then I'd have to try to get it to look right

  331. SamWhited

    FWIW, if I ever were to release one of my toy clients it would have something like the toolbar in this in it: https://simplemde.com/

  332. moparisthebest

    where as if you display what I send exactly, and maybe bold/italic/underline part, it's fine

  333. jonasw

    SamWhited, looks great

  334. SamWhited

    Maybe not with markdown, but something similar.

  335. SamWhited

    It's just a pleasant experience; I type **, my mother hits the "B" button. It all works out in the end.

  336. jonasw

    SamWhited, I was more thinking like: 1. You type *foo* 2. Client makes "foo" boldfaced and removes the asterisks. 3. You find that you didn’t want *foo* boldfaced, so you type backspace. 4. Client changes back to *foo*, but does not delete the *. 5. You can continue to type as normal.

  337. jonasw

    (in addition to a lightweight formatting toolbar)

  338. jonasw

    (of course, turning off any kind of formatting would work too. and stuff pasted from clipboard would never get formatted automatically.)

  339. moparisthebest

    or, you just type *foo*, recieving client may or may not bold it, everyone is happy, far less work, 100% interoperable

  340. jonasw

    moparisthebest, if everybody sees different things that’s not interoperable.

  341. jonasw

    that’s "it works"

  342. moparisthebest

    it's different regardless

  343. jonasw

    but not "it’s interoperable and works great"

  344. moparisthebest

    I typed this in courier new and you are seeing arial, maybe

  345. SamWhited

    Yah, Jira does the backspace thing and it never works as expected. I'm unsure why though.

  346. moparisthebest

    maybe we should start sending fonts and DPI values over xmpp too then?

  347. jonasw

    SamWhited, hm. I’d put some effort to make it work, if you care to test at some point? :)

  348. SamWhited


  349. jonasw

    moparisthebest, of course not.

  350. jonasw

    SamWhited, also, you can then try to exploit my webview-based message view :)

  351. SamWhited

    I am always game for that.

  352. jonasw

    moparisthebest, in fact, killing off any kind of font change support is one of the reasons why I’m in favour of obliterating @style in XHTML-IM or obliterating XHTML-Im altogether.

  353. jonasw

    but I don’t have XHTML-IM support yet, so ;-)

  354. moparisthebest

    I just don't buy the argument that me seeing *foo* without bold and you seeing *foo* bold is any sort of problem at all

  355. jonasw

    I’ll put the accessibility argument back in the ring.

  356. jonasw

    those asterisks and underlines are annoying for a11y software.

  357. jonasw

    and slashes etc.

  358. SamWhited

    If you didn't click it, also click the little eye icon in that web editor. It's the best part.

  359. jonasw

    SamWhited, :)

  360. jonasw

    much of this would be overkill for day-to-day IM use. but I definitely can see use-cases.

  361. jonasw

    and again, I think if we have these use-cases, I see no reason to have three different types of markup in XMPP if we can simply use the same thing for every use-case in the transport.

  362. SamWhited

    I don't think we can. Someone will always want a full blown layout engine for blogs. IM on the other hand just needs basic styling.

  363. moparisthebest

    jonasw, a11y software presumably would ignore those strange characters, I don't really know

  364. jonasw

    moparisthebest, I happen to know a few people who use a11y software.

  365. moparisthebest

    what does it say when it gets to *foo* or "bolded foo"

  366. jonasw

    SamWhited, I tend to agree that we might need some XHTML (but more than just the IM subset we had) for blogging cases.

  367. jonasw

    but for IM, I see something like XHTML-IM + possibly A/V embedding minus the @style as useful.

  368. jonasw

    moparisthebest, bolded "foo" leads to emphasis

  369. jonasw

    the other thing depends on the implementation

  370. jonasw

    but some will read out "asterisk foo asterisk"

  371. moparisthebest

    what kind of emphasis?

  372. jonasw


  373. moparisthebest

    I'm not sure what you mean

  374. moparisthebest

    like it screams at you?

  375. jonasw

    no, but like you would emphasize a word in a sentence. the whole point you use emphasis.

  376. moparisthebest

    so I think my argument holds and is the same

  377. moparisthebest

    someone who uses that software, depending on their client, would hear 'star foo star' or FOO with emphasis

  378. jonasw

    I don’t think so?

  379. moparisthebest

    and either way get the same meaning

  380. jonasw


  381. jonasw

    they would get "asterisk foo asterisk" with spoken emphasis.

  382. jonasw

    (if the client boldfaces the "*foo*")

  383. moparisthebest

    still they know what that means

  384. moparisthebest

    same as you or I know what it means when we read it

  385. jonasw

    that’s bad accessibility.

  386. jonasw


  387. jonasw

    that’s the type of thing people dependent on a11y software switch softwares for.

  388. moparisthebest

    it's identical to your plan of the sending client guessing all these things

  389. jonasw


  390. jonasw

    the sender can revise and make sure it actually reflects their intentions.

  391. jonasw

    they can’t do that on the receiving side.

  392. moparisthebest

    but no their software would either say "asterisk foo asterisk" or "foo" with emphasis

  393. moparisthebest

    either way they understand, no problems

  394. jonasw

    why would they omit the asterisks if the client has them in the text view?

  395. jonasw

    they understand, but it wastes time.

  396. SamWhited

    Yah, that sounds bad. Accessibility is definitely the thing I'm most concerned about if we were to recommend something like this. Maybe I'll see what androids reader does later.

  397. moparisthebest

    now I'm curious how does a11y software read xhtml-im

  398. moparisthebest

    it would have to be way worse

  399. jonasw


  400. jonasw

    they read it like they read webpages

  401. jonasw

    for which they are basically optimised

  402. jonasw

    (you do realize that a11y software scrapes the widgets of applications, don’t you?)

  403. moparisthebest


  404. jonasw

    (of course, applications help with that via a11y APIs and such)

  405. Link Mauve

    jonasw, not supporting font-family, color or color-background in @style is fine, but not supporting @style altogether is a bit bad imo.

  406. Link Mauve

    And it’s trivial to parse and whitelist correctly.

  407. Link Mauve

    “21:09:44 SamWhited> I don't think we can. Someone will always want a full blown layout engine for blogs. IM on the other hand just needs basic styling.”, that’s why I’ve been proposing to extend XHTML-IM with other profiles in the past, maybe I should go forward with that.

  408. Link Mauve

    Not only for microblogging, which wasn’t even my use-case back then.

  409. Link Mauve

    “21:10:57 jonasw> but for IM, I see something like XHTML-IM + possibly A/V embedding minus the @style as useful.”, @style is definitely useful, amongst the real-world examples of colour being used properly I’ve seen over the years were titles which include colour, sending a big red heart to someone, rainbows, spoilers, and in general style effects.

  410. Link Mauve

    You can argue that we all have to be professional in our communications and all, but being able to do playful things is also useful.

  411. Link Mauve

    That’s why I would dislike to see @style disappear altogether, whether in XHTML-IM or in a next spec.

  412. Link Mauve

    Not all of us are sad grown-ups. :)

  413. Zash

    <style color='rainbow'>hello</style>

  414. Zash

    And you seem to forget that using color in IRC is a crime against humanity and only annoying trolls and spammers use it

  415. Link Mauve

    Zash, currently we’re using span@style for that, per-letter, it works well and allows as much or as little control as you want.

  416. Link Mauve

    Zash, I’m actually enjoying when IRC people send spoilers in spoiler-style, and biboumi renders them as wanted.

  417. SamWhited

    I'm sure someone will need a layout engine, but that thing needs to not be XHTML-IM.

  418. SamWhited

    We need to figure out how to create something that won't end up with such an abysmal security record.

  419. SamWhited

    Extending the broken thing we have won't make that better.

  420. Link Mauve

    SamWhited, I once wrote a web implementation of XHTML-IM, approximately on the same model as poezio’s, and due to that I’m quite certain it didn’t have any kind of security issue.

  421. SamWhited

    Good for you, it would be the first I've ever seen.

  422. SamWhited

    As always, I'm not saying it's impossible (it's not). But most people aren't going to do it right the first time.

  423. Link Mauve

    That argument that it’s broken by definition is quite dubious.

  424. Link Mauve

    SamWhited, we need better security guidelines, two days ago I reviewed the current ones and they are abysmal.

  425. SamWhited

    Obviously, I disagree. The only way to have any inkling of security is to make the default secure and make it require work for developers to screw it up, not make the default broken and make it require work to fix.

  426. SamWhited

    I agree the current ones are terrible and could be improved, but it won't fix anything.

  427. Link Mauve

    You just discarded any web client here.

  428. SamWhited

    (although we should do it either way, hopefully it will help at least a little bit)

  429. Link Mauve

    The defaults of these APIs is to be insecure.

  430. SamWhited

    Yes, but unfortunately I can't change that spec.

  431. Link Mauve

    XHTML-IM isn’t any more or less insecure than RFC6121 here.

  432. SamWhited

    If we could deprecate the web I assure you, I'd be all over it, but this arguent isn't about the web. It's about how we interop with it.

  433. Link Mauve

    (Yes, I’ve seen implementations shove <{jabber:client}body/> into the DOM.)

  434. Link Mauve

    SamWhited, sure.

  435. Link Mauve

    It’s just a bogus argument because as a web dev you have to code extremely defensively all the time.

  436. SamWhited

    Sure, you should, but I don't see what that has to do with anything

  437. SamWhited

    But sure, for the sake of argument let's ignore the people that will do the obviously wrong and broken thing

  438. SamWhited

    Let's talk about the people who will try to do it right, and will implement the whitelist and be careful about elements and attributes

  439. Zash

    I'm not convinced we can make the web not be broken by default

  440. SamWhited

    Any tiny logic bug in the XHTML-IM whitelist implementation leads to a critical issue. It doesn't matter how good you are, you will make mistakes.

  441. SamWhited

    We can make something where any trivial mistake isn't a critical security issue.

  442. Link Mauve

    You’re saying that argument in loop, that people will do the broken way by not reading the spec, and then that it isn’t their fault and we should make a spec that can’t be gotten wrong, but then all specs will be gotten wrong by people who don’t read them, and the loop is looped.

  443. SamWhited

    I am not saying anything of the sort

  444. SamWhited

    Of course you can always get something wrong, you can always introduce security issues, etc.

  445. Link Mauve

    SamWhited, implementing XHTML-IM by a simple whitelist is imo not the correct way to go, see poezio’s implementation (sadly that web implementation I did was proprietary, and AFAIK never deployed publicly).

  446. SamWhited

    I'm saying *we* should be writing specs defesivesly, not relying that web devs will develop defensively, or that they will never make any mistakes.

  447. SamWhited

    Link Mauve: I agree, that is the correct way to go.

  448. Link Mauve

    SamWhited, we can’t make any spec if the goal is to make web devs develop non-defensively.

  449. SamWhited

    That's also not what I said

  450. Link Mauve

    Zash, same. :(

  451. SamWhited

    I said we shouldn't be *relying* on the fact that web devs will code defensively and make no mistakes.

  452. SamWhited

    Everyone has to be defensive, including us. We can't just assume the burden lies entirely on the application developer.

  453. Link Mauve

    Right, by providing them tested implementations, by providing them clear security guidelines, by encouraging them to do the correct thing.

  454. Link Mauve

    Not by rewriting what works into something which works less well already.

  455. Link Mauve

    SamWhited, sure.

  456. SamWhited

    That's not good enough. I'm not disagreeing, by all means, improve the security considerations, that would be great, but it's not going to help in any significant fashion.

  457. SamWhited

    We need something where the default isn't broken and where every mistake isn't an issue.

  458. Link Mauve

    I disagree on that.

  459. Link Mauve

    You can’t have a non-broken default on the web.

  460. Link Mauve

    It’s just impossible.

  461. Link Mauve

    Because it’s broken by design.

  462. SamWhited

    Sure you can, a number of techniques have been discussed.

  463. Link Mauve

    What we currently have works, has no intrinsic security issue, can be implemented securely (by us if any), and we should encourage that instead of replacing it with something with exactly the same potential security issues.

  464. SamWhited

    Please read the mailing list thread, we're literally just reiterating the exact same things that have been said on it.

  465. Link Mauve

    I have read it entirely already.

  466. Link Mauve

    And no matter what you replace it with, div.innerHTML = parse_markdown(message.body); will exist.

  467. SamWhited

    Why do you think we would encourage replacing it with something with the exact same issues?

  468. SamWhited

    What does that have to do with anything? Yes, we can't stop people from doing non-standard and broken things with the body, that has nothing do with deprecating XHTML-IM though.

  469. Link Mauve

    Deprecating XHTML-IM means people will find other ways to do formatting, the discussion we had earlier has terrifying examples of that.

  470. Link Mauve

    And replacing XHTML-IM (and subsequently deprecating it) has exactly the same issues as XHTML-IM has currently.

  471. mathieui

    SamWhited, because deprecating XHTML-IM without a replacement is something I am not looking upon favorably; and any replacement still has the exact same kind of issues you want to avoid

  472. SamWhited

    No, again, read the list, there have been multiple suggestions that do not have the exact same kind of issues.

  473. Link Mauve

    I have, and they all have them, even the JSON-based protocol break solution has them, if you don’t sanitise your input properly.

  474. SamWhited

    anyways, I've got to run

  475. Link Mauve

    And I, to sleep.

  476. Link Mauve

    See you! \o_