XSF Discussion - 2017-10-12

  1. uc has joined
  2. Ge0rG has left
  3. Ge0rG has left
  4. Tobias has joined
  5. uc has left
  6. stefandxm has left
  7. lskdjf has joined
  8. Tobias has joined
  9. matlag has joined
  10. Valerian has left
  11. Zash has left
  12. Tobias has joined
  13. Zash has joined
  14. some1namednate has joined
  15. some1namednate has left
  16. some1namednate has joined
  17. some1namednate has left
  18. xnyhps has left
  19. uc has joined
  20. Zash has left
  21. Zash has joined
  22. sonny has left
  23. sonny has joined
  24. sonny has left
  25. sonny has joined
  26. uc has joined
  27. daniel has joined
  28. alacer has joined
  29. daniel has left
  30. daniel has joined
  31. daniel has left
  32. daniel has joined
  33. moparisthebest has left
  34. stefandxm has joined
  35. alacer has joined
  36. lskdjf has joined
  37. dwd has left
  38. stefandxm has left
  39. dwd has left
  40. daniel has left
  41. alacer has left
  42. Guus has left
  43. Guus has joined
  44. jere has left
  45. alacer has joined
  46. mimi89999 has joined
  47. alacer has left
  48. Valerian has joined
  49. intosi has joined
  50. alacer has joined
  51. Guus has left
  52. Guus has joined
  53. tux has joined
  54. tux has joined
  55. stefandxm has joined
  56. daniel has joined
  57. Guus has left
  58. Guus has joined
  59. uc has joined
  60. uc has left
  61. stefandxm has left
  62. zinid has left
  63. zinid has joined
  64. alacer has joined
  65. Tobias has joined
  66. alacer has joined
  67. Guus has left
  68. Guus has joined
  69. alacer has left
  70. Valerian has left
  71. Valerian has joined
  72. Valerian has left
  73. intosi has left
  74. alacer has joined
  75. McKael has left
  76. Lance has joined
  77. Lance has left
  78. Tobias has joined
  79. SamWhited has left
  80. Guus has left
  81. Guus has joined
  82. Guus has left
  83. Guus has joined
  84. stefandxm has joined
  85. uc has joined
  86. stefandxm has left
  87. ralphm has left
  88. emxp has joined
  89. jubalh has joined
  90. Tobias has joined
  91. jubalh has left
  92. jubalh has joined
  93. McKael has joined
  94. xnyhps has left
  95. jere has joined
  96. dwd has left
  97. stefandxm has joined
  98. Flow has joined
  99. jonasw has joined
  100. mimi89999 has joined
  101. lumi has left
  102. uc has joined
  103. dwd has left
  104. dwd has left
  105. Flow jonasw, +1 for your XHTML-IM mail on standards@
  106. Valerian has joined
  107. Valerian has left
  108. jonasw thanks
  109. Ge0rG has left
  110. alacer has joined
  111. dwd has left
  112. stefandxm has left
  113. Flow has left
  114. goffi has joined
  115. ralphm has joined
  116. dwd has left
  117. alacer has joined
  118. dwd has left
  119. Tobias has joined
  120. edhelas SamWhited I just saw your mail, kind of agree with it, but be careful as XHTML-IM is also bound to other XEPs
  121. edhelas https://xmpp.org/extensions/xep-0231.html#referencing for example
  122. edhelas Movim doesn't handle XHTML-IM except for this use case where a BOB image (actually a "sticker") in Movim is sent
  123. jonasw oh, so there’s Yet-Another-XEP where images can be "attached" to posts.
  124. jonasw (in addition to OOB and SIMS)
  125. edhelas yeah but OOB descript a transfer method
  126. edhelas *describe
  127. edhelas sorry, BOB describe a transfer method
  128. jonasw indeed
  129. edhelas OOB and SIMS are just metadata
  130. jonasw yeah
  131. edhelas actually Movim support OOB, BOB and SIMS :D
  132. edhelas i'd like to deprecate OOB
  133. jonasw in favourof SIMS?
  134. edhelas yup
  135. jonasw I agree.
  136. edhelas https://github.com/siacs/Conversations/issues/2637
  137. jonasw hae
  138. jonasw daniel, did you misread that issue? I don’t see edhelas mentioning BOB in the issue, but you’re referencing it. Am I missing something there?
  139. pep. jonasw: I'd like to see solutions like you suggested indeed, instead of deprecating xhtml-im
  140. jonasw voice yourself on the ML :)
  141. jonasw has left
  142. pep. Will do
  143. jonasw and thanks
  144. pep. What/how/who would write that reference impl. though? XSF itself doesn't do that kind of stuff right?
  145. zinid reference implementation of what?
  146. Ge0rG has left
  147. jonasw pep., I wouldn’t say that
  148. jonasw there are RFCs which contain a reference implementation (e.g. the Opus Codec)
  149. jonasw so I don’t see any strict reason against that
  150. jonasw ideally someone from the web development part among the XSF members (looking in the general direction of the movim people) who know JS etc. would take a shot. even more ideally, the XSF would fund a proper audit.
  151. pep. zinid: xhtml-im thread on standards@
  152. zinid ah
  153. jonasw alternatively we could take a look at existing web clients wich get this right, but it appears that there are none :)
  154. zinid not interested :)
  155. jonasw afk for a while
  156. pep. jonasw: right. I would love to see movim implement that at some point
  157. pep. Much better than parsing random /commands and still sending that as text
  158. pep. But I guess that's the extent of what's possible without that xep
  159. Ge0rG has left
  160. Zash has left
  161. edhelas I choose to not implement XHTML-IM actually, it's also to keep the UI clean
  162. edhelas and it's heavy to cleanup/process XHTML messages on the volume
  163. pep. Xhtml-im* messages
  164. Ge0rG I'm absolutely in love with poezio's /code plugin.
  165. zinid https://xmpp.org/extensions/xep-0223.html -- is it implemented anywhere?
  166. pep. Yep it's really nice. And it doesn't pollute people's screen when they don't do xhtml-im
  167. jonasw Ge0rG, /code is annoying in the sense that the sender chooses the colours; they may not fit with the recipients background for examle
  168. uc has joined
  169. edhelas zinid used in Movim for the bookmarks and other things
  170. edhelas Ge0rG I'm also handling /code in Movim :)
  171. zinid edhelas: and how to deal with clients who don't support it?
  172. zinid edhelas: the same thing we did with avatars: nothing? :)
  173. edhelas zinid for bookmarks ? well I don't
  174. edhelas Movim is actually not in sync with Conversations regarding bookmarks
  175. zinid and you think it's ok? :)
  176. pep. edhelas: not the same way as poezio does. You leave the /code in your body :/
  177. edhelas because I choose to not use the old prive-xml XEP
  178. pep. And it doesn't make sense on any other clieny
  179. pep. Client
  180. edhelas pep. poezio put colors on the code using xhtml-im ?
  181. pep. Yes
  182. edhelas ouch
  183. pep. Why?
  184. edhelas then no, because it will look ugly
  185. pep. Why?
  186. edhelas well movim has its own color palette and so
  187. edhelas I don't want you to impose your pink and green colors in the Movim UI
  188. pep. Sadness
  189. edhelas also I can easily colorize the code myself, a simple lib on Movim side can take care of it
  190. jonasw edhelas, allowing XHTML-Im but filtering @style seems like a reasonable thing to do
  191. jonasw you need to know that it’s code though. XHTML-IM does not allow for a <code/> tag
  192. pep. edhelas: also, you're still polluting the body with /code
  193. edhelas then XHTML-IM is not a solution for it
  194. jonasw edhelas, itym then XHTML-IM should be extended ;-)
  195. edhelas pep. I agree as well for /code, we also have /me (even if there's a XEP yeah)
  196. jonasw thinks that the handling of /me is fine.
  197. edhelas why ?
  198. edhelas having a proper XML tag would be way better
  199. pep. jonasw: handling of it is fine in implementations, but it come directly from IRC
  200. edhelas <self-quote/>
  201. pep. And I agree with edhelas here
  202. Ge0rG has left
  203. jonasw yes, it would be better. but it works today, and breaking that would break a lot of clients for little gain
  204. edhelas if you don't like /code I understand, but let's be consistent
  205. jonasw /code is a client-side feature
  206. jonasw the "/code" is never transmitted
  207. pep. edhelas: history is never really consistent though. :/
  208. pep. Also it's not just about /code
  209. vanitasvitae has left
  210. edhelas but in general I'm against clients that are forcing the rendering of content to another client
  211. pep. It's also about all other possibilities that you're missing without xhtml-im. Or that you (somebody) are trying to reproduce badly
  212. edhelas this also applies to Atom publications in Pubsub, actually Movim is heavily filtering the XHTML tags to remove all the style and customization of the articles
  213. Ge0rG jonasw: I think that XHTML-IM 2.0 colors should be limited in the same way that the Colors XEP works. The sender defines the hue, and the displaying client is responsible for brightness and saturatio
  214. Ge0rG +n
  215. pep. edhelas: you should probably detail this statement, I'm sending you messages forcing you to display them. (Unless you ignore them)
  216. edhelas I'm ignoring xhtml-im
  217. edhelas only use the body tag
  218. edhelas XMPP is a transport protocol, like HTTP is transporting HTML
  219. pep. Ge0rG: that sounds nice
  220. edhelas the forating rules of HTML/CSS/JS is another playground
  221. edhelas *formating
  222. edhelas to XMPP can tell me if a message contains code, like HTTP tell me if an answer contains text or images
  223. edhelas but doesn't tell me how to format thoses
  224. jonasw Ge0rG, +1
  225. pep. Well xhtml-im doesn't, you choose
  226. jonasw I thought about that when I wrote my reply, but I think that’s another battle.
  227. pep. edhelas: it's all about semantics
  228. Ge0rG jonasw: yeah. But that should work on most neutral backgrounds, and with non-neutral backgrounds the displying client has the option to tune the curves accordingly.
  229. pep. XHTML is, really
  230. jonasw Ge0rG, yap
  231. jonasw pep., +1, which is why I feel we should keep XHTML-Im
  232. pep. edhelas: which is why, for example, the /code movim leaves in the body is meaningless to me, I don't know what to do with it if I don't use movim
  233. pep. (I agree that the xep could be extended)
  234. edhelas sure
  235. vanitasvitae has joined
  236. jonasw edhelas, re bookmarks and movim, does movim use publish-options or otherwise require that the node is configured correctly or would it publish the bookmarks for everyone to read if the pubsub service doesn’t support the correct access model?
  237. edhelas jonasw it set the configuration of the node on the first start
  238. edhelas set on whitelist actually
  239. Ge0rG has left
  240. jonasw mhm
  241. lskdjf has joined
  242. edhelas same for other nodes like avatar, vcard4, geoloc, microblog and subscriptions, with their own config
  243. la|r|ma has joined
  244. Zash has joined
  245. Ge0rG has left
  246. stefandxm has joined
  247. nyco has left
  248. stefandxm has left
  249. Alex has joined
  250. Ge0rG has left
  251. Flow has joined
  252. zinid has left
  253. uc has joined
  254. jubalh has joined
  255. Ge0rG has left
  256. Flow has left
  257. Flow has joined
  258. dwd has left
  259. dwd has left
  260. alacer has joined
  261. dwd has left
  262. dwd has left
  263. Guus has left
  264. dwd has left
  265. Guus has joined
  266. alacer has joined
  267. dwd has left
  268. Tobias has left
  269. Ge0rG has left
  270. dwd has left
  271. Guus has left
  272. dwd has left
  273. Guus has joined
  274. dwd has left
  275. Ge0rG has left
  276. jubalh has joined
  277. blabla has joined
  278. valo has joined
  279. Guus has left
  280. Ge0rG has left
  281. ralphm has joined
  282. dwd has left
  283. Tobias has left
  284. Ge0rG has left
  285. blabla has left
  286. dwd has left
  287. valo has joined
  288. Ge0rG has left
  289. stefandxm has joined
  290. Ge0rG has left
  291. Holger XEP-0357 says that the app can include arbitrary payload for the app server using <publish-options/>. XEP-0060 says that a "pubsub service advertising support for publishing options MUST reject publications with unknown fields." So I can't use a standard PubSub service to implement an app server, right?
  292. jonasw depends
  293. jonasw is "unknown fields" qualified in the XEP?
  294. valo has joined
  295. jonasw otherwise, one could argue that the app server understands those proprietary XEP—0357 fields
  296. Kev I'm not convinced that pubsub is actually the right mechanism for this anyway.
  297. Holger I'm ranting against the PubSub syntax for push notifications since forever :-)
  298. Holger It should just use a plain message.
  299. Holger jonasw: "Fields and their behaviour MUST be registered with the XMPP Registrar." -- https://xmpp.org/extensions/xep-0060.html#publisher-publish-options
  300. jonasw Holger, aww
  301. MattJ That's a silly requirement
  302. MattJ Like saying you MUST use standards
  303. jonasw kind of
  304. Holger MattJ: No it lets clients rely on behavior.
  305. Holger MattJ: Publish options are being used to make sure a node is not world-readable, for example.
  306. ralphm has left
  307. dwd has left
  308. MattJ Yes, rejecting unknown fields makes sense
  309. MattJ But requiring that every field MUST be registered I'm less sure of
  310. Holger If you guys are just saying that a non-standard service may accept the 0357 options then that's what I'm saying.
  311. dwd has left
  312. zinid MattJ: if it's not registered, then how to federate?
  313. Holger You can't use a standard service but must build your own PubSub thing to create an app server.
  314. Holger I think you must do so anyway if you actually need to parse those custom options (such as the secret).
  315. MattJ A non-standard service is a non-standard service and doesn't need to follow a MUST in a standard, because it's non-standard
  316. Holger So basically I'm back to "don't use PubSub syntax".
  317. dwd has left
  318. MattJ zinid, there are cases where federation is not a concern
  319. Holger MattJ: Right. So we shouldn't change the standard to also standardize non-standard behavior.
  320. zinid MattJ: ok, but in that case you don't give a damn whether there is MUST or not
  321. Holger Exactly.
  322. Holger <MattJ> Like saying you MUST use standards
  323. Holger 0060 doesn't do that.
  324. Holger It just says "if you follow 0060 and announce publish-options support, you must behave as defined". This only works if only registered options are supported.
  325. dwd has left
  326. dwd has left
  327. Holger I.e. if you reject options that aren't registered.
  328. zinid > Like saying you MUST use standards I think it's like "you MUST use standards to federate/interop"
  329. dwd has left
  330. MattJ Yes, to federate/interop you generally must use standards
  331. MattJ But this is a case where you don't, right? :)
  332. Syndace has joined
  333. Ge0rG If people don't bother to use standards, they won't bother more if the standards write that you MUST use standards.
  334. Holger MattJ: The idea is that you could use a standard PubSub service.
  335. zinid right, so Holger is right: we shouldn't use pubsub for this
  336. Holger MattJ: ... and have the app server subscribe to that.
  337. dwd has left
  338. Holger MattJ: That PubSub service would be a federating/interoperating 0060 service.
  339. Holger MattJ: At least that's how Lance argued back when I argued against PubSub :-)
  340. MattJ If the thing doing the publishing knows that the thing accepting the publish supports a certain option in a certain way, it doesn't matter if it's an XSF-blessed standard, is what I'm saying
  341. zinid why do we need so complex pubsub, it's kinda relay, what for?
  342. Ge0rG has left
  343. zinid I mean why would an app server subscribe to it instead of directly receiving stanzas?
  344. Holger MattJ: I'm talking about "the thing accepting the publish".
  345. MattJ which has to understand the options, no?
  346. Holger MattJ: Lance said he's using PubSub to make it possible for a standard publish service to be that thing.
  347. Holger MattJ: I'm saying this won't work.
  348. MattJ Example option?
  349. Holger MattJ: Yes. The thing has to understand non-standard options.
  350. Holger 'secret'
  351. MattJ Is this something you made up for your implementation, or is it in the XEP?
  352. Holger MattJ: Example 13 in XEP-0357.
  353. Holger MattJ: It's just an example. 0357 says I may include arbitrary options. 0060 says a standard PubSub service MUST reject them.
  354. dwd has left
  355. MattJ Well a simple solution is to register the option ;)
  356. dwd has left
  357. Holger No.
  358. Holger You want to allow for arbitrary options.
  359. Holger ChatSecure uses some other stuff.
  360. Steve Kille has left
  361. MattJ I still don't see a problem
  362. Holger MattJ: As you said this is really just communication between the app and the non-standard app server.
  363. MattJ So, you're using an off-the-shelf pubsub service
  364. Holger MattJ: So it just makes no sense to use PubSub for this.
  365. MattJ and it doesn't understand your custom option, but what is it meant to do with it?
  366. Holger MattJ: That's the next problem, which is why I'm saying this won't work anyway :-)
  367. zinid MattJ: but you need to patch the server in order to accept options in order to be passed them to the app server
  368. Holger The node subscriber won't see the option.
  369. MattJ Right
  370. Holger MattJ: In practice the problem is that people try to build an app server on top of the existing PubSub code, because that's what the XEP suggests.
  371. Steve Kille has joined
  372. Holger MattJ: Then I tell them that this isn't possible because it just looks similar to PubSub but is slightly non-standard.
  373. MattJ Ok, I see better now
  374. MattJ You're complaining as an XMPP server developer, not as an app server developer
  375. Holger Well.
  376. zinid what's the difference? :)
  377. Holger Sure my immediate issue is that I want to get rid of the support requests :-) But I think the app server developer will also appreciate not running into the problem.
  378. MattJ Sure
  379. dwd has left
  380. Holger As I said I think the proper fix is just using <message/> syntax. But if for some reason (which?) PubSub is preffered, use some other container for the custom stuff, not <publish-options/>.
  381. Ge0rG I also had that thought about "why not messages" when reading Push XEP back then
  382. Holger Lance' initial 0357 draft did just that, FWIW ...
  383. Ge0rG maybe Lance knows why it was changed, then?
  384. Holger https://github.com/legastero/customxeps/blob/gh-pages/extensions/push.md
  385. Ge0rG oh, "push token maintenance" is another thing I forgot on the device-identifier mail.
  386. Holger <Holger> Lance: What's the reason for using PubSub as opposed to plain messages to talk to the app server, BTW? <Lance> Holger: existing protocol, terminology, and semantics
  387. Holger There you go.
  388. zinid great
  389. zinid we can use pubsub for messages and presences btw
  390. zinid because why not? existing protocol!
  391. Holger I would say a <message/> offers all those features as well :-)
  392. Ge0rG Time to ask on standards@?
  393. Kev We can use pubsub syntax for not-default-xep60 services just fine, if we want to (e.g. 369).
  394. Kev And I think there's an argument for doing so. But if we go that route we need to be clear that it's not a standard pubsub service you're using.
  395. MattJ zinid, https://xmpp.org/extensions/xep-0207.html
  396. zinid MattJ: I know :)
  397. Holger Kev: Same syntax, slightly different semantics sounds awesome to me.
  398. Ge0rG The road to hell is paved with good intentions?
  399. zinid especially that in fact we're not reusing *existing* technology, where are using a fork
  400. dwd has left
  401. Ge0rG has left
  402. alacer has joined
  403. stefandxm has left
  404. stefandxm has joined
  405. Ge0rG has left
  406. stefandxm has left
  407. stefandxm has joined
  408. dwd has left
  409. stefandxm has left
  410. stefandxm has joined
  411. Flow has joined
  412. dwd has left
  413. Steve Kille has left
  414. emxp has joined
  415. emxp has joined
  416. Alex have just seen that many of teh projects are gone on the client/server/library page, because of the renew data. I don't think this is helpful for us as a XMPP community
  417. Holger "the renew data"?
  418. Ge0rG has left
  419. Alex Holger: https://github.com/xsf/xmpp.org/blob/master/data/README.rst
  420. jonasw Alex, anything specific you’re missing?
  421. Alex *last_renewed* field
  422. Alex jonasw: of course, I think the libraries page was 4x the size before :-)
  423. jonasw Alex, sure, but were those maintained?
  424. jonasw unmaintained libraries may be worse than no libraries
  425. Flow has joined
  426. Alex I don't agree on that
  427. Holger Alex: Seriously? Someone new to XMPP should wade through an endless list of dead projects?
  428. Alex one of the most used JS libraries for example, Strophe
  429. jubalh has joined
  430. jonasw Alex, if strophe.js missed the fact that they need to renew and they’re actively maintained, I think someone should tell them :)
  431. Holger (Huh there's an AstraChat server?)
  432. Alex Strope is only 1 example, there are many others which are missing
  433. Flow it would be nice to get an e-mail that my project is about to disappear
  434. dwd has left
  435. Flow but other then that, the new system is far better then listing a bunch of dead projects
  436. Alex Sleek is another famous Python XMPP lib which is missing
  437. Flow bear ^
  438. jubalh has left
  439. jubalh has joined
  440. Alex when I am new to XMPP and browse this pages I don't see many options, which is not positive
  441. jonasw huh
  442. jonasw Alex, many options and trying three which are unmaintained may be worse?
  443. jonasw should’ve watched out for sleek
  444. Alex jonasw: I don't think that most of the projects which are gone now were not maintained, but that is just an assumption
  445. Flow How about sorting by last update or something like that?
  446. Alex we can send a mail to standard, jdev and members and ask teh authors to renew their active projects
  447. jonasw sorting by a non-obvious thing seems bad
  448. jonasw Alex, we did that
  449. jonasw at least jdev I think
  450. jubalh has joined
  451. Alex ok, mnissed that probably :-)
  452. jonasw Subject: [jdev] XMPP Software Developers: Action Required
  453. Ge0rG Here is a nice one regarding the brokenness of TCP and ICMP on the public Internet. The main focus is fragmentation, but the problems stated also apply to detection of stale TCP connections: https://blog.cloudflare.com/ip-fragmentation-is-broken/
  454. jubalh has joined
  455. Steve Kille has joined
  456. jubalh has left
  457. jubalh has joined
  458. valo has joined
  459. Tobias has joined
  460. jubalh has left
  461. jubalh has joined
  462. jubalh has left
  463. jubalh has joined
  464. valo has joined
  465. lskdjf has joined
  466. Steve Kille has left
  467. Syndace has left
  468. jubalh has joined
  469. Steve Kille has left
  470. jubalh has joined
  471. jubalh has left
  472. blabla has joined
  473. jubalh has joined
  474. lumi has joined
  475. jubalh has left
  476. Steve Kille has left
  477. Steve Kille has left
  478. Steve Kille has left
  479. blabla has left
  480. Steve Kille has left
  481. jere has joined
  482. Steve Kille has joined
  483. alacer has joined
  484. ralphm has left
  485. jere has left
  486. jere has joined
  487. lovetox has joined
  488. Tobias has left
  489. alacer has joined
  490. pep. has left
  491. jere has left
  492. jere has joined
  493. winfried has joined
  494. Steve Kille has left
  495. alacer has joined
  496. SamWhited has joined
  497. efrit has joined
  498. lskdjf has joined
  499. Steve Kille has left
  500. Steve Kille has left
  501. waqas has joined
  502. jjrh has left
  503. stefandxm has left
  504. Steve Kille has left
  505. jjrh has left
  506. winfried has joined
  507. Steve Kille has joined
  508. jonasw has left
  509. jjrh has left
  510. Steve Kille has left
  511. ralphm has left
  512. jere has joined
  513. jere has joined
  514. Steve Kille has left
  515. jjrh has left
  516. Steve Kille has left
  517. zinid Ge0rG: nobody cares, they just invent crap like http2 instead of really fixing things
  518. zinid Just like XSF 😂 Because interop
  519. jjrh has left
  520. Ge0rG it's even worse.
  521. efrit has left
  522. Kev has left
  523. Valerian has joined
  524. jere has left
  525. jere has joined
  526. alacer has joined
  527. jjrh has left
  528. jjrh has left
  529. jjrh has left
  530. jjrh has left
  531. jjrh has left
  532. sonny has left
  533. sonny has joined
  534. Valerian has left
  535. sonny has joined
  536. daniel has left
  537. emxp has left
  538. emxp has joined
  539. Kev has joined
  540. jjrh has left
  541. jubalh has joined
  542. dwd Can someone not using Gajim write something with *bold* and /italic/ things in, please?
  543. Flow has joined
  544. Ge0rG dwd: at your service. Italics doesn't work though.
  545. mathieui this is not /italic/ and neither that one is *bold*
  546. Ge0rG Damn https://dev.louiz.org/issues/2722.
  547. Ge0rG Damn <https://dev.louiz.org/issues/2722>.
  548. dwd Ge0rG, Yours came as XHTML-IM, I think.
  549. Ge0rG mathieui: "at" was bold.
  550. mathieui Ge0rG, yours, yes
  551. dwd mathieui, Whereas yours was rendered as italic and bold for me, Markdown-like.
  552. jubalh has left
  553. mathieui jonasw, err, I would like xmpp: links in href :p
  554. Ge0rG dwd: ah, so you were asking for markdown in 'body' and not for XHTML-IM formatted.
  555. dwd Ge0rG, Indeed, sorry.
  556. Kev I like the idea of markdown in XMPP (I'm not entirely sure that I didn't originate *stuff* in XMPP with Psi), but I really dislike not having a standard. So I think we'd have to actually define a MD standard ourselves (which we pretty much had to with XHTML-IM, of course).
  557. Ge0rG so we are reinventing XHTML-IM without XML now?
  558. SamWhited I don't especially care what a new thing looks like, but I do like the idea of it being some sort of plain text formatting in <body> as opposed to a separate <fancybody> element or whatever.
  559. Ge0rG people will just plug-in their favorite markdown parser and your body texts will end up mutilated and you will still end up being pwned.
  560. SamWhited It keeps things simple to have one version of the message. One place to encrypt when doing E2E, no risk of something malicious sending a different plain text / non-plaintext version so that two different clients have tow representations of the conversastion, etc.
  561. Ge0rG SamWhited: there is no amount of specification that will prevent developers from doing stupid things.
  562. alacer has joined
  563. SamWhited Ge0rG: I agree. What's your point?
  564. SamWhited Security issues will always exist, so we shouldn't even try to mitigate any of them?
  565. Ge0rG SamWhited: XHTML-IM is good as it is.
  566. SamWhited Except for the history of insecure implementations.
  567. Ge0rG SamWhited: I have a dozen of CVEs for people not reading the Security Considerations of 0280.
  568. Ge0rG I want to burn Carbons with fire, but for completely different reasons.
  569. Valerian has joined
  570. Ge0rG SamWhited: by replacing XHTML-IM with markdown, you will keep the exact same security problems.
  571. mathieui most markdown implementations even allow raw html right in the plaintext, so I don’t see how that solves the "developer get it wrong" part
  572. Ge0rG And probably add some more.
  573. Ge0rG what mathieui said.
  574. SamWhited Ge0rG: That's why I'm not arguing that we should use markdown.
  575. SamWhited Just that we should obsolete XHTML-IM.
  576. mathieui yeah, that’s what SamWhited made a point in the thread to keep it about deprecating xhtml-im
  577. mathieui yeah, that’s why SamWhited made a point in the thread to keep it about deprecating xhtml-im
  578. Flow has joined
  579. Ge0rG SamWhited: Council just refused to deprecate 136 despite it not being a replacement/alternative to 313.
  580. SamWhited Ge0rG: I know, it made me sad. This is a security issue though, which I think makes it slightly different and more pressing.
  581. Kev I don't see a particular need to deprecate XHTML-IM. I think *anything* involving markup being injected into a DOM is going to see people doing stupid things.
  582. Kev But I do think that it's woefully inadequate at protecting diligent devs from things they haven't considered.
  583. Ge0rG XHTML-IM is not perfect, it's got some ugly warts. But it (or some other markup XEP) has its place, and anything that you can come up with as an alternative will have the same or worse security problems.
  584. SamWhited I disagree, it would be quite easy to design a spec with the same level of functionality but where it required active effort on the developers part to introduce the same security problems.
  585. Ge0rG SamWhited: maybe you can write that spec up, then?
  586. SamWhited It doesn't need to be impossible, it just needs to not be the "default".
  587. Ge0rG and then implement it in a bunch of widely-used XMPP clients.
  588. mathieui e.g. if we design a new markup language with a secure reference implementation
  589. SamWhited Ge0rG: no, I'm not interested. I'm just interested in getting rid of XHTML-IM.
  590. Ge0rG And then ask again for deprecation of XHTML-IM?
  591. jere has joined
  592. mathieui I remember embedding javascript within my nickname in jappix that would dump account passwords to a MUC
  593. mathieui no need for xhtml-im there
  594. SamWhited Yah, I've found plenty of those too, they're unrelated though.
  595. Ge0rG Yeah, so many places for XSS.
  596. mathieui they have the same root issue: the web
  597. SamWhited mathieui: If you have a proposal for fixing the root issue, I'm all ears :)
  598. mathieui :D
  599. SamWhited I would love to fix "the web" :)
  600. Zash SamWhited: So what you really wanna do is deprecated teh web! :)
  601. Zash Let's do tha!
  602. Alex use markdown :-)
  603. Ge0rG Yeah, let's approach the W3C with that.
  604. Kev SamWhited: I do think that having even a strawman that demonstrates that it's straightforward to write something better would help with those people who think that replacing XHTML-IM with something else is likely to also be easy to carelessly introduce vulns.
  605. SamWhited *sigh* yah, maybe you're right.
  606. Ge0rG Kev: even if there was a strawman, we still have the wide deployment problem.
  607. Ge0rG XHTML-IM is supported over a pretty large client base, as opposed to non-markdown-strawman.
  608. Kev Ge0rG: Yes, but one bridge at a time.
  609. stefandxm has joined
  610. Flow <message><markup-hint lang="commonmark:1"/>…</message>
  611. SamWhited I think you are probably right, that would go a long ways towards convincing some folks, I'm just not sure that I want to put in the work on that. I'm not interested in even having a replacement since I'd probably never implement it myself (not that I think one shouldn't be made, I understand that lots of deployments need basic formatting)
  612. Ge0rG Also related: https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89
  613. SamWhited But I do want to deprecate it, so maybe I need to just waste some time on a thing I'll never use to convince people. I'm torn.
  614. SamWhited s/deprecate/obsolete/ (I'm trying to be precise about my language, but I still mix those two up constantly)
  615. Ge0rG I want to deprecate GC1.0. And then some.
  616. Kev Ge0rG: I think I proposed that onlist as an alternative to 2 or 3 or whatever teh number was, and I don't remember any pushback.
  617. jjrh has left
  618. Ge0rG Kev: it was brought up at the last-but-one council and got vetoed immediately, IIRC
  619. Ge0rG Kev: you also still wanted to provide more alternatives to 1-2-3.
  620. Flow has joined
  621. Kev Ge0rG: I don't think I did. I think my alternative was to do 2 or 3, whichever the one I said I liked was, and to get rid of gc1.
  622. jjrh has left
  623. Steve Kille has joined
  624. Ge0rG Kev: oh, sorry. I must be misremembering then.
  625. Kev And I might misremember, but I don't recall anyone objecting to it in the thread.
  626. Ge0rG Maybe because it was TLDR, once again.
  627. alacer has joined
  628. emxp has joined
  629. jjrh has left
  630. Ge0rG Kev: oh, there it is: "Georg’s started a worthwhile discussion here, but I’m sure these aren’t the only 3 options we can consider."
  631. Ge0rG Kev: you also liked (2), which was the new-iq-type.
  632. sonny has joined
  633. sonny has joined
  634. Ge0rG but I'm interested in the other options before writing a diff to 0045.
  635. sonny has joined
  636. Kev Ge0rG: Did I not follow-up by saying that I thought that if gc1 was the reason that (3) was better than (2) we should kill gc1?
  637. Kev I accept there's a very real possibility that I'm simply going mad.
  638. jjrh has left
  639. Valerian has left
  640. Ge0rG Kev: you ended up discussing with Zash whether we can reliably obtain statistics on "intended GC1 joins" vs "presence updates misunderstood as GC1 joins"
  641. Ge0rG which we can't.
  642. sonny has joined
  643. Zash Why not?
  644. sonny has joined
  645. Ge0rG Zash: how?
  646. Ge0rG Kev: I've long believed that every person participating in this chat room and the related organizations is affected by a certain kind of madness.
  647. jjrh has left
  648. Zash Ge0rG: Look at presence sent to a MUC. Does it have the <x>? Is the user already in the room? Log that.
  649. jjrh has left
  650. Valerian has joined
  651. Ge0rG Zash: and then compare that with <x>-enabled presence from the same full JID in the last X hours?
  652. Kev Zash: That's not the question.
  653. Kev Zash: That's just listing which presences don't have <x/> it's not telling you if it's a gc1 join or a presence update.
  654. stefandxm has left
  655. jjrh has left
  656. jjrh has left
  657. alacer has left
  658. dwd has left
  659. valo has joined
  660. dwd has left
  661. SamWhited Sorry, got pulled away… RE GC1.0 I agree, let's deprecate it. I don't think it was vetoed, I think we just decided to get more feedback on list first, but I don't have the minutes in front of me.
  662. dwd has left
  663. Ge0rG wow, just got a presence from somebody in the form of "phone." + [68 characters that look like base64, including slashes]
  664. Ge0rG the madness is rising.
  665. Ge0rG SamWhited: yeah, the final decision was to get some list discussion, but there were some proponents of keeping GC1, surprisingly
  666. Zash Madness
  667. Zash http://www.youtube.com/watch?v=QH7fIkV8nsk
  668. jjrh has left
  669. jjrh has left
  670. dwd has left
  671. moparisthebest has left
  672. alacer has joined
  673. uc has joined
  674. jonasw SamWhited, you quoted me rather unfairly on the ML. I won’t point it out there, because I don’t believe you did that on purpose.
  675. stefandxm has joined
  676. SamWhited jonasw: Did I? Sorry about that
  677. SamWhited I removed the extra, but I didn't think I took you out of context or anything
  678. jonasw you removed the part where I said "plus providing a reference implementation"
  679. SamWhited Yah, I know, I wasn't responding to that part
  680. SamWhited It's unrelated to further restricting the subset of HTML involved
  681. jonasw not entirely, it’ll simplify the reference implementation.
  682. SamWhited ah, I see, restricting the HTML was about making the reference implementation simpler? Yah, I misunderstood what you meant
  683. SamWhited Either way, I don't think a reference implementation helps either
  684. jonasw all implementations, but also the reference implementation, because I agree that simply changing the spec won’t solve a thing
  685. jonasw I strongly think so
  686. Alex has left
  687. jjrh has left
  688. SamWhited I think adding a reference implementation won't solve a thing (although I'm certainly not against it, if we can have an implementation that we can more or less guarantee is secure, maybe at least a few things will use it and not be broken out of the box)
  689. SamWhited But not everyone will use it, so I don't think it really helps
  690. jonasw if we link the reference implementation prominently in the XEP and doesn’t have any non-DOM dependencies, I think new implementations certainly will use it.
  691. Alex has joined
  692. SamWhited Yah, some will and that's nice, but not all will
  693. jjrh has left
  694. jonasw meh
  695. SamWhited It doesn't really solve the problem, just puts a bandaid on it for a few implementations (which isn't bad, and I think you should totally do it, but I think we should still obsolete the spec either way)
  696. jjrh has left
  697. Ge0rG There are so many places to inject code into the DOM of a JavaScript XMPP client, XHTML-IM is just one of them.
  698. jonasw see, my main issue is that I really don’t want to see that we use plain text markup when we have the opportunity to use structured markup (be it XHTML-IM or anything else)
  699. SamWhited Ge0rG: yes… again I don't understand your point though: security is hard, so let's not fix any of the problems?
  700. SamWhited Other places where DOM injection is possible aren't related to this discussion
  701. jonasw I think that providing a reference implementation is the best we can and should do.
  702. SamWhited jonasw: I'm not 100% sure but I *think* I agree with you. Deprecating XHTML-IM doesn't mean we're going to use plain text markup in the <body> though.
  703. Ge0rG SamWhited: I'm just saying that security-ignorant developers will keep writing vulnerable XMPP clients, with or without XHTML-IM
  704. jonasw SamWhited, what else are we going to do? The alternative will be to reinvent XHTML-IM.
  705. SamWhited Ge0rG: Yes, I agree. I don't see what that has to do with anything though.
  706. SamWhited jonasw: Yes, reinvent it, but reinvent it in such a way that it's not HTML.
  707. Ge0rG SamWhited: I think my slightly exaggerated point is: you can't make webchat more secure by removing XHTML-IM.
  708. jonasw We shouldn’t sacrifice something that indeed works, can be made secure with reasonable effort (if we abolish @style, which we totally should do), to make in total only a few implementations transition from not-secure to secure (only a few will transition by obsoleting XHTML-IM, because many will have other XSS issues)
  709. jonasw SamWhited, people will simply patch tag names and embed it in the DOM.
  710. jonasw if it’s more complicated than that, people will not implement it.
  711. jonasw (and if people simply embed an XML tree into the dom, havoc will be wreaked)
  712. Flow has joined
  713. SamWhited jonasw: Your'e assuming @style is the only problem. That's not the problem that I've seen, the problem that I've seen won't be solved by further restricting what HTML is allowed.
  714. Ge0rG Maybe we should provide an XSS bot that will join your MUC with an evil name, post evil messages and change the subject to some <script> tag?
  715. SamWhited People are allowing <script> tags and the like, it doesn't matter how much more stuff you take out, they'll still just allow <script> tags.
  716. jonasw SamWhited, I’m keeping to mention @style, because @style is really really hard to fix.
  717. jonasw the other parts are more or less a piece of cake.
  718. SamWhited jonasw: Yah, I agree with you we should take it out. I just don't agree with you that it would solve anything.
  719. Ge0rG SamWhited: the problem you are trying to fix is ignorant developers?
  720. SamWhited Ge0rG: "fix" is the wrong word, but essentially yes. We can't "solve" all the security problems, we can never stop developers from doing a dumb thing and allowing a <script> tag. We *can* make it harder to do that by default.
  721. jonasw SamWhited, with @style, it is entirely unrealistic that any implementation is safe, because nobody will parse CSS.
  722. dwd has left
  723. SamWhited jonasw: I'm not arguing against that. By all means, remove style.
  724. SamWhited But that's another orthogonal problem.
  725. jonasw only if you’re set on obsoleting XHTML-IM, which I’m not ;-).
  726. dwd has left
  727. SamWhited It's orthogonal either way. The problem that I've seen, over and over again, is that people say "it's HTML, so take it out of the <html> element and stick it in the dom" or they have some subtle bug in how they do their whitelisting that allows it to be bypassed. Removing style won't solve either of those things (though again, I'm not disagreeing, it's something we should do to help existing implementations)
  728. dwd has left
  729. jonasw okay, I see your point.
  730. stefandxm has left
  731. Kev has left
  732. nyco has left
  733. alacer has joined
  734. emxp has joined
  735. Tobias has joined
  736. Valerian has left
  737. Steve Kille has left
  738. Valerian has joined
  739. emxp has joined
  740. alacer has left
  741. dwd has left
  742. waqas has left
  743. ralphm has left
  744. dwd has left
  745. dwd has left
  746. jere has joined
  747. jere has left
  748. jere has joined
  749. jonasw has left
  750. dwd has left
  751. jjrh has left
  752. stefandxm has joined
  753. ralphm has joined
  754. alacer has joined
  755. jonasw has joined
  756. waqas has joined
  757. dwd has left
  758. dwd has left
  759. jubalh has joined
  760. jubalh has left
  761. jubalh has joined
  762. jonasw has left
  763. Tobias has joined
  764. dwd has left
  765. Syndace has joined
  766. dwd has left
  767. alacer has left
  768. alacer has joined
  769. jonasw has joined
  770. jubalh has left
  771. jubalh has joined
  772. jonasw has left
  773. Alex has left
  774. Alex has joined
  775. jjrh has left
  776. Alex has left
  777. lovetox has left
  778. Tobias has joined
  779. jjrh has left
  780. Tobias has left
  781. waqas has left
  782. Zash has left
  783. jonasw has left
  784. uc has joined
  785. Valerian has left
  786. Valerian has joined
  787. Alex has left
  788. dwd has left
  789. alacer has joined
  790. dwd has left
  791. alacer has joined
  792. Valerian has left
  793. pep. has left
  794. mimi89999 has left
  795. Flow has left
  796. Syndace has left
  797. Valerian has joined
  798. uc has joined
  799. alacer has left
  800. Tobias has joined
  801. Steve Kille has joined
  802. intosi has joined
  803. intosi has left
  804. intosi has joined
  805. Guus has joined
  806. jjrh has left
  807. jjrh has left
  808. la|r|ma has left
  809. Tobias has joined
  810. la|r|ma has left
  811. matlag has left
  812. jjrh has left
  813. jjrh has left
  814. pep. has left
  815. jjrh has left
  816. goffi has left
  817. andrey.g has left
  818. andrey.g has joined
  819. Guus has left
  820. Guus has joined
  821. Alex has left
  822. Steve Kille has left
  823. Alex has joined
  824. andrey.g has joined
  825. jjrh has left
  826. Guus has left
  827. edhelas has left
  828. edhelas has joined
  829. alacer has joined
  830. Tobias has joined
  831. andrey.g has joined
  832. Guus has joined
  833. jere has joined
  834. Tobias has joined
  835. andrey.g has joined
  836. Tobias has joined
  837. la|r|ma has joined
  838. jere has joined
  839. Guus has left
  840. Guus has joined
  841. andrey.g has joined
  842. zinid has left
  843. andrey.g has joined
  844. Guus has left
  845. Alex has left
  846. alacer has joined
  847. ralphm has joined
  848. Alex has joined
  849. jubalh has joined
  850. andrey.g has joined
  851. Valerian has left
  852. Valerian has joined
  853. Alex has left
  854. Tobias has joined
  855. Valerian has left
  856. Valerian has joined
  857. andrey.g has joined
  858. dwd has left
  859. SamWhited has left
  860. andrey.g has joined
  861. tux has left
  862. andrey.g has joined
  863. intosi has joined
  864. Guus has joined
  865. andrey.g has joined
  866. winfried has joined
  867. Tobias has left
  868. Guus has left
  869. andrey.g has joined
  870. Link Mauve « 08:39:27 jonasw> you need to know that it’s code though. XHTML-IM does not allow for a <code/> tag », it totally does, fyi.
  871. Syndace has left
  872. Link Mauve I should totally improve poezio’s XHTML-IM module to run pygment on incoming code!
  873. Wiktor has joined
  874. Wiktor has joined
  875. Zash I'm almost surprised that you haven't already
  876. mathieui since 2003!
  877. mathieui we’re way behind
  878. mathieui note to self: DoS Link Mauve by pasting perl code in MUCs
  879. Zash Does <code> not have a language attr tho?
  880. Link Mauve mathieui, you know you don’t need anything fancy to DoS my server. :p
  881. mathieui right.
  882. Link Mauve Zash, hmm, maybe I’d have to write a XEP extending 0071, maybe with a standardised class attribute or something?
  883. Zash Maybe you already discussed this, but what about all the ways CSS can invoke more resources?
  884. Zash Link Mauve: Standardized classes would sorta make sense I guess
  885. Zash Eg like vcard thing
  886. mathieui yeah, a class preset would actually solve all the portability issues of 0071, along with solving the potential for CSS abuse
  887. Zash Way past brain-works-o'clock
  888. Zash microformats!
  889. Link Mauve Zash, don’t say that, I just woke up for the fourth time of the day!
  890. mathieui yes but you didn’t wake up yesterday, so it evens out
  891. Link Mauve True.
  892. Zash I haven't woken up today.
  893. Zash MMmm GMT+2 jokes ftw
  894. andrey.g has joined
  895. Guus has joined
  896. jere has joined
  897. jere has joined
  898. Guus has left
  899. Guus has joined
  900. andrey.g has joined
  901. alacer has joined
  902. Valerian has left
  903. Guus has left
  904. jjrh has left
  905. daniel has joined
  906. jjrh has left
  907. jjrh has left
  908. Zash makes xep-0071.epub and dumps to e-ink-thingy for later reading
  909. jjrh has left
  910. jjrh has left
  911. Zash Uh, I should make an email-to-epub thing
  912. lumi has left
  913. Zash has left