XSF Discussion - 2017-10-13

  1. Guus has joined

  2. Guus has left

  3. Guus has joined

  4. intosi has joined

  5. Guus has left

  6. Guus has joined

  7. Guus has left

  8. Guus has joined

  9. Guus has left

  10. Guus has joined

  11. daniel has left

  12. Guus has left

  13. dwd has left

  14. Zash has left

  15. Zash has joined

  16. jere has left

  17. jere has joined

  18. nyco has left

  19. Zash has left

  20. jjrh has left

  21. Zash has joined

  22. efrit has joined

  23. intosi has joined

  24. jjrh has left

  25. intosi has joined

  26. Guus has joined

  27. jjrh has left

  28. jjrh has left

  29. moparisthebest has joined

  30. moparisthebest

    What if we replace xhtml-im with bbcode!!!

  31. jjrh has left

  32. moparisthebest has left

  33. moparisthebest has joined

  34. moparisthebest

    Think of all the php implementations at our disposal

  35. andrey.g has joined

  36. matlag has left

  37. jjrh has left

  38. jjrh has left

  39. jjrh has left

  40. emxp has joined

  41. Guus has left

  42. alacer has joined

  43. lskdjf has joined

  44. jjrh has left

  45. Valerian has joined

  46. mimi89999 has joined

  47. jjrh has left

  48. jjrh has left

  49. jjrh has left

  50. Guus has joined

  51. Guus has left

  52. jjrh has left

  53. alacer has joined

  54. Guus has joined

  55. jjrh has left

  56. jjrh has left

  57. lskdjf has joined

  58. alacer has left

  59. intosi has left

  60. Syndace has joined

  61. jjrh has left

  62. alacer has joined

  63. Ge0rG has left

  64. daniel has joined

  65. Guus has left

  66. Guus has joined

  67. jjrh has left

  68. jjrh has left

  69. SamWhited has left

  70. jjrh has left

  71. alacer has left

  72. alacer has joined

  73. vanitasvitae has joined

  74. la|r|ma has joined

  75. lskdjf has joined

  76. Guus has left

  77. Guus has joined

  78. lskdjf has left

  79. jjrh has left

  80. alacer has left

  81. lskdjf has joined

  82. Zash has left

  83. lskdjf has joined

  84. uc has joined

  85. efrit has left

  86. alacer has joined

  87. tux has left

  88. tux has joined

  89. daniel has left

  90. Valerian has left

  91. SamWhited has left

  92. mimi89999 has joined

  93. alacer has left

  94. uc has joined

  95. la|r|ma has left

  96. la|r|ma has joined

  97. Valerian has joined

  98. lskdjf has joined

  99. Zash has joined

  100. alacer has joined

  101. jere has left

  102. goffi has joined

  103. Valerian has left

  104. alacer has left

  105. alacer has joined

  106. Guus has left

  107. Flow has joined

  108. alacer has joined

  109. alacer has joined

  110. Flow has left

  111. Tobias has joined

  112. uc has joined

  113. emxp has joined

  114. dwd has left

  115. dwd has left

  116. la|r|ma has left

  117. la|r|ma has joined

  118. uc has joined

  119. dwd has left

  120. Flow has joined

  121. SamWhited has left

  122. ralphm has left

  123. uc has joined

  124. Flow has joined

  125. Flow has joined

  126. dwd has left

  127. alacer has joined

  128. sonny has joined

  129. jonasw

    moparisthebest, loool

  130. Zash

    I do wonder if we should revive the <font> tag as replacement for the style attr

  131. jonasw

    I don’t believe in font styling, but people seem to think differently

  132. alacer has joined

  133. jonasw

    it’s the number one reason I block inbound formatting

  134. Zash

    Way easier to sanitize <font color="name | #hexhex">

  135. jonasw

    if we start to go down the route to revive parts of deprecated HTML, we can go down Sams route of inventing our own markup all the way

  136. Zash

    jonasw: People want stickers!!

  137. jonasw

    people don’t know what’s good for them!

  138. Zash

    People want the silliest things!

  139. sonny has joined

  140. Zash

    Do we give it to them or do they go elsewhere?

  141. Zash

    Nice things, none shall have them!

  142. Flow has joined

  143. Zash

    Only shiny, silly things

  144. edhelas

    stickers are possible with XMPP

  145. jonasw

    SIMS + a repository of stickers yes

  146. Zash

    Sure they are, since literally forever

  147. edhelas

    non, with Bits Of Binary as well

  148. Zash

    Peoples reasons for XMPP suckage don't need match reality

  149. jonasw

    edhelas, do stickers fit into BOB?

  150. Zash

    Make them fit

  151. jonasw

    Zash, they sure match the reality of actual implementations :)

  152. edhelas

    well 20kb-30kb is enough for most of them

  153. jonasw

    30kB * 4 / 3 = 40kiB stanza

  154. Zash

    That's well within the 10M stanza limit, even if base64'd

  155. edhelas

    also BOB use some hash, so they are transfered only once

  156. jonasw

    there’s a 10MiB stanza limit? :)

  157. Zash

    In Prosody, IIRC inspired by some recommendation for minimal limit somewhere

  158. edhelas

    Movim implement stickers using BOB :)

  159. edhelas


  160. jonasw

    7.5 MiB data limit -- that’s well sufficient for avatars

  161. edhelas

    jonasw at one moment people will ask for high-def-animated-with-sound stickers

  162. jonasw

    I recall that people said that PEP avatars are not feasible due to (among others) stanza size limit?

  163. Flow has left

  164. Zash

    Here we go. Why can't I have my browser plugin that lets me link directly to sections?

  165. Kev has joined

  166. Zash

    https://xmpp.org/rfcs/rfc6120.html#security-dos > A deployed server's maximum stanza size MUST NOT be smaller than 10000 bytes

  167. Zash

    Wait that's ~10k

  168. jonasw


  169. Steve Kille has joined

  170. zinid

    and there is no way to check what limit is applied on the server :)

  171. zinid

    we need a XEP

  172. Zash

    Path MTU discovery!

  173. Zash

    Now with eXtensibility! :D

  174. Zash

    MattJ: How did we end up with 10M then?

  175. dwd has left

  176. emxp has joined

  177. Zash

    I suppose you could survey peoples vCards and multiply the maximum size by some number out of a hat and call it a day.

  178. jonasw

    Zash, it’s not impossible that I complained a few years ago when my fiancees avatar wouldn’t upload and that made pidgin fail to connect or something. I remotely recall there to be such a problem.

  179. Zash

    jonasw: Not the thing where data goes into a buffer that the network stack isn't paying attention to?

  180. jonasw

    back in the days of google code

  181. jonasw

    not sure, I think it was some limit thing

  182. Zash


  183. dwd has left

  184. dwd has left

  185. uc has joined

  186. goffi has left

  187. dwd has left

  188. dwd has left

  189. Flow has joined

  190. dwd has left

  191. vanitasvitae has joined

  192. dwd has left

  193. winfried has joined

  194. Zash

    Hey, how do browsers deal with namespaces?

  195. Zash

    Like, if I stupidly insert some random XML tree into my DOM, and there's like a <p xmlns="not xhtml" onclick="evil();"> in there, what happens?

  196. jonasw

    Zash, horribly

  197. jonasw

    they don’t care a lot

  198. jonasw

    and as always, it depends

  199. Zash

    So a thing that sanitizes the xhtml-im namespace but lets anything else thorugh would be useless?

  200. jonasw

    I can imagine that this kind of stuff works because it is hared between XML and SVG handling

  201. jonasw


  202. jonasw

    I wouldn’t rely on it

  203. jonasw

    there are funny bugs in browsers with prefixes, too

  204. moparisthebest has joined

  205. uc has left

  206. dwd has left

  207. ralphm has joined

  208. winfried has joined

  209. tux has joined

  210. la|r|ma has joined

  211. stefandxm has left

  212. ralphm has left

  213. lskdjf has joined

  214. stefandxm has joined

  215. Ge0rG has left

  216. Ge0rG has left

  217. Steve Kille has left

  218. nyco has left

  219. jubalh has joined

  220. ralphm has left

  221. Steve Kille has joined

  222. tux has joined

  223. ThurahT has left

  224. ThurahT has joined

  225. jonasw

    Kev, +1 to your XHTML-IM mail

  226. jonasw

    you brought to the point what I tried to convey in a few paragraphs of prose elsewhere.

  227. Kev

    I don't have the attention span to write TL;DR mails :)

  228. Ge0rG

    Ha, I tried to make the same point yesterday.

  229. Ge0rG

    Let's see if different framings are going to convince the public

  230. jonasw

    itym the council.

  231. zinid

    guys, what is the agreement on pubsub in push?

  232. goffi has joined

  233. Kev

    I don't think the move towards something markdownish is actually stupid, FWIW, and I think it's much much easier to sanitise something that you can write your own parser/serialiser for, than XHTML-IM. So I don't think this is a bad direction. It is much easier for diligent devs to get it right. I'm just not sure I buy the argument that it's going to suddenly make anyone who wants to dump things into a DOM unsanitised safe.

  234. Ge0rG

    I like markdown, but it's impossible to write a parser for that.

  235. jonasw

    I agree with Ge0rG

  236. jonasw

    writing your own markdown parser is a mess, and will yield 1000 different implementations

  237. jonasw

    (this holds for all text-based markups, I’m afraid)

  238. Ge0rG

    It's even less possible to sanitize markdown.

  239. Kev

    Well, we can go with a binary markup if you want, and then base64 it to get it into the stream, but I don't think it helps :p

  240. Kev preempts Dave suggesting ASN.1 encoding of markup.

  241. Guus has joined

  242. Ge0rG

    Kev: it's already impossible to write correct markdown _text_, which is rendered in the same way everywhere. How are you going to write a parser?

  243. jonasw

    Kev, I sense buffer overflows there.

  244. Zash

    This is the appropriate reaction: https://pics.zash.se/4c840479.jpeg

  245. jonasw

    using an XML-based markup makes much more sense to me.

  246. Steve Kille has left

  247. Kev

    Ge0rG: That isn't the hard part. Tedious, but not hard, we just need to spec it. And by 'we', I mean that dwd has volunteered, so yay.

  248. zinid

    where to vote for asn.1? :)

  249. Ge0rG

    BER or DER?

  250. jonasw

    hasn’t BER failed?

  251. Zash

    Is server-side cleaning of xhtml-im sane, or would that just let broken clients be broken and then get hacked by evil servers?

  252. Zash


  253. Ge0rG

    Zash: yes.

  254. Kev

    Abstract Syntax Notation 71.

  255. jonasw

    from what I’ve heard, the general sentiment is that clients need to trust the server anyways to some extent...

  256. Zash

    Yes, trust the server, the server is good.

  257. jonasw

    but I guess it’d break e2ee

  258. Zash

    E2EE is just marketing fluff, did't we establish that?

  259. zinid

    jonasw: +1, I can't understand what's the point in building client-server architecture where there is no trust to server?

  260. jonasw

    Zash, I won’t get into that argument.

  261. zinid

    better off using p2p directly

  262. jonasw

    I’m torn on the e2ee thing. I don’t want certain stuff I discuss with people plaintext on my server in some MAM.

  263. jonasw

    zinid, p2p doesn’t scale

  264. Zash

    p2p doesn't scale *on mobile*

  265. zinid

    jonasw: I wouldn't say that, there are some research going on

  266. Ge0rG

    I really don't get why people hate ASN.1

  267. zinid

    Ge0rG: because it generates lots of boilerplate code for mainstream languages such as C++ or Java

  268. zinid

    for example, in Erlang it's great

  269. jonasw

    not rather because ~every ASN.1 parser is broken somehow?

  270. Steve Kille has left

  271. zinid

    jonasw: but we have PKIX working?

  272. Steve Kille has joined

  273. jonasw

    sure, take a look how secure the PKIX libraries are

  274. Ge0rG

    Every browser contains an ASN.1 decoder. We could leverage that and replace JSON, once and for all.

  275. Zash

    Ge0rG: Call it "binary JSON with schemas and namespaces"

  276. Zash

    Make a fancy website on whatever is the hip TLD today.

  277. Ge0rG

    Zash: yeah, marketing is crucial.

  278. Ge0rG


  279. zinid

    jonasw: I think that's the problem of the language you're using

  280. jonasw

    zinid, excellent, let’s ignore issues because they only occur in a single language.

  281. jonasw

    then we can stay with XHTML-IM, because javascript/DOM is the actual issue.

  282. zinid

    jonasw: well, we ignore? and what do we have as a result?

  283. zinid

    ASN.1 was a standard and now there are tons of implementation with 0 interop

  284. edhelas

    the XHTML-IM problem can be extended to Pubsub as well, with the usage of Atom

  285. dwd

    Kev, I volunteered to document a "snippets" design, which - I think - covers most of the use cases outside of *bold* /italic/ _underline_ and `preformat`.

  286. Ge0rG

    maybe we need a subset of ASN.1 that is easy to understand and to implement. Let's call it ASN.0. Or maybe ASNdown.

  287. zinid

    Ge0rG: I would rather use protobuff, frankly

  288. zinid

    but it's not a standard

  289. dwd

    zinid, FWIW, I've not come across any of these incompatible ASN.1 implementations, and I've used many of them.

  290. Kev

    dwd: I had completely misunderstood, I thought you'd volunteered to write the thing that's like markdown spec, sorry.

  291. dwd

    zinid, After all, when I worked at Isode, M-Link had about 6 in the code.

  292. edhelas

    but I'd say, maybe we can just add modules on servers to checkup the content of messages when they detect the xhtml-im namespace

  293. edhelas

    it's basically applying a schema and check if it fits

  294. dwd

    Kev, I can probably do that too. But I have a pair of XEPs and a I-D in my pipeline, and adding another one is pushing things enough. (Oh, and I'm trying to shepherd Ash through updateing '314 *and* writing another).

  295. zinid

    dwd: well I'm not talking about incompatible implementations, I think jonasw said that :)

  296. dwd

    edhelas, Really? So I can strip tables then?

  297. jonasw

    zinid, nope, I did not mention incompatibilities.

  298. dwd

    zinid, Then I misunderstood: [09:47:59] ‎zinid‎: ASN.1 was a standard and now there are tons of implementation with 0 interop

  299. zinid

    dwd: I mean there are now: thrift, protobuff, several json serializers, etc

  300. Ge0rG

    but those are all not ASN.1?

  301. zinid

    yes, but they do the same

  302. zinid

    encode/decode lang structures into/from wire format

  303. Ge0rG

    It's funny how SQL injection is still a thing in 2017. And XSS.

  304. Guus has left

  305. Guus has joined

  306. Kev

    When I keep talking about markdownish, to be clear, I'm talking about something that is clearly and comprehensively specced, presumably by us. I am not suggesting it's ok to say "use markdown", and then just have everyone pick their own, subtly incompatible, library.

  307. uc has joined

  308. dwd has left

  309. Ge0rG

    Kev: I'm not sure that makes a difference. If it is sufficiently similar to markdown, people will just plug their own markdown library in and end up wth full HTML support.

  310. Alex has joined

  311. Kev

    Ge0rG: I'd really like the discussion to move away from "People will do what's easy, not what the spec says", and instead try to work out how to have a spec that a reasonable person is likely to implement without significant issue. XHTML-IM, as it stands right now, is not the latter thing.

  312. la|r|ma has joined

  313. jonasw

    Kev, I’d like your opinion on a (possibly audited) JS reference implementation of a sanitiser.

  314. Kev

    I think it's a different question to whether XHTML-IM is sane. I don't think "It's near impossible to get right, but we've already done it, so use our implementation (or port it)" is the right thing to do.

  315. Kev

    If we get to the stage that we *do* have a sane spec, then a reference implementation could be helpful, but at that point is also probably not as necessary.

  316. jonasw

    I think that XHTML-IM is easy to get right, once we drop @style.

  317. jonasw

    (you’re gonna have the problem of sanitizing URLs in any markup which supports URLs)

  318. Ge0rG

    Kev: I'm not sure that it's actually possible for a reasonable person to implement a secure web application.

  319. zinid

    I'm lost, what is required to be sanitized? URLs?

  320. Ge0rG

    Kev: and I think that XHTML-IM is mostly a strawman here.

  321. zinid

    xhtml-im doesn't define scripting, so there should no be XSS, no? (I'm not a web developer)

  322. Ge0rG

    zinid: the problem is that it's insanely hard to sanitize user-controlled strings in a web application. And even more so if those strings contain HTML markup.

  323. Ge0rG

    zinid: change your nickname to `<script src=.../>` and there is a good chance some client will actually load and execute that.

  324. zinid

    I know about web application, but this is mostly due to script execution

  325. winfried has joined

  326. zinid

    yes, your example is also about scripting :)

  327. Ge0rG

    zinid: yes, but there are so many ways to include scripts.

  328. Ge0rG

    and developers need to know and filter them all.

  329. zinid

    but xmpp client should not execute scripts?

  330. Ge0rG

    zinid: should not, no. but if the client is running in the browser, the browser well might do

  331. zinid


  332. jonasw

    zinid, the fact that XHTML-IM doesn’t define scripting does not prevent (a) maliciuos entities to include <script>...</script> and (b) stupid clients to embed the XHTML from the message unsanitised into the browsers DOM

  333. zinid

    jonasw: yes, got it

  334. zinid

    but don't we have the same problem with markdown? how is markdown processed? web clients can pretty much insert <script/> from markdown into DOM as well

  335. zinid

    and the same for raw messages (i.e. <body/>)

  336. Ge0rG

    zinid: that's a very valid point, made multiple times by now.

  337. zinid

    ah, ok

  338. zinid

    sorry, TL;DR :D

  339. Ge0rG

    yeah, that is a common problem :>

  340. dwd has left

  341. uc has joined

  342. pep.

    Ge0rG> Kev: I'm not sure that it's actually possible for a reasonable person to implement a secure web application. < +1

  343. tux has joined

  344. pep.

    "Markdown is not HTML so people will have to write their own parser" what? (*me just read the ml thread*)

  345. pep.

    Or rather, people can't drop that into innerHTML. Don't worry they'll find ways

  346. Ge0rG

    I mean: I'm a professional IT security specialist, and I don't know all the ways that you can inject code into a web app from user input.

  347. pep.

    I'm not even sure how to contribute to that thread. People hear "We need to deprecate XHTML-IM" and already it's "I know $NEW_FANCY_MARKUP that we can use". We're just going in circles.

  348. pep.

    Kev> Ge0rG: I'd really like the discussion to move away from "People will do what's easy, not what the spec says" < That's exactly what's happening at the moment with XHTML-IM.

  349. pep.

    And that's what sam is ranting about

  350. pep.

    If it their implementation were compliant there would be no such issue. (Or we could fix the XEP to answer these issues)

  351. Syndace

    Can you deprecate a XEP, modify it and then make it draft again?

  352. pep.

    If it their implementation was compliant there would be no such issue. (Or we could fix the XEP to answer these issues)

  353. pep.

    Under a different name/number? dunno. That would be silly anyway

  354. pep.

    Might as well reinstate the original XEP

  355. Syndace

    No under same name and number

  356. mathieui

    Syndace, https://xmpp.org/extensions/xep-0001.html#approval-std

  357. Syndace

    Okay thanks

  358. pep.

    Anybody can post to standards@ right?

  359. Steve Kille has left

  360. mimi89999 has joined

  361. jubalh has joined

  362. uc has joined

  363. jonasw

    pep., must be subscribed, but subscription is open

  364. pep.

    I get the emails, so I did that iirc

  365. jonasw

    your mail got through

  366. jonasw

    the list has some delay, in the order of a few minutes

  367. pep.

    Yeah I saw it/them come back :)

  368. pep.

    Yeah I saw it/them go through :)

  369. pep.

    Why do my first emails have to be hate mails :(

  370. jonasw

    it’s not hate, it’s constructive discussion (for now)

  371. Kev


  372. pep.

    https://www.mail-archive.com/standards@xmpp.org/msg17919.html I like goffi's position here

  373. Kev

    Wasn't the first of those mails "We have to consider people who ignore the spec" and the second mail "Changing the spec will fix it"?

  374. Kev

    I think as long as your position involves the "stupid people" argument, there is no way to find a solution to injecting markup, but there is certainly no way for xhtml-im markup.

  375. pep.

    I'm not of the opinion that changing the spec would fix the issue. It might help a bit

  376. Kev

    Jonas said we should change the spec, you said you strongly agree...

  377. jonasw

    sure, because @style is hard to validate right. everything else can be done.

  378. pep.

    Well, that would help yes.

  379. jonasw

    (even @style can be done, but I don’t think we should be asking people to do that)

  380. pep.

    Kev, also look at my second sentence. "the issue is not here"

  381. Kev

    jonasw: Yes, and that's fine if you agree with my premise that we should be catering to people who want to do the right thing, not to people who ignore the spec and inject HTML directly. If you want to go along with my premise there, then changing the sanitisation rules can help. But if you're on the premise that people will ignore the spec, no amount of changing the spec will help with that.

  382. jonasw

    Kev, I still believe that a working reference implementation will help against people ignoring the spec.

  383. jonasw

    (and a reference implementation would benefit from getting rid of @style, which is my argument there)

  384. Syndace

    I don't even think in a open source environment you have to care about stupid people. If you stumple across an implementation that allows for XSS you open an issue and point them to the reference sanitizer and everything is fine.

  385. Syndace

    If someone writes new client code for fun that only he and his friends use then whatever

  386. jonasw

    I prefer to try to prevent security issues before they happen.

  387. Syndace

    Yeah sure

  388. Kev

    jonasw: I think you're agreeing with my argument, and disagreeing with pep's, that we should be making this easy for people who want to do the right thing.

  389. jonasw

    yes, we definitely agree on that.

  390. jonasw

    I don’t agree that inventing our own markup will help with that.

  391. pep.

    Kev, but the issue at hand is people not doing things right, am I wrong?

  392. jonasw

    it will just open another can of worms, be it security issues or interop issues.

  393. jonasw

    (or probably a mix of both)

  394. Alex

    server plugins could strip out java script and other malicious tags

  395. jonasw

    Alex, that has been proposed, and Zash even drafted an implementation of that for prosody.

  396. jonasw

    I don’t feel that clients should rely on that in any way.

  397. Kev

    Alex: I'm not convinced by that argument, really.

  398. jonasw

    (but it’d be an interesting tool to detect malicious parties)

  399. Alex

    I have done this before, the XHTML XEP lists the allowed tags, any other tag I ignored in the parser

  400. pep.

    Kev, if it's to make things more straightforward for people who follow the spec, I'm all in, and I agree with jonasw. But that's not how I read SamWhited's email.

  401. jonasw

    I also firmly believe that obsoleting XHTML-IM without a replacement which has deployment will achieve nothing, except closing a door for us on fixing things there. See Private XML support.

  402. Alex

    jonasw: agreed on that

  403. Alex

    we really need modern markup to compete with Slack and others these days

  404. jonasw

    I will implement XHTML-IM in my client over the next weeks, no matter the XEP status.

  405. jonasw

    simply to gain interoperability

  406. Alex

    othereise its a step backwards

  407. jonasw

    and I assume that others will do the same

  408. jonasw

    and if they don’t then we’ll end up with a bunch of incompatible tacked-on markups

  409. jonasw

    e.g. clients (not people!) putting markdown in <body/>

  410. jonasw

    (we already have that to some extent with clients interpreting *foo* and /bar/ and such)

  411. pep.

    I see *foo*, _bar_ etc. as historical, coming from IRC. Not sure where IRC got that first though

  412. jonasw

    pep., agreed

  413. jonasw

    even though there are clients which interpret ">", which I haven’t seen used much in IRC except in the last few years.

  414. pep.

    Right, they're all implementing their own markup, using <body>, which is meh

  415. jonasw

    much meh

  416. pep.

    I often rage against Conversations translating ">" at the beginning of a message. It breaks stuff like "><", and messages with a single ">" don't make sense anymore (got this case on prosody@ the other day)

  417. pep.

    I often rage against Conversations converting ">" at the beginning of a message. It breaks stuff like "><", and messages with a single ">" don't make sense anymore (got this case on prosody@ the other day)

  418. Holger

    >< works though.

  419. dwd has left

  420. zinid

    Alex: > we really need modern markup to compete with Slack and others these days Do we really want to compete? I just doubt that this is the goal of XSF

  421. pep.

    Ah it works now indeed. I haven'T checked in a while

  422. dwd

    zinid, I think we should be competitive with things like Slack, yes.

  423. Alex

    zinid: I see many people switching to Slack these days. There is no reason why you can do the same with XMPP. But we lack of modern client and features these days

  424. pep.

    Alex, I think we have most tools to start implementing. I would rather wait and see if UAs ask for more

  425. jonasw has left

  426. pep.

    Maybe push them to implement such things if you really want

  427. zinid

    dwd: only like Slack? really, what userbase do XSF target? because from what I see currently it's producing specs for nerds (like e2ee)

  428. dwd

    zinid, Well, not only like Slack. And I don't entirely disagree with your assertions there.

  429. dwd

    zinid, ALthough not all nerds focus on the threat model that OMEMO does.

  430. pep.

    zinid, I think most nerds have their own servers, and e2ee is possibly of less important there

  431. pep.

    But I don't disagree with your assertions either :)

  432. zinid

    I just think maybe it's better to define the target userbase?

  433. zinid

    I mean if this is nerds, then I'm fine and we should go in this direction

  434. zinid

    I don't think we can produce a protocol for every person on the planet

  435. dwd

    zinid, Scalability would be an issue, for sure.

  436. Zash has left

  437. Alex

    the strenght of XMPP was the we always covered a huge variety of use cases an users

  438. pep.

    zinid, protocol maybe, but for the end-users I don't think the protocol really matters anyway.

  439. zinid

    dwd: yes, but if we try to resolve scalability issues we will end up with SIP :)

  440. pep.

    Or rather, for *most end-users, non-tech that is

  441. zinid

    there is sip p2p rfc already

  442. dwd

    zinid, Oh, I do hope not.

  443. zinid

    dwd: well, if you strip shit from sip, it's usable and can be used as building block

  444. Zash

    zinid: the one that also works for xmpp?

  445. jubalh has joined

  446. zinid

    hehe, ok, I didn't want to go into SIP vs XMPP debate :)

  447. dwd

    zinid, That's not a debate, it's a bloodbath. ;-)

  448. dwd

    zinid, But anyway, I think we have a set of existing target communities, and I agree that defining these would be of benefit to us as protocol designers - however you implied there can only be one, which I think I take issue with.

  449. jere has joined

  450. Alex

    the target communities also changed over the last 10+ years. I like this discussion of defining it

  451. zinid

    dwd: well, their can be several, but I don't think "regular user" class intersects a lot with "nerds" class (intersection is a very basic functionality)

  452. zinid

    I mean, take a look: 1) a girl spending most of the time in instagram and so on 2) a nerd who lives with console

  453. zinid

    how can we target both?

  454. dwd

    zinid, I think the amount of intersection between the sets is actually something we'd need to find out. I suspect it's not nearly as small as you might think.

  455. zinid

    maybe, would be great to understand though at least for making the priorities

  456. Alex

    extensions, give teh nerd a console client without XHTML, and the girl a client where she can like messages, have hundreds of emoticons and share images and glyphys

  457. zinid

    Alex: sounds great in theory, but does it work in practice?

  458. Zash

    Jack of all trades

  459. Alex

    yes it does, I am doing XMPP stuff for close to 15 years now, and have customers which do all that with XMPP with great sucess

  460. Zash

    It does show that a bunch of us are more or less doing stuff for ourselves. Nothing wrong with that.

  461. Holger

    Zash: Nothing wrong with targetting ourselves if we clarify that. Then I can give up trying to sell XMPP to others and then having to explain why stuff breaks.

  462. Zash

    Optimally we'd get instagramming teens into software and standards development

  463. zinid

    nothing wrong of course, the problem I have is that we constantly speak about how to fight with Slack without even defining the target

  464. Zash

    And if the target is everything then it's a lot of work

  465. zinid

    yes, 300+ XEPs for sure :)

  466. zinid

    yet another 300 I mean :)

  467. Alex

    I think case studies and small tutorials on our webpages would help

  468. Zash

    Only? Gotta break that initial zero ;)

  469. Holger

    I think it's a vicious circle. XMPP's niche is mostly nerds, so there's few other users complaining about our stuff, so we concentrate on the nerd stuff because that's more fun to implement.

  470. Zash

    Holger: Typical in most FOSS circles

  471. Alex

    you wanna build something liek Slack, hey this iw what you need, extensions A+B+C+D you wanna build a military grade client, then this is what you need, extensions X+Y+Z

  472. Zash

    Alex: Sounds good

  473. zinid

    Holger: +1

  474. Holger

    Zash: Yes but elsewhere there target audience is more obvious.

  475. Holger


  476. dwd

    Alex, In my experience, the Military and similar markets actually want something Slack-like anyway.

  477. Holger

    Zash: If you build a tiling window manager, you won't break stuff for non-geeks.

  478. Alex

    you wanna build something like whats app do that you wanna build machine 2 amchien communications do this you need build a system for realtime stick exchange do this you wanna build the next Uber (geoLoc) to that

  479. dwd

    Alex, I mean, they want labelling, sure, but don't think they don't care about emoji support.

  480. Holger

    And a large part of FOSS projects is building server/infrastructure stuff ...

  481. Ge0rG

    Alex: that sounds like a compliance suite.

  482. zinid

    Alex: ok, let me rephrase maybe: who will write the XEPs for Slack audience? Hell, does anyone even know what Slack audience want? :)

  483. Alex

    I suck at typing today, so need a client which supports XEP-0308 :-)

  484. dwd

    zinid, I've used Slack, and I can tell you that Slack themselves don't have a clue.

  485. Ge0rG

    there is a commercial market for corporate (or government) slack-like things self-hosted with data retention, archival, LDAP integration and other enterprisey requirements.

  486. zinid

    we can start doing this, but we will eventually end up working on JET and OMEMO :D

  487. zinid

    dwd: yes, maybe :)

  488. Ge0rG

    zinid: we don't need to target the nerd audience. They will come to us voluntarily.

  489. zinid

    Ge0rG: but we do this

  490. zinid

    JET and OMEMO for whom?

  491. zinid

    a girl from instagram never heard about e2e

  492. Alex

    Ge0rG: yes, we had a compliance suite before at the XSF for servers and client, but somehow died

  493. Ge0rG

    IMO, there are two target groups we should focus on, five years ago: - Slack-like on-premise / hosted services with a good web and mobile UX - slightly nerdy normal users (see Conversations' success)

  494. Ge0rG

    Alex: the current one is defining "mobile" and "IM" use cases. I'm pretty sure that "Slack" would make a good "Multimedia Chat" one or somesuch

  495. Ge0rG

    Alex: actually, there is not much specification missing to pull off a Slack-like thing, it's only a lack of dev power to make a proper web client and a one-button easy-deployment server.

  496. Ge0rG

    okay, web client _and_ mobile client

  497. Ge0rG

    Give me a dozen competent developers, a year and a time machine so I can start in 2012, and I can pull it off.

  498. dwd

    Ge0rG, Actually, Openfire has the latter, for sure. You can install webchat clients just by push-button after Openfire itself is installed.

  499. Ge0rG

    dwd: will Openfire come with AD/LDAP integration and all the Enterprisey checklist features?

  500. dwd

    Ge0rG, It has had AD integration for a decade or something.

  501. Ge0rG

    And will it scale to (tens) thousands of users?

  502. dwd

    Ge0rG, It doesn't scale as well as some servers. Chokes around 20k users or so, I think, until you do clustering.

  503. edhelas

    what about ejabberd ?

  504. dwd

    edhelas, I think that has LDAP integration, I don't know about Active Directory SSO (ie, GSSAPI).

  505. zinid

    edhelas: https://blog.process-one.net/ejabberd-massive-scalability-1node-2-million-concurrent-users/

  506. Ge0rG

    dwd: is it possible to buy an Openfire appliance / virtual machine with around-the-clock tech support?

  507. zinid


  508. Ge0rG

    dwd: but we are getting off-topic here.

  509. Ge0rG

    There is a German startup, selling enterprise mobile messaging <https://www.teamwire.eu/> - they provide cloud-hosted and on-premise solutions, and ask something like 3€/month/user for a WhatsApp-like experience. And they don't even have federation.

  510. Alex

    zinid: there is hosted.im if you need that

  511. Ge0rG

    But they have a sustainable business for something like five years now.

  512. dwd

    Ge0rG, Sure. We do have a dearth of clients running on Apple-favloured systems.

  513. Ge0rG

    The problem is: nobody will buy an XMPP-based IM solution if the UI isn't Slack-like

  514. zinid

    Alex: me? :) now, thanks, I have my own domain

  515. Ge0rG

    dwd: business clients running openfire on Apple? Or XMPP clients running on macOS?

  516. Ge0rG

    or iOS?

  517. edhelas

    Ge0rG what is "slack like" for you ?

  518. zinid

    damn, last time I checked slack I didn't understand what its buzz is about

  519. dwd

    Ge0rG, Yes.

  520. Ge0rG

    edhelas: easy to use private messages, channels, markup, some integration with websites / web services

  521. dwd

    zinid, It introduces millenials to IRC.

  522. Ge0rG

    edhelas: synchronization across all devices. proper push notifications

  523. valo has joined

  524. dwd

    zinid, That is, pretty much, it. It's IRC with emojis and working file sharing.

  525. Ge0rG

    I actually like Slack. It's easy to use.

  526. zinid

    dwd: then what is a problem to build slack-like using existing XEPs? am I missing something?

  527. Ge0rG

    zinid: lack of developers

  528. dwd

    zinid, No, we're not missing much to build something Slack-like, but federating and with security.

  529. edhelas

    I already have a couple of Movim users that deployed it in their business on top of a XMPP server

  530. edhelas

    you add some bots to integrate with github/jira and you're good no ?

  531. dwd

    I do think that our absolute neutrality does handicap us from showcasing good clients, which in turn reduces the appeal of the platform as a whole.

  532. zinid

    Ge0rG: that's true

  533. zinid

    dwd: so the problem is nobody wants to use XMPP for their apps, ok, we go in circles now :)

  534. dwd

    zinid, Well, sorta. I think people look at the first client or two they see and assume that the UX they encounter is due to restrictions in XMPP.

  535. Alex

    GitHubs Gitter is another example, also getting quite popular these days

  536. Ge0rG

    dwd [13:46]: > I do think that our absolute neutrality does handicap us from showcasing good clients, which in turn reduces the appeal of the platform as a whole. Very sad, and very true.

  537. edhelas

    I was thinking of creating a page that showcase those "good clients" actually

  538. edhelas

    if it's a project that is not officially pushed by the XSF, it could work no ?

  539. zinid

    what good clients? I still use Tkabber...

  540. zinid

    conversations maybe

  541. dwd

    zinid, Nerd. :-P

  542. edhelas

    zinid Dino looks very promissing

  543. zinid

    dwd: but what to use? swift lacks of features, dino is crashing, gajim is buggy (tracebacks are the friends)

  544. dwd

    zinid, I wonder if - and I know this sounds silly - the XSF should have an awards thing for Best XMPP Client for XYZ Platform, etc? Would that help highlight and motivate?

  545. zinid

    dwd: no, Durov puts 1M$/month in telegram for instance, I think other major IM players do the same

  546. zinid

    so if the price will be 1M$ then maybe :)

  547. zinid


  548. jubalh has left

  549. jubalh has joined

  550. jubalh has left

  551. jubalh has joined

  552. Ge0rG

    You don't need that much for developing a client or two

  553. mimi89999 has joined

  554. zinid

    Ge0rG: yes, I understand the most of the money goes into adv, but still there is a lot of guys working on a client

  555. jonasw

    dwd, awards are not so cool

  556. jonasw

    the issue with awards is that only one wins

  557. jonasw

    or let me put it this way: it would require well thought out terms for people to participate

  558. jonasw

    also I’m afraid it might just re-enforce already well-funded (in which way ever) clients

  559. lumi has joined

  560. Ge0rG

    dwd: we really need to revive the Jabber Software Foundation

  561. Alex

    putting good software projects under an umbrella like Apache does could help

  562. Alex

    Ge0rG: same idea :-)

  563. pep.

    edhelas, arguably there is no good clients, it's all shapes of bad :)

  564. Alex

    Pandion was this client for windows in the early days of Jabber/XMPP

  565. Zash has left

  566. dwd has left

  567. zinid

    Ge0rG: what will JSF do?

  568. pep.

    marketing? promotion of clients? and the XSF do standards? (wild guess)

  569. zinid

    marketing = $$$

  570. dwd has left

  571. Alex

    $$$ could be raised easily, when there is good software

  572. Zash

    Alex: wrong, when there is good marketing

  573. zinid

    Alex: no

  574. Alex

    Zash: both

  575. Kev

    OK. I have a strong position on XSF Neutrality, because I don't see a way to do things fairly. So perhaps it'd help to persuade people like me that the XSF can do this stuff if someone came up with a concrete proposal of how the XSF could do recommended clients/servers etc., and do it fairly.

  576. zinid

    Alex: tons of Conversations user don't even pay for it

  577. jubalh has left

  578. Alex

    zinid: its not easy, but doable

  579. jubalh has joined

  580. valo has joined

  581. dwd has left

  582. dwd has left

  583. dwd has left

  584. edhelas has left

  585. nyco has left

  586. edhelas has joined

  587. matlag has left

  588. jonasw has left

  589. winfried has joined

  590. dwd has left

  591. emxp has left

  592. jubalh has left

  593. dwd has left

  594. stefandxm has left

  595. stefandxm has joined

  596. jere has left

  597. jere has joined

  598. Guus has left

  599. intosi has joined

  600. jere has left

  601. jere has joined

  602. Guus has joined

  603. alacer has joined

  604. winfried has joined

  605. Alex has left

  606. SamWhited

    Catching up… fwiw, I don't have a "position" that we should do markdown that likes like plain text in <body>. I have a position that we should deprecate XHTML-IM and then we should take the time top write a good replacement considering the pros and cons of both approaches. Tentatively I suspect that doing it in the body makes sense, but I'm not pushing for that.

  607. alacer has left

  608. SamWhited

    Similarly, this started because I've tried an XHTML-IM impl that was broken … again. So it's hardly a strawman for "other xss'". If I thought other xss' were caused by a poor spec, I would probably try to obsolete that too.

  609. alacer has joined

  610. SamWhited

    Alex: we have a council vote to advance them next week! https://xmpp.org/extensions/xep-0387.html

  611. SamWhited

    Or already did and it's waiting on list votes, I forget.

  612. jonasw

    SamWhited, good luck trying to obsolete .innerHTML and others :)

  613. Kev

    I think Council just approved an LC on 387, and so vote to advance should be the week after, shouldn't it?

  614. SamWhited

    jonasw: exactly, that's why I'm focusing on xhtml-im instead :)

  615. jonasw

    I think the LC needs to be announced properly on the ML first

  616. jonasw

    some editor should do that *cough*

  617. SamWhited

    Ah yah, that sounds tight

  618. SamWhited

    Right, even

  619. jonasw

    I can see if I can get around to do that this weekend

  620. Kev

    Oh, right. The two weeks don't start until that's announced.

  621. Zash

    SamWhited: How is "The Web" handling that? Because it's not just XMPP clients having that problem, right?

  622. emxp has joined

  623. SamWhited

    Zash: by not sending raw html around and trusting that developers can implement a white list properly or will do so at all.

  624. jonasw

    Zash, have you looked at the web? it’s injections everywhere.

  625. Zash

    I looked at the web recently. It said "It is inherently impossible to make a secure web thing."

  626. dwd has left

  627. SamWhited

    I assumed we were talking about transmitting formatting over instant messages, but yes, generally it's injections everywhere. I just still fail to see what other problems that aren't xhtml-im have to do with xhtml-im.

  628. dwd has left

  629. Zash

    I'm thinking, what are other standards orgs or such doing about equivalent injection issues?

  630. Zash

    I'm assuming here that there's some overlap between xhtml-im and web apps

  631. SamWhited

    Ah, yah… good idea, someone else must do this.

  632. Zash

    More like "has someone done something already that we can steal?"

  633. pep.

    SamWhited, for me deprecating xhtml-im is just delaying the same kind of issues with another more or less similar XEP. You're complaining about a range of UAs that are either 1. not following the XEP, 2. Not doing their job correctly. I don't think you can't fix 1., and if you see 2. please report it. If you do and and still get no reply, then I don't think we can't do anything either.

  634. pep.

    Replacing XHTML-IM won't fix this

  635. Zash

    The XMPP thing to do is to turn it into XML on the wire. But people will fail at that, whatever we do.

  636. SamWhited

    pep.: it won't fix that, you're right. I am not arguing that a new thing will make developers never have any security issues ever again.

  637. pep.


  638. SamWhited

    I am arguing that I have never seen an xhtmlim impl that worked the first time and that it is especially easy to get wrong. We *can* make something where the default naive implementation does not commonly lead to badness.

  639. SamWhited

    This is the best you can do in any security issue.

  640. dwd has left

  641. mathieui

    SamWhited, would bringing up the poezio xhtmlim impl be trollong?

  642. mathieui

    SamWhited, would bringing up the poezio xhtmlim impl be trolling?

  643. pep.

    goffi also has an implementation iirc

  644. jonasw

    doesn’t movim have XHTML-IM support?

  645. pep.


  646. SamWhited

    mathieui: sorry, I didn't include it here because phone, but yes, on the emails I think I specifically said "web based"

  647. SamWhited


  648. jonasw

    I thought they talked about that (at least partial support, I think they strip @style, but maybe I’m confusing things)

  649. mathieui

    that makes sense, np

  650. pep.

    SamWhited, libervia is a web client.

  651. mathieui

    and everything that brings in a webview in a client application too

  652. pep.

    jonasw, no, edhelas doesn't want xhtml-im for some reason

  653. SamWhited

    Right, "things that actually have a javascript engine"

  654. SamWhited

    Getting of the bus… may be slow to respond.

  655. pep.

    SamWhited, also please don't merge markup in <body> :(

  656. SamWhited

    Off… I hate phones.

  657. jonasw

    who doesn’t

  658. Flow has joined

  659. winfried has joined

  660. lovetox has joined

  661. SamWhited

    I give up. Why does everyone think I want to push an alternative format? I will probably volunteer to write one if xhtml-im gets deprecated, but I am not pushing for markdown or whatever in body. I haven't done any research yet.

  662. jonasw

    I personally do not think that, but we are going to need an alternative, and the alternatives all look bad.

  663. Flow has joined

  664. Ge0rG

    We won't improve our situation by deprecating XHTML-IM without an alternative, and I still don't believe we will be able to come up with an idiot-proof alternative.

  665. Kev

    And if we're not striving for idiot-proof, we should assess whether XHTML-IM can be suitably improved.

  666. Zash

    If you do, the universe will spawn a better idiot.

  667. Zash

    Having an official safe JS reference implementation does sound somewhat promising tho.

  668. Zash

    And and a bigger better security considerations section

  669. Kev

    And blacklisting style.

  670. Flow has joined

  671. Zash

    What about the teends that crave colorful messages?

  672. Alex has joined

  673. Zash

    Bunch of predefined classes?

  674. Kev

    If we allow style, I'm not at all sure how even a reasonably diligent implementor avoids issues.

  675. Zash

    Instead of <span style="color:red">, there would be <span class="fg-red">

  676. jonasw

    classes seem like not a good idea either

  677. jonasw


  678. jonasw

    it needs sanitization at least

  679. jonasw

    to avoid that some attacker abusse your clients classes

  680. Zash

    Do they?

  681. Zash


  682. jonasw

    but they’re much easier to sanitise than @style

  683. jonasw

    (split by " ", make a set, check that only things starting with xhtml-im- are in there or so)

  684. jonasw

    alternatively (but Sam will shoot me for that), xhtml-im:color="..."

  685. Zash


  686. jonasw

    why not?

  687. jonasw

    (hm, still needs sanitisation to prevent injection attacks)

  688. jonasw

    so using @class and defining a set of classes seems most safe for now

  689. mathieui shoots jonasw

  690. Ge0rG

    we should only allow one value for color, which is an integer between `0` and `359` on the XEP-0392 color wheel.

  691. stefandxm has left

  692. SamWhited

    Amusingly, I just sent a short reply to one of Kev's messages that included the example: *&lt;script&gt;alert(123)&lt;script;&gt;* and FastMail rendered that as bold.

  693. Zash

    Why not hold a public poll where people can suggest names for them

  694. Zash

    SamWhited: /nick <script>alert("everyhing is broken");</script>

  695. Zash

    Especially my typing

  696. Ge0rG

    what happens if you add unquoted HTML to the <body> text?

  697. lumi has left

  698. Zash

    What happens when you encrypt unquoted HTML in OTR?

  699. jonasw

    Ge0rG, you mean, like, <body><b>foo</b></body>?

  700. Zash

    Interesting how <b> isn't in xhtml-im

  701. lumi has joined

  702. jonasw


  703. pep.

    Zash, jonasw, reference implementation, and tests also maybe

  704. pep.

    Although I'd like to have more than just JS, because it's not just a web issue and it's not just an xhtml-im issue

  705. pep.

    Basically we need a reference client? :)

  706. mathieui

    16:20:06 Zash> What happens when you encrypt unquoted HTML in OTR? → let’s not talk about OTR

  707. Zash

    jonasw: IIRC <b> was added back into html because nobody cares about semantics

  708. efrit has joined

  709. Zash

    And nobody is going to fix all the web that uses it

  710. Ge0rG

    jonasw: yeah

  711. alacer has joined

  712. alacer has joined

  713. jonasw

    Ge0rG: depends; web clients might joyfully let themselves being XSSed

  714. jonasw has left

  715. mathieui

    but they do even without xhtml-im

  716. jere has left

  717. jere has joined

  718. SamWhited

    > but they do even without xhtml-im I still can't figure out what the argument is there. Other XSS's aren't related to XHTML-IM… what point are people trying to make when they say that "there are other XSS's too"? If it's obvious to everyone else I apologize, but I'm honestly asking. There is some implied ending to that statement that I don't understand.

  719. Syndace has left

  720. pep.

    That XHTML-IM is not the issue, there's a deeper issue

  721. SamWhited

    Yes, XSS is a deeper issue, but you can't fix XSS on the web. You can not recommend a spec that actively encourages them though.

  722. SamWhited

    Is that what people are suggesting though? XSS is the underlying issue so there's no point in trying to prevent a subset of them?

  723. alacer has joined

  724. alacer has joined

  725. pep.

    You can try and improve XEPs all you want, that won't prevent clients from having bugs. I agree XHTML-IM could be improved to try and make people aware of it, but in the end it's mostly reporting bugs to clients

  726. SamWhited

    You won't prevent it, but you can certainly make it less likely that those bugs are catastrophic security issues.

  727. jonasw has left

  728. pep.

    Do you have specific examples of these issues btw? And I suppose you also reported them

  729. jonasw has left

  730. SamWhited

    Yes, I reported them. I won't go into the most recent one because it's not fixed yet as far as I know, but literally *every* XHTML-IM impl I've tried that was tied to an environment where JavaScript could be executed was either vulnerable at first, or had been vulnerable in the past (there was a CVE or issue about it or something)

  731. SamWhited

    HipChat for instance tried to do things right, but had a handful of bugs in their whitelisting (and I'm sure you could easily find more).

  732. SamWhited

    With XHTML-IM almost *any* simple bug leads to a security issue. We can absolutely write a spec where not every single simple logic issue allows a script to be executed.

  733. Guus has left

  734. sonny has joined

  735. sonny has left

  736. sonny has joined

  737. sonny has left

  738. sonny has joined

  739. sonny has left

  740. sonny has joined

  741. tux has joined

  742. stefandxm has joined

  743. dwd

    SamWhited, Quite. The problem with XHTML-IM is that the obvious implementation is the most dangerous one, and insatead you more or less have to add an HTML protocol break in to make it safe.

  744. dwd

    SamWhited, In fact, edhelas suggested doing so in the server (and I thought of doing so in Metre), but the problem there is that XHTML-IM is often silently extended anyway.

  745. SamWhited

    dwd: Indeed. HipChat in theory does things right on the client (whitelist of elements and attributes, don't stick things straight into the DOM), *and* it has server side filtering. Despite that I've found at least two injections in that implementation (both of which are fixed now).

  746. jonasw

    what’s an "HTML protocol break"?

  747. sonny has joined

  748. alacer has joined

  749. tux has left

  750. jubalh has joined

  751. Kev has left

  752. Zash

    jonasw: <bold> mebbe

  753. Zash

    Or markdown

  754. Valerian has joined

  755. dwd

    jonasw, A protocol break is a security programming technique where you extract out the information into a different, fixed, form and then reconstitute it entirely from scratch. Means that, in our case, a bit of Javascript has no place in the intermediate form so cannot pass through.

  756. Zash

    dwd: And is that even possible while still being XML?

  757. dwd

    Zash, No, you wouldn't do it with XML, you'd do it with something else. Real protocol breaks would break up all the XMPP traffic into an intermediate form (JSON, maybe) and ship it across a wire to the other side, which then puts it back together. Obviously that's a little overkill for XHTML-IM.

  758. jonasw

    You’re saying we can’t use XML for markup, at all.

  759. alacer has joined

  760. Zash

    jonasw: Yes. But we should, but we can't. Nice things and unavailability

  761. jonasw

    That’s depressing.

  762. waqas has joined

  763. pep.

    Who ever thought web clients would be a good thing :x

  764. efrit has left

  765. SamWhited

    What is the advantage to doing an XML based markup? I'm not convinced that we can't do it, but I do think a non-XML based thing (which I'm assuming means "in the <body>") has a few nice advantages (single source of truth, better fallback behavior, etc.)

  766. dwd

    jonasw, No, I'm not. Just that you can't copy it direct to output without very havey mangling.

  767. dwd

    jonasw, And the level of safety we're talking about in the mangling negates the advantage of it being XML in the first place, IMO.

  768. jere has joined

  769. alacer has joined

  770. intosi has joined

  771. Zash

    dwd: people will find a way to lazily search and replace that lets trough evil stuff

  772. dwd

    jonasw, I mean, two XMPP servers talking across a heavily secured boundary have all their traffic mangled out, and then back into, XML. It's not the XML itself that's the problem, it's that you cannot do a direct copy and guarantee safety.

  773. jonasw

    SamWhited, whatever we do, not in <body/>.

  774. waqas

    I agree with everything SamWhited said. Not a single client that I reviewed has gotten xhtml-im secure.

  775. SamWhited

    jonasw: what is the advantage of not doing it in the <body/>

  776. jonasw

    dwd, so, I like your HTML protocol break argument. Indeed, based on that argumentation, I think a something-not-XML-based-but-still-structural representation of the semantics of XHTML-IM would make sense.

  777. Zash

    <body type='html'>&lt;script....

  778. SamWhited

    thanks waqas; you're running for council next term right?

  779. jonasw

    SamWhited, doing it in the body ties us to poor plaintext-ish markups like Markdown, Creole or reStructuredText. Those are not extensible, the implementations often vary or are poor in other ways and such.

  780. waqas

    As part of my research I'd written a library that implements XHTML-IM protcol break: https://github.com/zeen/xhtml-im.js — it makes an XML DOM to an HTML DOM with a strict whitelist of elements, attributes and possible attribute values.

  781. Zash

    The xep talks about rtf. Do that

  782. stefandxm has left

  783. jonasw

    waqas: :-O

  784. waqas

    I need to npm-ify it, to make it easier to use and add docs.

  785. jonasw

    waqas, that sounds like the reference implementation I wanted to see in XEP-0071 which everybody can use.

  786. SamWhited

    Ooh nifty, that's nice to have, thanks

  787. Zash

    So, let's pay for an audit?

  788. SamWhited

    actually I forgot, I think you sent this to me and challenged me to break it a while back and I never did.

  789. SamWhited

    never tried, I mean.

  790. jonasw

    waqas, except that I think it also gets the "replace invalid tags with their children thing" wrong

  791. jonasw

    (i.e. doesn’t implement it)

  792. Zash

    jonasw: let's kill that plz

  793. waqas

    It discards anything invalid first and foremost

  794. waqas

    i.e., it avoids all positives, but may have false-positives for certain attribute values

  795. waqas

    And the unknown element case

  796. jonasw

    Zash, I think it’s a nice-to-have for extensibility.

  797. jonasw

    (but I see how it’s hard to implement in anything which isn’t XSLT)

  798. dwd has left

  799. Zash

    jonasw: you can extend the <message>, it's probably safer

  800. jonasw

    Zash, how’d you extend <message/> with HTML-<video/> elements?

  801. SamWhited

    jonasw: why is a plain text protocol not extensible? If I want to add /italics/ later, what is stopping me?

  802. SamWhited

    for that matter, why are "plaintext-ish markups" poor?

  803. dwd

    SamWhited, It still amuses me that the word italics in your message is rendered in italics for me.

  804. jonasw

    SamWhited, that clients which don’t know that /italics/ is italics won’t escape it

  805. SamWhited

    See, there we go, it works already!

  806. Zash

    Let's talk about /etc/foobar/

  807. SamWhited

    jonasw: Right, and we have a lovely fallback behavior, they still see the exact same message it just looks like someone added /emphasis/ in a different way

  808. waqas

    Extensibility is a secondary concern, that we should be thoughtful about. Security is the primary concern. I'm not sure the 'include the children' approach is always correct in HTML.

  809. pep.

    Zash, :D

  810. jonasw

    so my /path/to/some/file will render italics on your new client supporting italics even though it shouldn’t

  811. dwd

    Zash, Not italics.

  812. SamWhited

    Zash: Yah, I don't know about the specifics of using /, just an example.

  813. jonasw

    SamWhited, it’ll work for anything

  814. Syndace has left

  815. pep.


  816. SamWhited

    *sigh* so pick a different character, it was an example.

  817. dwd

    So /this is italics/ but yet /etc/passwd is not.

  818. dwd has left

  819. jonasw

    SamWhited, I challenge you, which one which doesn’t look super odd when seen without support?

  820. dwd

    I mean, right now, in Gajim, this is the actual case.

  821. waqas

    dwd: Machine learning!

  822. jonasw

    dwd, what if I want to have only a part of a word in italics?

  823. SamWhited

    jonasw: That doesn't look odd to me, _emphasis_, /emphasis/, and *emphasis* all look relatively nice.

  824. dwd has left

  825. SamWhited

    we're diving into specifics that don't matter though. The question is "why isn't it extensible" which you argued was a problem. Implementation details are not relavant at this point.

  826. dwd

    SamWhited, And they all worked in Gajim. They show the markup, mind, as well as the effect. But they work.

  827. Flow has joined

  828. jonasw

    SamWhited, but that’s exactly why it isn’t extensible.

  829. SamWhited

    dwd: Oh that's interesting, I've noticed a few web things (not IM) that keep showing the markup and the effect recently and liked it, I wanted to try it in an IM client. Didn't realize gajim already did it.

  830. jonasw

    You are re-defining things which previously were normal characters as meta-characters when extending it.

  831. jonasw

    That simply breaks, always.

  832. jonasw

    anyways, I gotta go for now.

  833. jonasw has left

  834. SamWhited

    jonasw: ahh, I see. That's fair.

  835. SamWhited

    I still think it doesn't matter as far as deprecating XHTML-IM, mind. The security concern comes first like waqas said.

  836. SamWhited

    But it's a fair argument if we're discussing alternatives.

  837. Steve Kille has left

  838. SamWhited

    A fair argument that I would love to consider in parallel to deprecating XHTML-IM ;)

  839. pep.

    So you're going to deprecate XHTML-IM, to then try and find a replacement, that is possibly just XHTML-IM 2.0.

  840. Zash

    XHTML-IM 2.0, now 200% more security considerations

  841. pep.


  842. SamWhited

    pep. yes. I certainly hope we don't come up with something that's just as bad, but we *know* XHTML-IM causes problems, it has been for years, so let's stop recommending new implementations of it. Keep in mind that people will still implement it for compatibility, and all existing implementations won't go away. It just means we don't advertise it as the way to do things.

  843. jonasw

    SamWhited, thanks for seeing my point, that has driven me crazy ;-)

  844. pep.

    So that doesn't find things at all, deprecating it. Fixing the XEP might be a better option?

  845. Guus has left

  846. pep.

    So that doesn't fix things at all, deprecating it. Fixing the XEP might be a better option?

  847. SamWhited

    pep. we can't fix it without a rewrite, the basic idea is fundamentally broken.

  848. pep.

    If there is anything to fix

  849. jonasw

    SamWhited, given the arguments from dwd about protocol breaks and such, I agree that we should do other things. at this point, I’m in favour of something like some simple JSON-based markup or so.

  850. SamWhited

    At least, I don't think we can, if you have a proposal I'd love to be proven wrong.

  851. jonasw

    but I’m out of the discussion for now, I’ll write a list to standards@

  852. SamWhited

    jonasw: thanks, I look forward to reading it.

  853. Flow has joined

  854. pep.

    SamWhited, no I don't see how what you want to fix can be fixed, and I don't know if we have to worry about this to then come up with something as bad

  855. SamWhited

    I don't think we'll come up with something as bad. I'm reasonably sure most of us understand the problem.

  856. dwd

    Zash, Incidentally, `/etc/passwd` works in most IM-based Markdown variants as an escape pattern that also switches to monospaced "code" layout. But not in Gajim.

  857. pep.

    dwd, that doesn't change jonasw's point

  858. pep.

    And I agree with him

  859. pep.

    If you want to do something else please don't use <body>

  860. Zash

    dwd: Markdown is a html superset. You are doomed.

  861. dwd

    pep., Oh, I'm somewhat open either way, there.

  862. SamWhited

    I wonder if there's a middle ground, body and a hint about the type of markdown being supported. <body>this is *bold*!</body><formatting version="0.2"/>

  863. alacer has joined

  864. dwd

    Zash, I'm not proposing using *full* markdown. That would indeed be insane - nobody needs headers and things in IM messages.

  865. pep.

    SamWhited, so you'd include all different versions?

  866. SamWhited

    pep. you'd just give a hint about what the version of the spec was, then the client could implement all or nothing depending on if it understands the version attribute. I'm not sure this is a good idea mind, just spit balling.

  867. mimi89999 has left

  868. Zash

    dwd: markdown libs are going to pass through html by default

  869. Zash

    Same problem

  870. Zash

    SamWhited: I have this vague feeling that I've seen that proposal before

  871. SamWhited

    Like dwd, I'm rather open to either thing though. I do have a vague sense that doing it in body fixes a lot of little problems, but it has the downside that jonasw pointed out. I'm not sure which is the best tradeoff.

  872. dwd

    Zash, Well, I'm not actually sure most of them do, anymore. And in any case, there are loads of cut-down ones. But I'm merely hinting at a direction rather than wanting to compare it with XHTML-IM. It is, as SamWhited says, more a matter of agreeing we need to deprecate XHTML-IM and wondering what the functionality might be replaced with.

  873. pep.

    SamWhited, right. I don't think this fixes the issue. If the client doesn't handle *foo*, it'll leave the markup here, which is meh, and for each new version you'll just be defining more and more new meta-characters that weren't before. I'm not sure that addresses our issue

  874. pep.

    (As you just said ^)

  875. Valerian has left

  876. SamWhited

    I'm pretty okay with leaving the markup there; it may not be ideal, but it's a better fallback behavior than XHTML-IM right now (where the message just doesn't show up if you don't also include a plaintext body, eg. most HipChat extensions)

  877. pep.

    Well then HipChat is not compliant?

  878. pep.

    They should follow the XEP

  879. dwd

    pep., Do you seriously think that anyone using any Internet-based communications medium for the past two decades would be surprised to see *bold* things expressed as such?

  880. pep.

    dwd, not us no, but I'm pretty sure you don't want to target only us nerds with this

  881. SamWhited

    I'm pretty sure that everybody would understand *emphasis*.

  882. dwd

    pep., No, not just us. Any Twitter user, for example. Probably any Facebook user too.

  883. pep.

    Also, you will never be able to have any breaking change

  884. Zash

    Should it be about styling or semantics ? ?

  885. pep.

    I'd prefer it to be semantics

  886. pep.

    But I suppose Slack or Facebook users don't care

  887. mimi89999 has left

  888. SamWhited

    That's an interesting distinction. I think a replacement should just deal with text styling. If you want an image you have sims or something, and the client can decide if and how it wants to display that (maybe with an information XEP about displaying media in clients for guidance).

  889. SamWhited

    and the XML-based SIMS or OOB or whatever gives the client the semantic meaning of whatever the non-text resource is.

  890. Ge0rG has left

  891. Ge0rG has left

  892. Zash has left

  893. Valerian has joined

  894. alacer has joined

  895. mimi89999 has left

  896. uc has left

  897. uc has left

  898. mimi89999 has left

  899. mimi89999 has joined

  900. uc has joined

  901. intosi has joined

  902. ralphm has left

  903. mimi89999 has left

  904. uc has left

  905. mimi89999 has left

  906. mimi89999 has joined

  907. uc has joined

  908. Zash

    Someone mentioned push and publish-options being invalid?

  909. Zash

    https://xmpp.org/extensions/xep-0223.html#example-1 has the same issue?

  910. zinid

    Zash: yes, #persist_items is not registered within XEP-0060

  911. zinid

    only #access_model is registered

  912. Kev has left

  913. stefandxm has joined

  914. Zash


  915. sonny has joined

  916. zinid

    ah, right :)

  917. zinid

    even more

  918. Zash

    Maybe one should do a `grep publish-options xeps/xep-????.xml`

  919. zinid

    sure, PRs are welcome, I'm told

  920. zinid

    but it seems like we just copy attributes from #node_config to #publish-options

  921. zinid

    what's the point? why not using #node_config data form directly?

  922. Zash

    It seems like at the time, people thought that was what it was

  923. Zash

    Like how you can create+configure a node in a single step, but this would be publish+configure (and maybe autocreate)

  924. Zash

    Seems like it'd be weird if you have many clients disagreeing on the options

  925. dwd has left

  926. valo has joined

  927. Flow has left

  928. stefandxm has left

  929. dwd has left

  930. emxp has joined

  931. Zash

    Oh look at what fun issue I'm having. My xep-0071.epub had unescaped HTML like <body/> passed through, breaking things.

  932. zinid

    irony :D

  933. Ge0rG has left

  934. Ge0rG has left

  935. mathieui

    Zash, nice

  936. Zash

    > The root element for including XHTML content within XMPP stanzas is > > .

  937. Zash

    Good job pandoc

  938. Zash

    > The raw HTML is passed through unchanged in HTML, [bunch of formats], EPUB, Markdown, [even more]

  939. Zash

    Maybe I should just generate JSON. That'll solve all problems.

  940. Zash


  941. Flow has joined

  942. winfried has joined

  943. Ge0rG has joined

  944. mimi89999 has left

  945. Steve Kille has joined

  946. dwd

    Zash, Just looks like smiley faces to me.

  947. Zash

    dwd: Please don't use JSON as a markup language. Altho maybe that's the reason it's the only choice.

  948. Steve Kille has left

  949. Steve Kille has joined

  950. dwd

    Zash, I wasn't going to suggest JSON at all.

  951. dwd has left

  952. uc has joined

  953. Guus has left

  954. Flow has left

  955. dwd has left

  956. Guus has left

  957. dwd has left

  958. efrit has joined

  959. Steve Kille has left

  960. dwd has left

  961. Steve Kille has joined

  962. Alex has left

  963. Alex has joined

  964. Alex has left

  965. ralphm has left

  966. Alex has joined

  967. Alex has left

  968. stefandxm has joined

  969. Alex has joined

  970. Alex has left

  971. Zash

    Forget about XHTML-IM and markdown, let's do this https://www.oasis-open.org/committees/download.php/60/HM.Primary-Base-Spec-1.0.html

  972. jubalh has joined

  973. Steve Kille has left

  974. edhelas has left

  975. edhelas has joined

  976. SamWhited

    Embedded SVG, but the version of the spec that didn't end up making it through where it had functionality to open sockets.

  977. SamWhited


  978. Valerian has left

  979. Valerian has joined

  980. alacer has joined

  981. efrit has left

  982. stefandxm has left

  983. Valerian has left

  984. Valerian has joined

  985. stefandxm has joined

  986. jubalh has joined

  987. Tobias has joined

  988. dwd has left

  989. Steve Kille has joined

  990. dwd has left

  991. jubalh has left

  992. emxp has joined

  993. Flow has joined

  994. valo has joined

  995. jubalh has joined

  996. valo has joined

  997. Flow has left

  998. Steve Kille has left

  999. dwd has left

  1000. dwd has left

  1001. dwd has left

  1002. emxp has joined

  1003. SamWhited has left

  1004. dwd has left

  1005. alacer has left

  1006. alacer has joined

  1007. ralphm has joined

  1008. emxp has joined

  1009. Syndace has left

  1010. alacer has left

  1011. alacer has joined

  1012. Valerian has left

  1013. valo has joined

  1014. alacer has left

  1015. Steve Kille has joined

  1016. jubalh has joined

  1017. goffi has left

  1018. alacer has joined

  1019. Steve Kille has left

  1020. uc has joined

  1021. ralphm has left

  1022. zinid has left

  1023. Syndace

    I really don't get why all examples of XEP-0030: Service Discovery error responses contain the query element mirrored from the request. To me it is as confusing as it looks useless. If a client does not support disco at all it won't know that it has to mirror the query element anyway, so why is it mirrored in all examples and do I really have to mirror it in my implementation? I did not find a MUST or REQUIRED about this in the specification. Do people mirror it? Do people rely on it to exist in error stanzas?

  1024. Zash

    Syndace: I believe that's technically allowed by the specifications, but rarely used.

  1025. zinid

    It's useful for debugging sometimes

  1026. Syndace

    Zash: So, I can ignore it as being historical? Is there any reason it might be helpfull that I'm missing?

  1027. Syndace

    zinid, okay I can see that, it's easier than matching ids of outgoing and incoming iqs.

  1028. zinid

    I mean when you dump xml on server: you see what exactly your server is replying to with error

  1029. zinid

    Syndace: but there is no requirement in the RFC

  1030. Syndace

    Okay got it, thanks :)

  1031. Valerian has joined

  1032. jubalh has joined

  1033. alacer has joined

  1034. jubalh has joined

  1035. Flow has joined

  1036. dwd has left

  1037. edhelas has left

  1038. alacer has joined

  1039. Alex has joined

  1040. dwd has left

  1041. edhelas has left

  1042. edhelas has joined

  1043. edhelas has left

  1044. edhelas has joined

  1045. edhelas has left

  1046. edhelas has joined

  1047. Kev has left

  1048. edhelas has left

  1049. edhelas has joined

  1050. edhelas has left

  1051. edhelas has joined

  1052. edhelas has left

  1053. edhelas has joined

  1054. Ge0rG has left

  1055. alacer has joined

  1056. alacer has joined

  1057. Syndace has left

  1058. Flow has joined

  1059. Ge0rG has left

  1060. alacer has left

  1061. daniel has joined

  1062. Ge0rG has left

  1063. alacer has joined

  1064. lovetox has left

  1065. waqas has left

  1066. daniel has left

  1067. emxp has left

  1068. emxp has joined

  1069. Ge0rG has left

  1070. jubalh has left

  1071. winfried has joined

  1072. Ge0rG has left

  1073. emxp has left

  1074. emxp has joined

  1075. efrit has joined

  1076. Syndace has left

  1077. daniel has joined

  1078. SamWhited has left

  1079. daniel has left

  1080. daniel has joined

  1081. Valerian has left

  1082. Valerian has joined

  1083. alacer has joined

  1084. Ge0rG has left

  1085. alacer has joined

  1086. Alex has left

  1087. Tobias has left

  1088. Tobias has joined

  1089. Guus has left

  1090. Zash has left

  1091. sonny has joined

  1092. Valerian has left

  1093. emxp has joined

  1094. Ge0rG has left

  1095. emxp has joined

  1096. Syndace has joined

  1097. jere has joined

  1098. jere has joined

  1099. dwd has left

  1100. Syndace has joined

  1101. Ge0rG has left

  1102. Valerian has joined

  1103. Ge0rG has left

  1104. daniel has left

  1105. alacer has joined

  1106. alacer has joined