XSF logo XSF Discussion - 2017-11-06


  1. goffi has left
  2. efrit has left
  3. Ge0rG has left
  4. Zash has left
  5. jere has joined
  6. jere has joined
  7. Ge0rG has left
  8. tux has left
  9. tux has joined
  10. efrit has joined
  11. lskdjf has left
  12. lskdjf has left
  13. Ge0rG has left
  14. lskdjf has left
  15. Zash has left
  16. arc has left
  17. arc has joined
  18. lskdjf has left
  19. Valerian has left
  20. Valerian has joined
  21. Guus has left
  22. Valerian has left
  23. Guus has left
  24. Ge0rG has left
  25. lskdjf has joined
  26. lskdjf has left
  27. Guus Holger: done. Check your mail.
  28. lskdjf has left
  29. daniel has left
  30. bjc has joined
  31. lskdjf has joined
  32. Ge0rG has left
  33. Valerian has joined
  34. Ge0rG has left
  35. Tobias has left
  36. Ge0rG has joined
  37. Guus has left
  38. Valerian has left
  39. Tobias has joined
  40. bjc has left
  41. Ge0rG has left
  42. daniel has left
  43. daniel has joined
  44. la|r|ma has joined
  45. lumi has left
  46. jere has left
  47. jere has joined
  48. Kev has left
  49. Ge0rG has left
  50. Kev has left
  51. Guus has left
  52. Tobias has joined
  53. bjc has left
  54. Ge0rG has left
  55. la|r|ma has joined
  56. Tobias has joined
  57. Ge0rG has left
  58. bjc has left
  59. Ge0rG has left
  60. Ge0rG has left
  61. jere has left
  62. vanitasvitae has joined
  63. jere has joined
  64. arc has left
  65. arc has joined
  66. Ge0rG has left
  67. efrit has left
  68. jjrh has joined
  69. jjrh has joined
  70. jjrh has joined
  71. efrit has joined
  72. matlag has joined
  73. matlag has joined
  74. Ge0rG has left
  75. Ge0rG has left
  76. SamWhited has left
  77. arc has left
  78. arc has joined
  79. Ge0rG has left
  80. arc has left
  81. arc has joined
  82. arc has left
  83. arc has joined
  84. lskdjf has joined
  85. Ge0rG has left
  86. daniel has left
  87. daniel has joined
  88. daniel has left
  89. daniel has joined
  90. nyco has left
  91. nyco has joined
  92. Ge0rG has left
  93. Syndace has left
  94. Syndace has joined
  95. daniel has left
  96. daniel has joined
  97. Ge0rG has left
  98. efrit has left
  99. daniel has left
  100. daniel has joined
  101. marc has left
  102. Ge0rG has left
  103. daniel has left
  104. daniel has joined
  105. Ge0rG has left
  106. Guus has left
  107. Ge0rG has left
  108. Ge0rG has left
  109. Ge0rG has left
  110. Ge0rG has left
  111. Ge0rG has left
  112. Guus has left
  113. Ge0rG has left
  114. @Alacer has left
  115. daniel has left
  116. daniel has joined
  117. Ge0rG has left
  118. Guus has left
  119. @Alacer has joined
  120. ralphm has left
  121. Ge0rG has left
  122. @Alacer has left
  123. @Alacer has joined
  124. Ge0rG has left
  125. sonny has left
  126. ralphm has left
  127. uc has joined
  128. Ge0rG has left
  129. ralphm has left
  130. Ge0rG has left
  131. Ge0rG has left
  132. zinid has left
  133. zinid can I have an account there too?
  134. zinid zinid - xramtsov@gmail.com
  135. Kev Done.
  136. zinid thx
  137. arc has left
  138. arc has joined
  139. thomas_ has joined
  140. daniel has left
  141. daniel has joined
  142. jubalh has joined
  143. Ge0rG has joined
  144. sezuan has left
  145. Steve Kille has left
  146. arc has left
  147. arc has joined
  148. goffi has joined
  149. uc has joined
  150. jonasw SamWhited, you might want to update https://wiki.xmpp.org/web/Sam_Whited_for_Council_2017#Better_recommendations
  151. Steve Kille has joined
  152. arc has left
  153. arc has joined
  154. Kev jonasw: Actually, the deadline for applications has passed, so we shouldn't be editing our applications really.
  155. jonasw Kev, I know. I just wanted to point it out for Sam to judge, given that the content is obviously deprecated and the thing which is deprecated has changed before the deadline
  156. Guus Happy to see that we at least have a full complement of candidates. I was worried there for a bit.
  157. jonasw Kev, also, MattJs application for board is still null
  158. Kev Don't think that's true.
  159. jonasw Kev, then at least it’s not properly linked
  160. Kev Have you tried clicking it? :)
  161. Guus there's a page for Matt, but the link shows red for me. Some weird caching issue in mediawiki that I though was fixed.
  162. jonasw no. stupid caches.
  163. jonasw the three issues in computer science. Cache invalidation and Off-by-one errors.
  164. Guus I like how 50% of the applications were made on the day of the deadline.
  165. jonasw I don’t like that.
  166. Guus you're right, it's not ideal, but it's funny to see how procrastination is at work each time. At least, I'm hoping that it's just that.
  167. jonasw I too do hope that
  168. intosi Usually is for me when I'm late at putting up my reapplication ;)
  169. jonasw is there a summary on how the voting for Board & Council works for those who find the Bylaws hard to read?
  170. jonasw is it that you vote for each individual yes/no and each individual has to be elected by majority to be part of that group?
  171. jonasw if so, what happens if n>m (where m being the size of the group) individuals get elected?
  172. sonny has joined
  173. Ge0rG has left
  174. Ge0rG has joined
  175. jcbrand has joined
  176. Guus I'm just hoping that procrastination combined with wiki account loss didn't prevent people from applying.
  177. Guus jonasw: I don't know, not do I think your explanation was clearer than the bylaws 😉
  178. jonasw I’m sorry :P
  179. goffi Guus: I was considering applying but I gave up as I've already too much work and I can't take any more engement this year.
  180. goffi commitment*
  181. Kev jonasw: Top five, basically.
  182. jonasw top five with respect to what?
  183. jonasw do we get one yes/no vote per candidate?
  184. Kev ISTR we pick (up to) our chosen five, those count as yes, others count as no.
  185. Guus istr istr istr
  186. Guus I...
  187. Guus it stands to reason?
  188. Ge0rG has left
  189. Ge0rG has joined
  190. Guus goffi: totally understandable. I'm just hoping that there we not people that did want to apply, but ended up missing the deadline because the forgot about / were not aware of the loss of wiki accounts
  191. Guus (we had a couple of requests tonight to recreate accounts, which made me wonder)
  192. Kev I seem to recall
  193. ralphm has left
  194. jonasw Guus, I’m confident that those people would step up if that was the only reason
  195. jonasw in which case I’m sure that we could extend the period retrospectively since this was an issue outside of their control
  196. daniel has left
  197. jcbrand has left
  198. bra has left
  199. Guus I kind of disagree with the 'outside of their control' classification, but would be in favor of accepting late candidacies.
  200. Kev If anyone had said they needed an account, and didn't get one, yesterday that'd be one thing, but if anyone comes in today and says they want to apply, they obviously missed it.
  201. Guus There's the "ah, I couldn't sign up and was confident that requesting a new account wouldn't get me a new account before the deadline" argument. If we would be extending the deadline (which I don't think we are), there's not much reason to accept one type, but not another.
  202. Kev I suggest we stop debating what to do in a situation we don't have :)
  203. jonasw :)
  204. jonasw it’s monday morning, don’t judge people for a desire to distract themselves with irrelevant scenarios
  205. edhelas Kev +1
  206. edhelas by the way, is there people that are interested to come to T-DOSE this month ? https://wiki.xmpp.org/web/T-DOSE_2017
  207. Guus I'll be at T-Dose! :)
  208. Guus let me put out a tweet for that event
  209. Ge0rG has left
  210. bra has joined
  211. Guus edhelas: we should prepare for some demos and the like. Thoughts?
  212. thomas_ has left
  213. dwd has joined
  214. Guus edhelas: would you mind drafting a blogpost that announces our presence there?
  215. edhelas I don't have much time for that atm sorry
  216. goffi Guus: by the may, I need to recreate account too
  217. goffi no that you're talking about it :p
  218. thomas_ has joined
  219. daniel has left
  220. goffi now*
  221. Guus goffi: desired nickname and email address please
  222. Ge0rG It looks like we finally have a situation where wiki account creation is almost instant.
  223. daniel has left
  224. goffi Guus: answered in P.V.
  225. edhelas Ge0rG API over XMPP MUC
  226. jonasw XML-RPC!
  227. goffi ad-hoc commands
  228. goffi that works great
  229. goffi I love this XEP
  230. edhelas if only it was more user friendly
  231. goffi why would it not be ? It's a client thing to make is user friendly
  232. Ge0rG has left
  233. daniel has left
  234. marc has joined
  235. dwd has left
  236. dwd has joined
  237. @Alacer has left
  238. Alex has joined
  239. @Alacer has joined
  240. daniel has left
  241. tim@boese-ban.de has left
  242. tim@boese-ban.de has left
  243. daniel has left
  244. Ge0rG has left
  245. tim@boese-ban.de has joined
  246. tux has joined
  247. edhelas http://www.t-dose.org/node/1063
  248. daniel has left
  249. jcbrand has joined
  250. jcbrand has left
  251. jcbrand has joined
  252. Ge0rG has left
  253. Guus has left
  254. daniel has left
  255. daniel has left
  256. Ge0rG has left
  257. Tobias has joined
  258. Alex has left
  259. Guus has left
  260. ThurahT has joined
  261. Ge0rG has left
  262. jcbrand has left
  263. ThurahT has left
  264. ThurahT has joined
  265. daniel has left
  266. jcbrand has joined
  267. Ge0rG has left
  268. lskdjf has joined
  269. la|r|ma has joined
  270. nyco has left
  271. ralphm has joined
  272. Alex has joined
  273. Alex has left
  274. Ge0rG has left
  275. jubalh has joined
  276. jcbrand has left
  277. jcbrand has joined
  278. Holger Guus: Got the account email, thank you.
  279. Guus Holger: yw
  280. efrit has joined
  281. Ge0rG has left
  282. Alex has joined
  283. efrit has left
  284. jcbrand has left
  285. Ge0rG has left
  286. daniel has left
  287. jere has left
  288. jere has joined
  289. Ge0rG has left
  290. daniel has left
  291. sonny has joined
  292. jere has left
  293. jere has joined
  294. Ge0rG has left
  295. ralphm has left
  296. @Alacer has left
  297. @Alacer has joined
  298. Holger has left
  299. jcbrand has joined
  300. jcbrand has left
  301. jcbrand has joined
  302. Ge0rG has left
  303. lumi has joined
  304. zinid has left
  305. vanitasvitae has joined
  306. Valerian has joined
  307. sonny has joined
  308. jcbrand has left
  309. Ge0rG has left
  310. daniel has left
  311. valo has joined
  312. Ge0rG has left
  313. Alex has left
  314. jere has joined
  315. nyco has joined
  316. jcbrand has left
  317. Ge0rG has left
  318. daniel has left
  319. Valerian has left
  320. Ge0rG has left
  321. jcbrand has joined
  322. Alex has joined
  323. nyco has left
  324. nyco has joined
  325. Alex has left
  326. Alex has joined
  327. Tobias has left
  328. Ge0rG has left
  329. jcbrand has left
  330. jcbrand has joined
  331. Ge0rG has left
  332. pep. has left
  333. Valerian has joined
  334. Ge0rG has left
  335. jcbrand has left
  336. ralphm has left
  337. lskdjf has left
  338. daniel has left
  339. lovetox has joined
  340. jcbrand has joined
  341. Ge0rG has left
  342. jere has joined
  343. daniel has left
  344. Tobias has joined
  345. bjc has left
  346. Valerian has left
  347. daniel has left
  348. daniel has left
  349. Ge0rG has left
  350. ralphm has joined
  351. daniel has left
  352. Ge0rG has left
  353. daniel has left
  354. Ge0rG has left
  355. daniel has left
  356. lskdjf has left
  357. daniel has left
  358. zinid has left
  359. Alex has left
  360. daniel has left
  361. ralphm has joined
  362. daniel has left
  363. Alex has left
  364. Ge0rG has left
  365. Kev has left
  366. bjc has joined
  367. Alex has left
  368. daniel has left
  369. Valerian has joined
  370. Ge0rG has left
  371. Steve Kille has left
  372. daniel has left
  373. daniel has left
  374. Holger has left
  375. Alex has joined
  376. daniel has left
  377. ralphm has left
  378. Ge0rG has left
  379. daniel has left
  380. Holger has left
  381. daniel has left
  382. lovetox has left
  383. lovetox has joined
  384. Ge0rG has left
  385. nyco has left
  386. nyco has joined
  387. jjrh has left
  388. Valerian has left
  389. jjrh has left
  390. jcbrand has left
  391. jjrh has left
  392. jubalh has left
  393. Tobias has left
  394. jubalh has left
  395. lovetox has left
  396. Ge0rG has left
  397. ralphm has left
  398. daniel has left
  399. tux has left
  400. Valerian has joined
  401. Ge0rG has left
  402. lovetox has left
  403. lovetox has joined
  404. jubalh has left
  405. efrit has joined
  406. lskdjf has joined
  407. Guus has left
  408. jubalh has joined
  409. Ge0rG has left
  410. Guus has left
  411. nyco has left
  412. nyco has joined
  413. la|r|ma has joined
  414. zinid isn't it easier to add <subscribe/> to MUC XEP instead of writing this MIX stuff?
  415. goffi has left
  416. Guus It's certainly easier to write that, yes.
  417. Ge0rG Zash: tell us about minimix
  418. nyco has left
  419. nyco has joined
  420. zinid Guus: so what's the problem? we can create those pusbus nodes inside a muc room
  421. Ge0rG has left
  422. zinid *pubsub :)
  423. moparisthebest ha I like pusbus better we should rename it
  424. zinid no objection
  425. Ge0rG I vote for pup-soup. 🐶🍲
  426. intosi has left
  427. daniel has left
  428. Ge0rG has left
  429. zinid also, assuming a user's server should know about MIX is a bad idea
  430. Guus has left
  431. zinid another issue: > To achieve this, the client will query the user's own MAM archive using Message Archive Management (XEP-0313) [3], with the query filtered by the channel JID. > The only exception to this is when a user wishes to access message history in the channel prior to when the user joined the channel. To achieve this, the client will use MAM to retrieve message history directly from the MAM Archive of the MUX channel.
  432. zinid why a client cannot request mam archive from MIX channel right away?
  433. Ge0rG zinid: you should read up the previous discussions on standards@
  434. zinid which ones?
  435. Ge0rG the ones on MIX
  436. zinid there are tons of them
  437. Ge0rG Yes.
  438. zinid no thanks
  439. Kev has left
  440. goffi has joined
  441. Valerian has left
  442. zinid I just did some search and didn't find any relevant info inside those discussions
  443. Ge0rG has left
  444. arc has left
  445. Ge0rG has left
  446. arc has joined
  447. arc has left
  448. arc has joined
  449. waqas has joined
  450. arc has left
  451. arc has joined
  452. arc has left
  453. arc has joined
  454. arc has left
  455. arc has joined
  456. arc has left
  457. arc has joined
  458. Steve Kille has left
  459. Steve Kille has left
  460. Ge0rG has left
  461. ralphm has left
  462. Steve Kille has joined
  463. arc has left
  464. Ge0rG has left
  465. arc has joined
  466. efrit has left
  467. daniel has left
  468. bjc has left
  469. ralphm has joined
  470. Valerian has joined
  471. marc has left
  472. Ge0rG has left
  473. Ge0rG has left
  474. daniel has left
  475. Alex memberbot is up and council for the board & council election
  476. jonasw Alex, thanks :)
  477. jonasw even though I assume it’s up and running, and not up and council :-)
  478. Tobias has joined
  479. jonasw Alex, you included ralphms application despite it being late?
  480. marc has left
  481. jonasw (I’m not saying that we should not, but I think that some people have strong opinions on that)
  482. Alex yes I did
  483. Ge0rG has left
  484. efrit has joined
  485. marc has joined
  486. tim@boese-ban.de has left
  487. thomas_ has left
  488. McKael has left
  489. thomas_ has joined
  490. Arc has joined
  491. Arc """Your problem is so terrible, I worry that, if I help you, I risk drawing the attention of whatever god of technology inflicted it on you."""
  492. jonasw :D
  493. Guus please don't walk in the sea.
  494. Guus into*
  495. Ge0rG has left
  496. Arc I LOL'd so hard reading that
  497. Zash Arc: That sounds like how helping people with old code makes you the maintainer.
  498. Guus Yeah, I get funny looks whenever reading his book
  499. jonasw The What-If book?
  500. Guus yeah
  501. Guus he might have more, unsure :)
  502. Zash Is that from What-If?
  503. jonasw no
  504. Guus xkcd
  505. jonasw it’s todays xkcd, Zash
  506. Zash Bunneh: xkcd
  507. Bunneh Thermostat https://xkcd.com/1912/
  508. jonasw Guus, I learnt in that book that I both want and totally not want a wall with the periodic table of elements :-)
  509. Guus I learnt from that book that I snort when snickering
  510. jonasw :D
  511. Arc im digging through my old code with mod_xmpp now, doing a major overhaul. its actually not terrible, just a bit ... spaghettified
  512. Arc i was actually closing in on a "good" solution but was one step away. instead of chopping up stanzas by the outside, i needed to chop them from the inside.
  513. jonasw what’s mod_xmpp?
  514. Guus "not terrible"
  515. Guus (just a bit spaghettified)
  516. Arc jonasw: it started as an Apache module to do XMPP over Websockets proxying to an xmpp server over C2S
  517. jonasw ah
  518. Arc Guus: i know I'm not unique in, when you work on code you havent touched by a year, you start hating your younger self
  519. Guus Arc: I totally bypass that by simply forgetting that I touched that code. As long as I don't use git blame, I can hate the random anonymous dev that did that terrible thing.
  520. Arc heh
  521. Guus Or, as one of my code-workers used to say: "I must've been drunk."
  522. jonasw Guus, +1 for "I must’ve been drunk."
  523. Arc or high.
  524. jonasw it’s extra funny since I don’t drink alcohol or so at all.
  525. Guus ... that you remember ...
  526. jonasw right.
  527. marc has left
  528. jonasw I also find that this varies greatly by language.
  529. Arc so, I'm looking at chopping up the XML stream by the inner part of the stanza, and parsing/serializing the outer part of the stanza. does that seem sane?
  530. jonasw I’m not sure what "chopping" means and why you need to do it
  531. jonasw (also, jdev@ maybe)
  532. Arc obviously open to edge cases, but I'm still using expat with this, and I'll move to libexi in a later version meaning it'll do a full parse->serialize during the process
  533. Arc jonasw: outer part, eg, <message from="" to="" id="">, vs inside part eg <body xmlns=""> etc
  534. jonasw I guessed that much -- what kind of chopping?
  535. Arc oh man, i havent been in jdev in forever
  536. jonasw (I may be missing context on how websockets work)
  537. Ge0rG has left
  538. Arc jonasw: its semi related to websockets.. chopping actually in regard to APR bucket brigades. so Apache operates streams as a linked list of buffers. when the expat parser hits certain markers, I record the point, and then can recreate/remove part of the stream, then grab the buffer until a certain termination point, passing that along verbatim
  539. jonasw okay, what
  540. Arc one of the bugs in mod_xmpp has always been that, contrary to spec, it hasn't included xmlns="jabber:client" with every stanza
  541. jonasw huh, is that a MUST or SHOULD?
  542. Guus didn't you get all that from 'spaghettified code', jonasw? ;)
  543. Guus namespace can be either on the stream or on each stanza, iirc
  544. jonasw my personal style of test-driven development (which is much less strict than what people probably usually advocate, I don’t know, I’m self-taught) has stopped me from writing spaghettified code
  545. Arc its a MUST because XMPP over WebSockets isn't within a root <stream:stream> element anymore. each stanza is a whole and complete XML document
  546. jonasw I think so too, Guus
  547. jonasw Arc, okay
  548. jonasw I was scared there for a second
  549. Guus https://xmpp.org/rfcs/rfc6120.html#streams-ns-content
  550. Arc most javascript code implementing xmpp over websockets doesn't test for the xmlns="jabber:client"
  551. Zash I'm not so sure that doing that wrapping thing was the best idea
  552. jonasw because I’m pretty sure that aioxmpp doesn’t include xmlns="..." on each stanza
  553. Guus ah, websockets
  554. jonasw Arc, most javascript code doesn’t give a f..thing about namespaces.
  555. jonasw and if you try to do, you run into all kinds of funny browser bugs.
  556. Guus it's annoying to have to move stanzas from a c2s stream to a s2s stream, for the difference in namespace
  557. jonasw Guus, I agree that using different namespaces there was a weird choice
  558. Zash All that because nobody wanted to write a SAX parser for browsers
  559. jonasw asm.js + libxml2?
  560. jonasw or libexpat
  561. Guus off to watch some House of Cards, for board election winning tips.
  562. Zash jonasw: but now it's set in stone forever and ever
  563. jonasw Zash, until XMPP 2.0 comes around or so...
  564. Zash maybe a "just plain XMPP over websockets, no fancy framing" spec?
  565. jonasw wouldn’t that break due to lack of SAX parsers?
  566. Arc i dont think the namespace actually breaks anything in javascript
  567. Zash jonasw: I mean as a separate thing
  568. jubalh has joined
  569. jonasw more separate things?
  570. Arc but yea in WebSockets the second example in guus's URL, "prefix-free canonicalization", is what websockets stanzas SHOULD look like.
  571. Zash The current XMPP-over-WS RFC is basically "XMPP over WS for the Web"
  572. jonasw Zash, is there a use-case for WB not over the Web?
  573. jonasw Zash, is there a use-case for WB not for the Web?
  574. Georg has joined
  575. jonasw Zash, is there a use-case for WebSockets not for the Web?
  576. jonasw damnit
  577. Georg has left
  578. Zash The dark future where only port 443 can be used?
  579. jonasw Zash, don’t support that dark future
  580. jonasw (and don’t walk into the sea)
  581. Zash And where you can't tunnel whatever over TLS on 443?
  582. Zash I don't
  583. Zash It's of course inevitable tho :(
  584. jonasw Zash, stop saying that
  585. jonasw you make me sad
  586. jonasw I don’t want to be sad.
  587. Arc in that particular example, xmpp connect might actually be faster than starttls
  588. jonasw Arc, even faster than XEP-0386?
  589. Arc jonasw: no, because you have the HTTP upgrade handshake
  590. jonasw wait that number is wrong
  591. Arc i know what you mean tho
  592. Arc and i love it.
  593. jonasw XEP-0368 (SRV records for XMPP over TLS)
  594. Arc I mean its a bit rough around the edges, i wish it wasnt needed, that xmpp were to default over TLS
  595. jcbrand has joined
  596. Arc zash is right tho, there's already networks that block all communication that's not on an "approved" protocol on its "accepted" port
  597. Arc HTTPS must be accepted.
  598. jonasw Arc, I’m not sure pushing that fight further up in the ISO/OSI layers will help
  599. Arc we've had some form of XMPP over HTTP proxy to deal with those kinds of networks
  600. Zash It's all just moving negotiation around the layers
  601. jonasw Arc, at some point, either breaking of TLS by those firewalls will becmoe standard or other means of guessing the type of traffic will be used.
  602. Arc at some point those firewalls will also include ALPN sniffing
  603. Zash Arc: Implying that they don't already?
  604. Arc point
  605. waqas has left
  606. Arc i still have a WRT54GL router setup exclusively to proxy all IP traffic over HTTPS because most school districts have only 80 and 443 open, and block *MOST* websites on both. Luckily I own an IP address not currently included in any blocking blacklist
  607. Arc the DC Public Library system was setup similarly. good luck getting a video conference to work
  608. McKael has joined
  609. Arc it was otherwise impossible to do after school programming
  610. Kev has left
  611. Ge0rG has left
  612. moparisthebest > jonasw‎: Zash, is there a use-case for WebSockets not for the Web?
  613. moparisthebest unfortunately yes: https://github.com/moparisthebest/WebSocketSocket
  614. moparisthebest for a brief period my work mitm'd all TLS and I had to tunnel TLS over websocket over mitm'd TLS
  615. moparisthebest luckily I did not write a XEP :P
  616. Arc Guus: also man, given the attendance record for the last board, i dont think you have much to worry about. really.
  617. Arc we clearly need new, energized blood
  618. Arc (even if its me that's out the door for next year)
  619. Guus I'm not worried either way, just wanted to make a House of Cards reference.
  620. Arc heh
  621. Guus because i think that's hillarious.
  622. Guus there.
  623. Arc well, no HoC reference is complete without accusations of gay rape
  624. moparisthebest might be nice to link to https://wiki.xmpp.org/web/Board_and_Council_Elections_2017 in topic
  625. waqas has joined
  626. waqas has left
  627. Arc I pledge that I only sexually harass men when asked to by women who feel harassed by those same men. :-P
  628. Arc PyCon before the CoC was a very dark time.
  629. Ge0rG has left
  630. Valerian has left
  631. Valerian has joined
  632. Valerian has left
  633. Valerian has joined
  634. jubalh has joined
  635. Ge0rG has left
  636. Arc hey Kev how solid is MIX at this point?
  637. moparisthebest pretty solid if you mean too dense to read :P
  638. Arc is there a reference implementation yet?
  639. Arc moparisthebest: did you ever see or read my presentation on xmpp microservices?
  640. zinid Arc: I read your EXI xep
  641. moparisthebest no, got a link to read?
  642. Arc zinid: that's impossible, i havent written it yet
  643. zinid moparisthebest: just read his EXI xep to get the idea ;)
  644. Arc the only exi xep that exists now is garbage
  645. Guus Arc: there's a MIX implementation for Openfire being worked on by Surevine - not sure in what state of completeness it is.
  646. daniel has left
  647. moparisthebest I'm not positive EXI has a purpose outside tiny embedded devices really
  648. Arc the XEP as it stands does not sync the grammar to be used, it relies on the server taking several schemas and compiling a grammar itself, which depending on implementation may or may not match
  649. moparisthebest like mobile phones handle XML just fine
  650. Arc moparisthebest: yes, it absolutely does. the problem is imlementation
  651. Zash Or lack thereof?
  652. moparisthebest why would a phone app want to implement something other than XML though is the question?
  653. Arc of course it does. mobile devices can handle XML, but the overhead is immense. to say "hi" takes 200+ bytes
  654. zinid Arc: ah, you're not the author, ok
  655. moparisthebest certainly no memory or speed reasons anymore
  656. moparisthebest in a world where node.js is a thing, what's 200+ bytes?
  657. moparisthebest a hello world webpage is ~4mb
  658. Zash Bunneh: do #'<message to="arc@example.com" type="chat"><body>hi</body></message>'
  659. Bunneh Zash: 67
  660. zinid Arc: but EXI is a terrible way to fix this issue, at least current XEP is pure shit
  661. zinid abstracting from XML is a way to go
  662. Steve Kille has left
  663. Arc zinid: yes, it absolutely is. which is why i dont want to fix it. i want to write a new one
  664. Zash zinid: Separation of the data and its encoding?
  665. zinid Zash: yeah...
  666. Arc what I'm missing is a manner for the client to transmit the grammar to the server when the server doesn't already have it. there isnt a standard encoding for this, and it must be implementation agnostic
  667. moparisthebest and sounds like a nightmare security-wise, probably
  668. Arc i dont think so. why would it?
  669. zinid why would you need to transfer schemas? do you know any asn.1-base implementation transfering asn.1 definitions?
  670. jonasw I wonder if EXI grammars can be used to create exponential costs (they can contain regexes, right?)
  671. Arc the current XEP does something, security wise, awful in having the server fetch grammar files from arbitrary HTTP URLs. that's begging to be used as a DDoS amplication attack
  672. moparisthebest I vaguely recall discussing this before, I think you said the server would cache these or whatever
  673. moparisthebest or does the client transfer all it's going to use every session?
  674. moparisthebest because then you don't save bytes
  675. Flow Arc, is it so important to do that? I've heard that EXI works reasonably efficient even when not used in schema-informed mode
  676. jonasw moparisthebest, I think the grammars would be keyed by a cryptographic hash sum
  677. Zash What if each party says which namespaces they have schemas of, and then you fall back to some inefficient generic encoding for everything not in the union of known schemasq
  678. Zash s/q$/?/g
  679. Arc Flow: reasonably is relative. you have to transmit all your string tables
  680. Arc Zash: aka non-strict encoding.
  681. moparisthebest so can evil client fill up that cache and/or boot out other in-use ones?
  682. Arc moparisthebest: SHA256 should reasonably cover this, unless you think SHA256 is weak. and the server could have a finite cache.
  683. moparisthebest my point is EXI seems possibly useful in a iot network of trusted super low resource clients or whatever
  684. moparisthebest and useless for desktop or modern phones
  685. moparisthebest (which are now, indistinguishable resource-wise, right?)
  686. Arc you cannot trust iot devices. thats where terrible iot security comes from.
  687. jere has left
  688. jere has joined
  689. moparisthebest so can't I just evict your useful grammar files by sending you a load of useless ones?
  690. Flow moparisthebest, mobile devices may have similar computing power than desktops, but they have other constraints too
  691. moparisthebest even if you do everything correctly and sha256 is secure
  692. Zash LRU cache?
  693. Guus has left
  694. Arc yea
  695. jonasw moparisthebest, use a very limited per-account cache, plus a global cache for shasums which are used by multiple accounts.
  696. jonasw in the worst case the global cache is filled with garbage, but the account-local caches for well-behaving accounts will still work as they should.
  697. moparisthebest jonasw, so then I just connect 2 evil clients and still evict from global?
  698. Zash moparisthebest: Think of EXI as better compression that is safe from https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/
  699. Flow Zash, are you 100% sure that EXI isn't vulnerable to similar form of attacks?
  700. moparisthebest ah yea I think we talked about that too and weren't entirely sure it was safe in all modes
  701. Arc regex btw is an argument against transmitting schemas, its primarily used when defining constrained character sets, and the regex in question isn't a full regex implementation but rather a list of character ranges
  702. Zash Flow: I'm not 100% sure of anything
  703. Zash s/safe/safer/ probably
  704. moparisthebest in fact I think Arc said it was vulnerable in some modes
  705. moparisthebest it's been awhile
  706. Arc moparisthebest: there's vulnerabilities in all XML libraries.
  707. Ge0rG has left
  708. Flow Zash, ok, let me rephrase: Do you expect that EXI is not vulnerable to similar things like CRIME/BREACH?
  709. moparisthebest Arc, sorry I meant vulnerable agaist crime-like compression attacks
  710. Zash Flow: I expect that kind of attack to not be effective against something that roughtly boils down to byte-packing of Enum-like fields
  711. SamWhited has left
  712. Arc well EXI includes the option for including DEFLATE
  713. Arc there are 4 modes; bitpacked, byte aligned, pre-compression, and DEFLATE
  714. Arc the client chooses.
  715. Arc honestly ive found bitpacked to work the best in almost every case
  716. Arc in bitpacked mode there's no huffman table or similar to exploit. it doesn't compress text really at all, only XML structure.
  717. bjc has left
  718. efrit has left
  719. Arc if there's a potential attack on DEFLATE i'd be personally satisfied in including it in a Security section of the XEP with an advisement against using it.
  720. Zash If you make sure that any fields that an attacker can put stuff into are treated as text then it should be more resistant
  721. Arc *nod*
  722. bjc has joined
  723. Arc I believe I remember seeing a case of ascii-only 6-bit encoding, and UTF32, intermixed.
  724. Guus has left
  725. Arc but that's about the only text compression you're going to find
  726. Zash 5 bits should be enough for everyone! :)
  727. Arc until its not. :-P
  728. Arc insert unicode emoticon.
  729. moparisthebest I wonder size-wise how it compares to that xml->json thing, was that a xep?
  730. Flow Arc: It the wrong usage of DEFLATE that opens the side-channel. If the attacked endpoint performs a full flush, i.e. drops the dictionary, on every "channel" change, then it should be safe
  731. Arc Flow: interesting. well, that's something we could address. XML fragments are included, i honestly dont remember how compression was supported.
  732. Zash Flow: I think that should have had a protocol break
  733. Arc i remember i talked to sam a lot about using framing with it, and each stanza a full and complete xml document
  734. Flow Zash, why?
  735. Zash Flow: How does one end know that the other end is doing it Right?
  736. efrit has joined
  737. daniel has left
  738. sonny has joined
  739. moparisthebest yep, no way to tell, no way for server configs to forbid insecure clients
  740. Arc the core of the argument for mobile comes down to this tho, the reason Google dropped XMPP support, according to one of the guys on the Hangouts team, was the massive bandwidth and processing overhead of XML vs binary.
  741. moparisthebest so XML was an engineering problem google couldn't tackle?
  742. Zash Arc: Is that why they pushed for HTTP/2 to be binary?
  743. moparisthebest because marketing sounds far more likely
  744. Arc moparisthebest: XML has a very high processing overhead, and bandwidth overhead, and those are things that can't be just "tackled"
  745. daniel has left
  746. Arc remember when i accidentally crashed gtalk?
  747. Zash Text based protocols do have other valuable properties tho
  748. moparisthebest google engineers didn't know about EXI or some other encoding?
  749. Flow Zash, the other end being the other end of the stream or the xmpp communication?
  750. Zash Flow: Yes
  751. Zash :D
  752. moparisthebest I just find it hard to believe the reason wasn't "we want to lock people into our walled garden"
  753. Flow I'm not sure if in the c2s case, the client needs to know that the server also does full flushes on channel changes
  754. Flow Isn't it possibly sufficent if the client does the right thing?
  755. Arc that was due to an optimization in their UTF8 to protobufs handling. a shortcut was taken, the message i sent jumped their double null termination and propigated.
  756. Zash Flow: How do I, the server, know that you do the right thing if the protocol is identical?
  757. Flow Zash, you don't, but do you care as server if, for the example, the client authenticated your TLS cert?
  758. Arc 𐑓𐑳𐑒 𐑿
  759. Arc that exact message was all it took.
  760. Zash Flow: just <method>zlib-but-better</method> is what I mean
  761. Zash -demoji Arc> 𐑓𐑳𐑒 𐑿
  762. Bunneh Zash: Arc> 𐑓𐑳𐑒 𐑿
  763. Ge0rG has left
  764. McKael has left
  765. Zash Arc: hexdump?
  766. Arc not emoji zash. its shavian https://en.wikipedia.org/wiki/Shavian_alphabet
  767. Flow Zash, sure why not, but you could also do the better part as client with <method>zlib</method>
  768. Flow The client has the incentive to do the right thing, the server doesn't really care, that is what I mean :)
  769. Zash Flow: You think the server should you just let you shoot yourself in the foot? :)
  770. Arc it reads "F-U-K YEW" which is what I wrote in jdev several years ago, when gtalk was brand new, to a google dev who argued that there's "no difference between characters and bytes, thats why we use UTF8"
  771. zinid has left
  772. jonasw what
  773. Flow Zash, the server will happily route my root password in <body/> to your JID, won't it?
  774. Arc whatever optimizations they used, the space there caused their parser to jump the terminating null plus the two "safety nulls" they had in the protobuff reader and cause every gtalk server processing it to crash
  775. Zash Flow: You think the server should just let old non-fixed versions shoot themselves in the foot?
  776. Arc google devs found it as the last message in the queue in every affected server, and they "decoded" the phonetic english
  777. jonasw "safety nulls"
  778. jonasw amazing
  779. Flow Zash, valid point. So you prosody implement zlib-but-better?
  780. Arc this was a long, long time ago, but yes. their "optimized" xml/utf8 decoder had two "safety nulls" to ensure that this wouldn't happen. they didnt expect 4-byte unicode
  781. Flow s/you/would?
  782. jonasw nobody does expect 4byte unicode (*glances at mysql*)
  783. Arc one of the guys from the gtalk team shared that bit with me a long time after it happened.
  784. Flow as mod_compression_safe ;)
  785. Zash Flow: Maybe, if it get's properly XEP'd, but no promises
  786. jcbrand has left
  787. Ge0rG has left
  788. Arc anyway the biggest issue for EXI right now is *how* to communicate the grammar.
  789. Flow Wasn't there even a TLS compression extension for CRIME or something?
  790. Flow Arc, bytestreams?
  791. Flow Or what exactly is the issue? That there is no mechanism defined?
  792. Zash Does it really need to be communicated at all?
  793. Flow My question exactly
  794. Arc Flow: no, no XML schema or otherwise that Ive ever seen.
  795. Arc Flow: the gains for it are huge, especially for initial connection.
  796. daniel has left
  797. Flow I'm sorry but I don't follow. It is not required to exchange grammar to the other endpoint for EXI do work, but it would improve things, right?
  798. Flow Then why not: 1. authenticate 2. upload grammer via base64 encoded stanzs. 3. activate exi 4. bind
  799. Flow Or is the grammar byte format not well defined?
  800. Arc Flow: because you don't want to require the client support text-mode XML. especially with IoT
  801. Flow Arc, ahh ok, Smack's EXI protype would always work on XML, so that is what I thought would everyone do
  802. jonasw Arc, 1. activate exi, 2. upload grammar via exi-encoded stanzas, 3. use grammar, […]?
  803. Flow What is the other thing besides text mode XML? binary XML?
  804. Arc Flow: https://www.w3.org/TR/exi/#informedGrammars
  805. edhelas regarding the Styling XEP proposal, XMPP is a "protocol", this means it has to stay in the backend on my app, telling it what is received and what to send, XMPP is NOT a protocol that enforce how my app should look like, with Markdow, if I want to display my messages without formating I'd have to remove manually all those ugly ~ and *
  806. Arc Flow: EXI uses a lot less code to implement. so yes, text XML vs EXI
  807. Flow Maybe I'm a bit inflexible, but I can't think how a XMPP client/library/server would work with pure non-XML EXI exclusively
  808. jonasw Flow, _xmppexi-server._tcp SRV :-)
  809. jonasw Flow, _xmppexi-client._tcp SRV :-)
  810. Flow It sure is possible
  811. Zash jonasw!
  812. jonasw Zash!
  813. Zash jonasw: I was just typing that
  814. Arc Flow: client connects and sends a EXI header, specifying the schemaId as sha256, if server doesn't support it it'll respond with a default EXI grammar specifying this, client sends a new header to transmit the grammar
  815. Arc it adds a handshake if its unsupported
  816. Arc the grammar can be informed by a schema but includes weights. I might be wrong, and i'd love to be wrong, but I am not aware of an implementation-independent way to specify weighted options in an EXI schema
  817. Arc the grammar is a tree
  818. Ge0rG has left
  819. Arc the tree is scoped by where you are, and the options available at each point. more common options use fewer bits, or even only one bit. eg, end element is commonly transmitted with the first bit
  820. Arc in non-strict encoding there are options at every step, even for elements which have no attributes, child elements, or content
  821. Arc tho that can be transmitted with a single bit, end-element, or "other"
  822. jubalh has joined
  823. efrit has left
  824. Arc ive skimmed a few other EXI libraries for other languages and they all represent this slightly differently.
  825. Steve Kille has left
  826. moparisthebest just, if _xmppexi-client._tcp becomes a thing make it '368 style direct-tls please :)
  827. Arc moparisthebest: you have my whole-hearted agreement there
  828. Steve Kille has left
  829. Ge0rG has left
  830. Steve Kille has left
  831. ralphm has left
  832. Steve Kille has left
  833. uc has joined
  834. moparisthebest has joined
  835. Ge0rG has left
  836. Steve Kille has left
  837. Arc I do not like the idea, tho, of having to invent a XML schema to represent the grammar. because that has to be documented, and it'd be complex.
  838. daniel has left
  839. arc has left
  840. jere has joined
  841. arc has joined
  842. arc has left
  843. arc has joined
  844. arc has left
  845. arc has joined
  846. arc has left
  847. arc has joined
  848. Steve Kille has left
  849. arc has left
  850. arc has joined
  851. Ge0rG has left
  852. jubalh has joined
  853. goffi edhelas: please post your remark on the @standard. The worst with the current proposal, is that you can't even know if you have to remove those ugly ~ and *
  854. Ge0rG has left
  855. Valerian has left
  856. Valerian has joined
  857. Valerian has left
  858. jubalh has joined
  859. moparisthebest You can choose
  860. Steve Kille has left
  861. moparisthebest It basically describes what most clients do anyway
  862. jere has joined
  863. Zash Which "most clients"?
  864. moparisthebest Thunderbird, Gmail?, Hexchat, every IRC client I've *ever* used, people writing text from the beginning of writing text when nothing parsed that except people, gajim
  865. Ge0rG has left
  866. moparisthebest I'm missing a ton surely
  867. moparisthebest Point is, parsed or not, it's well understood by anyone reading it
  868. Zash If everyone understands it already, then do we need to do anything?
  869. Steve Kille has left
  870. daniel has left
  871. moparisthebest Nope that's the beauty of it
  872. moparisthebest You don't have to do anything
  873. daniel has left
  874. arc has left
  875. bjc has left
  876. goffi would be fun to post "ls `date +%Y-%m-%d`-*.xml" in a shell@ MUC room with some of client using this XEP some others not using it.
  877. arc has joined
  878. Zash goffi: I recently learned about `date -uI`
  879. goffi Zash: easier to remember :)
  880. daniel has left
  881. Zash oui
  882. Ge0rG has left
  883. moparisthebest goffi: so highlight but keep characters?
  884. daniel moparisthebest: that's probably for the best
  885. Kev has left
  886. SamWhited I think keeping the characters vs. hiding them is a client decision FWIW, but I really like keeping them (eg. use https://simplemde.com/ for a while, it's very pleasant)
  887. Kev has joined
  888. Kev has left
  889. goffi let's add one more different way of rendering
  890. daniel I just changed my implementation to keep the characters bit display them with 50% opacity
  891. daniel *but
  892. moparisthebest Gajim keeps them
  893. moparisthebest Have to check others...
  894. daniel Yes I'm starting to think that keeping them is for the better. And maybe the xep should specify that (the characters have to be kept)
  895. SamWhited I would be happy to change that to say that you SHOULD keep them, I only didn't do that because I assumed people would complain if I did.
  896. daniel I guess you can never fully avoid false positives
  897. goffi daniel: yes, by properly marking when you use a rich syntax and when you are not
  898. daniel If we decide to keep them we should specify if the style should include the keyword
  899. daniel I opt for not
  900. daniel Because it looks better
  901. SamWhited daniel: I'm not sure what you mean, do you just want to make eg. the * bold but not the word?
  902. moparisthebest goffi: then rewrite all e2e xeps, carbons, and come up with some nightmare to check if the content sent 2 different ways matches in content meaning
  903. moparisthebest Or, keep. It. Simple.
  904. daniel SamWhited, if *bold* will render to <b>*bold*</b> or *<b>bold</b>*
  905. daniel and i think the later looks better
  906. edhelas :')
  907. Zash <b>*bold</b>*
  908. SamWhited daniel: Ah, right. Tentatively I *think* I agree with you.
  909. moparisthebest Good compromise
  910. edhelas we all agree that next to the type="markdown" content we will have an unformated classic <body> tag ?
  911. moparisthebest I think gajim bolds the asterisks too, not on it now though
  912. daniel especially if you then go and display the * with 60% opacity
  913. daniel moparisthebest, yes it does
  914. daniel this is just coming from my personal preference on what i think looks better. not what other clients do
  915. moparisthebest I think it actually doesn't matter but the xep should recommend
  916. SamWhited edhelas: no, I think that's exactly what many people here are trying to avoid
  917. edhelas sic…
  918. edhelas can I also invent my own markup for Post content published in Pubsub ? like in Microblog then ?
  919. edhelas something that is like Markdown but with my own personnal syntax
  920. goffi moparisthebest: no all e2e XEP, OTR and OMEMO, and we already complained about that before. OX is done the right way.
  921. edhelas then people can embed videos and centered texts, but without using XML
  922. goffi moparisthebest: and you'll have to rewrite RFCs if you don't want different contents.
  923. daniel has left
  924. edhelas I'm half serious here, or you go full Markdown or you do nothing, because I don't think developpers with love to write their own parsers again
  925. Ge0rG has left
  926. goffi but at least if the XEP mention a MUST (and not a SHOULD) keep formatting characteres, I would be more OK, as I could safely just ignore it.
  927. moparisthebest goffi: so I'll just use the clients that implement ox then, oh wait that's none...
  928. daniel has left
  929. daniel i can get on board with a MUST. i like strict XEPs anyway
  930. goffi daniel: with a MUST I don't see any issue right now (beside your pasted code being ugly on some client, but that's their choice)
  931. jubalh has left
  932. daniel just updated Conversations master in case someone wants to see how this looks like
  933. goffi actually forcing formatting characteres would not work with escaping. So this would mean removing escaping
  934. jubalh has joined
  935. moparisthebest I think daniel already said that and I agree
  936. moparisthebest Removing escaping that is
  937. SamWhited Yah, removing escaping seems fine to me
  938. SamWhited I'll add that to my TODO list assuming no serious counterpoints are brought up in the list discussion
  939. goffi I've mentionned this in a new message, I'm done with standard@ flooding for today :)
  940. Ge0rG has left
  941. goffi or we are already tomorrow, I can flood again
  942. goffi oh*
  943. goffi (this joke only work in CET timezone)
  944. lovetox has left
  945. arc has left
  946. arc has joined
  947. bra has left
  948. efrit has joined
  949. @Alacer has left
  950. Ge0rG has left
  951. Steve Kille has left
  952. McKael has joined
  953. SamWhited has left
  954. Valerian has joined
  955. Steve Kille has left
  956. jjrh has left
  957. jjrh has left
  958. Ge0rG has left
  959. jjrh has left
  960. jjrh has left
  961. Steve Kille has left
  962. Arc SamWhited: your XEP looks good to me
  963. daniel has left
  964. bjc has joined
  965. Steve Kille has left
  966. thomas_ has left
  967. Ge0rG has left
  968. Steve Kille has left
  969. jjrh has left
  970. jere has left
  971. jere has joined
  972. goffi has left
  973. jjrh has left
  974. Ge0rG has left
  975. SamWhited Arc: thanks! Any oddities you find, things that aren't clear, etc. please let me know!
  976. Steve Kille has left