XSF Discussion - 2018-12-08

  1. Yagiza


  2. Yagiza

    jonas’, are you Jonas Schäfer?

  3. Yagiza

    Is it possible to adopt a deferred XEP?

  4. ralphm


  5. ralphm

    Which one?

  6. Yagiza

    ralphm, right now I'm about XEP-0394: Message Markup

  7. Yagiza

    ralphm, I want to implement something like it in my client as an alternative to deprecated XEP-0071, but in it current state it is almost useless, so I don't want. And it seems, no one wants.

  8. Yagiza

    ralphm, and author said that he have no time to improve it.

  9. ralphm

    Yeah, XHTML-IM has various security concerns, that's why it was deprecated

  10. Yagiza

    ralphm, the idea of the XEP is good, but it's current implementation is awful. We need to add more features and remove unneeded restrictions to make it a usable alternative to XEP-0071.

  11. ralphm

    There's been some recent discussion on it

  12. ralphm

    And there are a few other suggestions

  13. Yagiza

    ralphm, yes. But the main question is who will keep updating the XEP. At least, to advance it back to experimental state.

  14. ralphm

    https://xmpp.org/extensions/inbox/bmh.html https://xmpp.org/extensions/xep-0393.html

  15. ralphm

    Yagiza: sure. I'd send an email to standards@xmpp.org about your suggestions for modification. Then either Jonas will ask for a pull request or more discussion ensues.

  16. Yagiza

    ralphm, ok, thanx

  17. ralphm

    No worries.

  18. oli

    Yagiza: xep-0394 _sucks_

  19. oli

    don't implement it.

  20. Yagiza

    oli, the idea is good.

  21. oli

    no its not

  22. oli

    i hate the idea

  23. Yagiza

    oli, why?

  24. Yagiza

    oli, I myself hate an idea of using LML in IM, but I feel ut's a good idea to allow using rich text formatting.

  25. oli

    because it forces me to use some weird "markup"

  26. Yagiza

    oli, it forces you? Never heard about any XEP, which FORCES someone to do something.

  27. Yagiza

    oli, AFAIK all the XEPs are optional.

  28. oli

    why not use <b> <em> <i> ?

  29. Yagiza

    oli, what do you mean?

  30. Yagiza

    oli, where to use them?

  31. oli

    why not use some basic xhtml for rich text.

  32. oli

    the client can decide how to implement it

  33. oli

    if you like 0394 then translate it

  34. oli

    client translates it to xhtml

  35. oli

    underlines as italics is weird...

  36. Yagiza

    oli, i can't get your point.

  37. Yagiza

    oli, what do you suggest?

  38. oli

    the richtext format on the wire should be xml, like xep-0071, but much simpler

  39. oli

    clients could implement whatsapp like markup, but translate it to xml

  40. Yagiza

    oli, using the way it described in XEP-0071 have nasty problem: formatted and unformatted texts are separated. So, it's possible to send absolutely different content to those, who's software supports XEP and for those, who's software do not. Also, it will make problem with P2P encryption XEPs.

  41. ralphm

    oli: the primary objection to having something syntactically a subset of (X)HTML is that people just throw at their closest HTML rendering engine, without checking.

  42. Yagiza

    oli, so, XEP-0394 is much better in that way: text itself and its formatting MUST be separated!

  43. oli

    maybe im confusing xeps

  44. Yagiza

    oli, yes. If you're about XEP-0393, it's really awful.

  45. Yagiza

    oli, I'm strongly against using LML in IM.

  46. Yagiza

    oli, also, it's too bad that XEP names are confusing.

  47. oli

    fuck, sorry

  48. Yagiza

    oli, I told about it more than a year ago, but nothing's changed so far.

  49. Yagiza

    oli, XEP-0393 describes LML, but called "Styling" and XEP-0394 describes styling, but called "Markup"!

  50. Yagiza

    oli, I also was often confused because of that and often mixed them up!

  51. oli

    ok, i will remember 0393 *bad* 0394 good

  52. Yagiza

    That's why I want to adopt XEP-0394, to fix those issues and make it usable, to start its implementation in my client.

  53. oli

    which client

  54. oli


  55. Yagiza

    oli, yes. XEP-0393 is a bad idea itself. XEP-0394 is a good idea, but awful implementation in its current state.

  56. Yagiza

    oli, eyeCU.

  57. Yagiza

    oli, it has full implementation of XEP-0071 right now.

  58. ralphm

    I'd rename for being so much like ICQ you might have a trademark issue

  59. Yagiza

    oli, it can even use both http(s)/ftp and cid (BOB) chemas for embedded images.

  60. Yagiza

    ralphm, i don't think so. eyeCU called that way because it's geoloc-oriented. It has built-in online map engine, so you can see your contacts on the map.

  61. ralphm

    I don't have a beef in it, just saying that I'd avoid a legal discussion that you're likely to lose.

  62. ralphm

    I'm not taking about the client, I'm taking about its name.

  63. ralphm


  64. Yagiza

    ralphm, yes. You're just the first person, who ever tell that our client name may have legal issues.

  65. ralphm

    Better me than a lawyer

  66. Yagiza

    ralphm, yes. So, you gave me an idea to register "eyeCU" and eyeCU logo as a trademark!

  67. ralphm

    Good luck. I'm very curious about the outcome.

  68. oli

    OS/2 :)

  69. Yagiza

    ralphm, you are from Netherlands, you talk just like you're from USA! ;-)

  70. Yagiza

    oli, do you fel something bad about IBM OS/2?

  71. Yagiza


  72. ralphm

    I'm told I do sound like a Californian when speaking English.

  73. oli

    Yagiza: I used it in the 90s with fidonet and BBS

  74. Yagiza

    ralphm, yes, but that's not an idea. A character of a popular Russian sitcom said once: "USA is a country of lawyers and criminals!". The idea is that because of lawyers in USA anyone may suddenly find himself a criminal.

  75. Yagiza

    oli, me too!

  76. oli

    i dont think there is a problem with eyeCU and ICQ.

  77. oli

    it did remind me of CU-SeeMe

  78. oli

    ok, but thats offtopic

  79. Yagiza

    oli, I'm sure it's impossible in Russia, even now, when ICQ belongs to a Russian company. But I can't be sure about USA and other countries with strange laws and almighty lawyers.

  80. oli

    are there other clients that support xep-0394?

  81. Yagiza

    oli, I hope, no

  82. Yagiza

    oli, if there are, it makes its harder to improve it.

  83. Yagiza

    oli, the authors of those clients will try to resist serious changes.

  84. ralphm

    I don't see that as a valid reason against changes while it is experimental or even deferred.

  85. Yagiza

    ralphm, me so

  86. Yagiza

    ralphm, but

  87. Yagiza

    ralphm, once I tried to suggest improvements for XEP-0363 here, some people started to argue against them. And the only argument was that there are existing implementations and authors will not implement my suggestions even after XEP is updated.

  88. ralphm

    Well, if they're backwards incompatible, it may require increasing the number at the end of the namespace. Whether a change gets accepted is ultimately up to the Council.

  89. ralphm

    Oddly, XEP-0363 is still in Last Call, so you might make another attempt.

  90. Yagiza

    ralphm, to tell the truth, I didn't even try to post my suggestions to mailing list, 'cause they were hardly criticized by a pair of participants of this (or jdev) room.

  91. Ge0rG

    Somebody tried to make the 0363 client a full HTTP proxy and almost succeeded. The web is a huge mess for security, not only the markup but also the transport.

  92. Yagiza

    Ge0rG, IC

  93. Ge0rG

    Also 0393 was supposed to document existing usage of the markup in some clients, and is sufficiently easy to implement. I'm not convinced that 0394 has a chance for wide adoption

  94. Yagiza

    Ge0rG, that's why I think it should be an informational XEP, not standards track.

  95. Ge0rG

    The names are really bad. I already suggested renaming them to markright (uses >) and markleft (needs < for all styling annotations)

  96. daniel

    Funnily enough 393 is better than what some clients are implementing

  97. Yagiza

    Ge0rG, the only idea I suggested is to send file hash when requesting a slot. So, if file is already on the server, server will reply just with URL, without upload slot.

  98. daniel

    Same syntax stricter rules

  99. Ge0rG

    Yagiza: I've implemented 0393 in my client. It's great.

  100. Yagiza

    Ge0rG, your arguments?

  101. ralphm

    Indeed, 0393 is basically codifying the Slack syntax, no?

  102. Yagiza

    Ge0rG, besides "it's great because I like it".

  103. daniel

    You only start noticing how important the parsing rules in 393 are when you use a client that doesn't follow

  104. daniel

    > Indeed, 0393 is basically codifying the Slack syntax, no? I mix of WhatsApp and slack plus some in the wild testing

  105. daniel

    I mean WhatsApp and slack don't publish their exact rules

  106. daniel

    But it's the same general syntax

  107. Ge0rG

    Yagiza: your suggestion is nice, but now you created an oracle that will tell the user whether a given file exists on the server

  108. Ge0rG

    Yagiza: 0393 is in a sweet spot of easy to implement, easy to understand for users, sufficiently easy for handicapped people

  109. Ge0rG

    Also works over transports

  110. Yagiza

    Ge0rG, yes. And what's wrong with it?

  111. ralphm

    Ge0rG: do you think that the body markup hints spec in the inbox is a useful complement to XEP-0393?

  112. Ge0rG

    ralphm: haven't read yet

  113. daniel

    ralphm: it feels overly generalized. That will end up like the stanza-id xep or the hints xep that is only used in one place. I'd prefer to use add a <styled xml=message styling /> hint

  114. ralphm

    Huh? Doesn't BHM just tell the other side which markup dialect was used in the body?

  115. ralphm


  116. daniel

    Yes. But I don't think anyone will ever use anything else

  117. daniel

    And then why bother having to rely on a second xep

  118. Yagiza

    Ge0rG, which of above cannot be applied to XEP-0394?

  119. pep.

    I would just implement xhtml-im fwiw, maybe without CSS until we find a replacement. There is no good alternative for it as of today and deprecating it was a mistake.

  120. pep.

    Even then, CSS included in there is pretty simple, it's not CSS3

  121. pep.

    393 is fine as an input method, but that's about it

  122. ralphm

    pep.: the problem isn't which parts you use, it is how clients implement rendering, which is usually not checking the input and passing it to a generic HTML renderer

  123. pep.

    Yes, I just don't want to buy this argument, you can say that about pretty much anything

  124. oli

    lets not use the web

  125. ralphm

    I don't think the idea behind XEP-0394 is bad, as it provides a way to very explicitly mark up the plain text. Might be better if it was somehow combined with References.

  126. oli


  127. ralphm


  128. ralphm

    And see also https://xmpp.org/extensions/xep-0385.html

  129. waqas

    I have very mixed feelings about xhtml-im, but the main thing I know about it is that every single client I looked at had RCE vulnerabilities.

  130. pep.

    Because it was the only place with vulnerabilities right

  131. Yagiza

    pep., why not just improve XEP-0394 instead of trying to rip-off CSS from XEP-0071?

  132. waqas

    It was. I think I averaged 15 minutes each, across more than a handful of clients before seeing something dumb.

  133. waqas

    Including some native clients with embedded HTML, where RCE meant full local system access.

  134. Yagiza

    pep., also, what's nice about LML as input method? WYSIWYG is always better for and user, than LML.

  135. pep.

    Yagiza: yeah I don't really care about the input method tbh

  136. Yagiza

    pep., so, then. Why improved XEP-0394 is not better than ripped XHTML-IM?

  137. ralphm

    waqas: especially in MUC context, because it doesn't require direct contact and the amplification angle?

  138. oli

    ralphm: > And see also https://xmpp.org/extensions/xep-0385.html i don't understand what it has to do with markup and references.

  139. pep.

    Yagiza, Dismiss the comment about CSS. It's not that complex. If people want more stuff in security implications, let there be more stuff added. I don't think deprecating the xep altogether was the thing to do

  140. ralphm

    oli: XHTML-IM provides a way to include images

  141. oli


  142. oli

    xhtml-im includes a lot

  143. ralphm

    oli: so SIMS helps achieving that in a similar way as XEP-0394 does. Also why I think they should be aligned, spec wise.

  144. waqas

    Note that I'm neither for, nor against deprecation. I think it's a feature people may want. It was simply concerning how hard it was to find an implementation that was secure.

  145. oli

    Yagiza: which changes for xep0394 do you propose?

  146. oli

    where are the problems?

  147. ralphm

    waqas: disconcerting indeed

  148. ralphm

    By the way, XEP-0393 and XEP-0394 could totally co-exist.

  149. Yagiza

    oli, add support for embedded images and hyperlinks.

  150. Yagiza

    oli, add normal "bold", "italic", "underscore" text decoration instead of strange "emphasis".

  151. Yagiza

    oli, add ability to specify font type, font size and text color.

  152. Yagiza

    oli, add ability to specify text alignment.

  153. Yagiza

    oli, add ability to remove list markers from the beginning of list item text when rendering.

  154. Ge0rG

    Yagiza [10:47]: > oli, add ability to specify font type, font size and text color. This will end up with clients sending 5px Comic Sans black on black, kthx

  155. Yagiza

    Ge0rG, as I said many times, any feature could be abused. We should deprecate XMPP itself, 'cause there are hundreds features in it which could be used for abuse.

  156. oli

    but it also get used. like in the mess we have with emails

  157. ralphm

    Yagiza: if those are your suggestions, then I'd rather have you look at the References stuff I just mentioned

  158. ralphm

    Also, if it were my client, I'd never implement font type, size, or color.

  159. oli

    supporting font size and color will be messy

  160. oli

    monospace font has some value

  161. ralphm

    With backticks, sure

  162. oli

    everything else should be semantic markup only

  163. Yagiza

    oli, ralphm, it depends on what you are using it for.

  164. oli

    maybe xhtml-im is just the right way to do everything fancy

  165. Yagiza

    oli, yes, but it has flaws which XEP-0394 solves.

  166. Yagiza

    oli, so making XEP-0394 powerful enough, but without XHTML-IM flaws is a good way, I beleive.

  167. ralphm

    oli: I'd see the use of monospace for literals (one backtick) and code snippets (triple backticks) as purely semantic.

  168. ralphm

    Allowing users to specify font size, type, or color, just makes for a horrible mess. Like different clients/desktops having different default background colors.

  169. ralphm

    We have this XHTML-IM right now, and at some time patched Gajim to ignore those styles completely.

  170. oli

    maybe we could just encapsulate rfc822 messages

  171. oli

    would be super fun and messy

  172. Yagiza

    ralphm, author of XEP-0394 thinks about specifying not text color but only its hue and saturation. To allow client always make text contrast. So, that's not really a problem.

  173. Yagiza

    Inability to specify bold, italic and underscore in different combinations if much worse.

  174. ralphm

    I don't agree with the author then, that this is useful.

  175. oli

    have anyone thought about accessibility?

  176. Yagiza

    oli, what's wrong with accessibility? If contrast problem is solved, I guess no problem.

  177. ralphm

    I strongly think that markup should be semantic

  178. oli

    and i believe that xep-0393 is not very screen reader friendly

  179. ralphm

    E.g. while monospace for literals is nice, it doesn't work if you are in a terminal. Then you need some other way of rendering that differently. E.g. by setting a different background.

  180. ralphm

    oli: why not?

  181. oli

    i have to test it

  182. ralphm

    I'd say markdown-like syntaxes are actually very good for screen readers.

  183. oli

    screen reader test: *one* _two_ `three`

  184. oli

    »one underscore two underscore backquote three backquote«

  185. oli

    doesn't work well with android talkback

  186. oli

    ~talkback~ select-to-read

  187. jonas’

    Yagiza, yes, you can adopt a deferred XEP, but I might retract XEP-0394 in the medium future actually

  188. Yagiza

    jonas’, so, I can try to publish my own XEP instead of that one?

  189. jonas’

    you can also adopt it if you want

  190. jonas’

    I’d be fine with that, since I want to go down other routes, I think

  191. Yagiza

    jonas’, that's nice

  192. jonas’

    Yagiza, my original idea where to go with XEP-0394 was to enforce a specific plain-text representation of the different markup variants to have an automatic plaintext fallback

  193. jonas’

    so e.g. a span marked with strong would have to be bracketed with *

  194. jonas’

    but that was just the last idea I had

  195. Yagiza

    jonas’, IC

  196. Yagiza

    jonas’, anyway, we should think about the best way to implement that all.

  197. jonas’

    I think we might end up with a revamped version of '71 actually

  198. oli

    so xep-0071 is security nightmare, xep-0393 horrible for screen readers and sexist, xep-0394 will be retracted

  199. MattJ

    oli, ok, what?

  200. jonas’


  201. oli

    lets just use plaintext.

  202. jonas’


  203. jonas’

    what did I miss here?

  204. oli

    gender gap doesnt work

  205. oli


  206. oli


  207. oli


  208. jonas’

    ah, that

  209. MattJ

    jonas’, ? enlighten me?

  210. daniel

    that’s going to require so much explaining

  211. jonas’

    MattJ, in german, we have gender in nouns. the male version is the default.

  212. jonas’

    then there’s the "in" suffix which makes it a female word

  213. jonas’

    e.g. Lehrer (-> male teacher), Lehrerin (-> female teacher)

  214. jonas’

    now the male default is viewed as sexist by some (many even?), and also the restriction to two versions (male and female) as problematic

  215. jonas’

    so some constructs such as Lehrer*In (kind of a wildcard thing) or Lehrer_In (symbolising the gap in the language to support all the cases) have been invented

  216. MattJ

    I see

  217. jonas’

    in formal language, Lehrer/In was typical (but also only represents the two versions), LehrerIn has become a shorthand of that

  218. jonas’

    (I even brought that up when XEP-0393 was discussed)

  219. MattJ

    Sounds like it's the German language that's sexist, not XEP-0393 :)

  220. jonas’

    that’s true

  221. MattJ

    But yes, it highlights the fact that the XEP assumes these symbols are just free for it to use for its own purpose

  222. jonas’

    it does

  223. oli

    i'm arguing all the time that we just change the german language, but without any succesd

  224. jonas’

    oli, sounds like a plan, but in that case I’d actually like to see the "*" version; I like how globby it is :)

  225. oli

    what do you mean?

  226. jonas’

    which part of my statement is unclear to yu?

  227. jonas’

    which part of my statement is unclear to you?

  228. oli

    like to see the * version

  229. oli


  230. daniel

    fwiw this could potentially be fixed in the xep

  231. jonas’

    making the non-existent grammar more complex?

  232. daniel

    but that’s not as cool as complaining about stuff

  233. jonas’

    still waiting on Sams promise to deliver a formal grammar for the thing.

  234. daniel

    jonas’, one potential fix (of the two that i have in mind) would actually make things easier

  235. daniel

    although i would prefer the more complicated one. :-)

  236. oli

    jonas’: i would eliminate the multiple grammatical genders from the german language. problem solved

  237. oli

    okay, but what about screen readers?

  238. jonas’

    oli, I like you, you repeat all the arguments I brought up a year ago :)

  239. jonas’

    gives me the feeling I’m not totally outside of the norm

  240. Yagiza

    If I adopt XEP-0394, it won't be retracted, so calm down.

  241. Ge0rG

    Maybe XHTML-IM is just the wrong way to do anything. I don't want somebody else to be dictating how the text *I* shall read will look. I'm okay with the sender define monospace vs normal, and _maybe_ color hints from a predefined high contrast palette and _maybe_ relative font sizes for pasting headings.

  242. oli

    for chat i'm happy with plain text. for everything else we could resurrect google wave

  243. jonas’

    Ge0rG, so you want XHTML-IM :)

  244. jonas’

    not the current one

  245. jonas’

    but you want semantic markup

  246. jonas’

    emphasis, monospace, headings

  247. ralphm

    oli: I think that's a minority opinion.

  248. oli

    better plain text than xep-0393. i'll try to disable it in conversations, later.

  249. Syndace

    Couple of OMEMO questions: OMEMO defines KeyTransportMessages to be used to encrypt out-of-band non-message data like pictures or files or whatever you want. In reality these KTMs have become a tool to do manual ratchet forwarding/silent session creation in case a session is broken. So my question is: if you ever wanted to use KTMs for actual data, how would you even know, which KTM is for your photos, which one is for that pdf someone sent you and which one is just a ratchet forwarder? Is there any identification mechanism? If not, should we add one? And are there any XEPs using the KTM mechanism?

  250. jonas’

    Syndace, https://xmpp.org/extensions/xep-0396.html this maybe?

  251. jonas’

    if KeyTransportElement == KeyTransportMessage

  252. Syndace

    jonas’: Thanks, it is ^^

  253. daniel

    Syndace: I think the original plan was to just reuse the element somewhere as a sub element

  254. Syndace

    daniel: That's how it's done in the XEP that jonas' linked, makes a lot of sense

  255. daniel

    And that would give you the context

  256. daniel

    Yes I don't like that xep for various reasons. But it is a good demonstration on how it was originally intended to be used

  257. Syndace

    Okay cool. At least gives me a good hint on how to add KTMs to my lib...

  258. ralphm

    oli: I don't understand. People _already_ type markup like this, and I like that Conversations takes those hints. I don't really like that it retains the markers, though. Other messaging systems don't, when they interpret the plain text.

  259. jonas’

    you must retain the markers when you make up markup out of thin air

  260. jonas’

    if we just had an out-of-band way to signal that the markers really are intended for markup....

  261. pep.

    If only

  262. daniel

    I by the way have a work around for the _programmier_innen_ problem that probably shouldn't cause side effects

  263. daniel

    Will test this for a while

  264. daniel


  265. daniel

    Coming up with the parsing rules Was a process. It doesn't mean it has to end there. It can still be modified

  266. daniel

    That's what experimental xeps are for

  267. oli

    done. i just disabled ImStyleParser. now i can write underlines without the italics. make the _usenet_ great again.

  268. ralphm

    jonas’: haha

  269. ta

    > done. i just disabled ImStyleParser. now i can write underlines without the italics. make the _usenet_ great again. Actually i'd like to see that in expert preferencies

  270. oli

    switching to propet old-school style?

  271. vanitasvitae


  272. vanitasvitae

    When you just want to game a little bit...

  273. ralphm


  274. alexde

    Hope it got a good multiplayer: https://repl.it/site/blog/multi ...