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