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/

    Thermostat
    Thermostat
  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