XSF Discussion - 2017-09-15


  1. lskdjf has left
  2. lskdjf has joined
  3. mimi89999 has joined
  4. la|r|ma has joined
  5. jjrh has left
  6. ralphm has joined
  7. vanitasvitae has left
  8. tim@boese-ban.de has left
  9. tim@boese-ban.de has joined
  10. Tobias has joined
  11. Tobias has joined
  12. Guus has left
  13. lskdjf has joined
  14. Tobias has joined
  15. Zash has left
  16. isotelo has joined
  17. isotelo has left
  18. isotelo has joined
  19. isotelo has left
  20. jere has left
  21. jere has joined
  22. moparisthebest has left
  23. isotelo has joined
  24. isotelo has left
  25. andrey.g has left
  26. andrey.g has joined
  27. Yagiza has joined
  28. andrey.g has left
  29. SamWhited has joined
  30. andrey.g has joined
  31. andrey.g has left
  32. andrey.g has joined
  33. andrey.g has left
  34. andrey.g has joined
  35. andrey.g has left
  36. andrey.g has joined
  37. tim@boese-ban.de has joined
  38. tim@boese-ban.de has joined
  39. andrey.g has left
  40. andrey.g has joined
  41. andrey.g has left
  42. andrey.g has joined
  43. andrey.g has left
  44. andrey.g has joined
  45. andrey.g has left
  46. jere has left
  47. jere has joined
  48. andrey.g has joined
  49. andrey.g has left
  50. andrey.g has joined
  51. andrey.g has left
  52. Wiktor has left
  53. jere has left
  54. jere has joined
  55. Valerian has joined
  56. mimi89999 has left
  57. uc has left
  58. mimi89999 has left
  59. uc has left
  60. jere has left
  61. jere has joined
  62. Guus Link Mauve: to late 😉
  63. Guus has left
  64. Guus has left
  65. waqas has left
  66. jonasw has left
  67. jonasw has joined
  68. uc has joined
  69. Guus has left
  70. jere has left
  71. ralphm has joined
  72. Guus has left
  73. jubalh has joined
  74. Valerian has left
  75. Valerian has joined
  76. ralphm has left
  77. mimi89999 has joined
  78. Guus has left
  79. jubalh has left
  80. fp-tester has joined
  81. ralphm has joined
  82. Valerian has left
  83. fp-tester has left
  84. fp-tester has joined
  85. ralphm has left
  86. ralphm has joined
  87. Guus who can set me up with access to the XMPP Twitter account?
  88. stefandxm has left
  89. stefandxm has joined
  90. intosi has joined
  91. intosi has left
  92. intosi has joined
  93. ralphm has left
  94. Valerian has joined
  95. emxp has joined
  96. stefandxm has left
  97. ralphm has joined
  98. valo has joined
  99. Valerian has left
  100. stefandxm has joined
  101. Valerian has joined
  102. Flow has joined
  103. ralphm has left
  104. daniel has left
  105. daniel has joined
  106. tux has left
  107. tux moparisthebest: I wondered because when I looked up nick hash coloring recently I saw that SHA1 was used to calculate the hash.
  108. jubalh has joined
  109. stefandxm has left
  110. stefandxm has joined
  111. Steve Kille has left
  112. Steve Kille has left
  113. Valerian has left
  114. la|r|ma has joined
  115. jonasw tux: sha was my first choice indeed, but it doesn't really matter
  116. tux are there other implementations which use crc?
  117. jonasw tux: I haven't checked
  118. dwd jonasw, I wondered about CRC32. It feels like it's more prone to accidental collisions. Adler32 is less so, and faster. And MD5 even less so and fast enough these days.
  119. jonasw dwd: Adler doesn't work at all in those input sizes
  120. tux If we could come up with a hint that one of the algorithms is most common for nick hashing I'd vote for that most common algorithm.
  121. stefandxm has left
  122. stefandxm has joined
  123. ralphm has joined
  124. jonasw dwd, it doesn’t matter a lot (except that Adler32 needs much more input to be effective) since we fold the output to 16 bits anyways
  125. jonasw tux, interesting idea; however, my intention was to go with something which is easily available on all platforms and implementations; the zlib crc32 should be such a thing
  126. Steve Kille has joined
  127. jonasw with MD5, we had the concern that it might vanish from crypto libraries at some point
  128. tux For C/C++ that's true. I'm not so sure about other languages.
  129. tux IMHO it would be sensible to have a scheme that is viable to as many (modern) programming languages as possible. We want people to use this.
  130. jonasw most languages have some kind of zlib support, because the zlib is everywhree
  131. jonasw I agree
  132. jonasw I can check how well Adler16 performs. we might be able to seed it properly so that it randomizes, but I’m not too confident in that. the adler concept is a bit weak on the mixing side
  133. dwd jonasw, I think CRC32 predates zlib, actually.
  134. jonasw dwd, sure
  135. tux The fine thing about CRC ist that it is easy to implement
  136. jonasw is it? I never managed to :)
  137. dwd Huh. CRC is 1961, CRC32 is 1975.
  138. jonasw dwd, I’m referring to zlib crc32 because of the specific zlib polynomial used
  139. tux At least I did some working implementations. ;)
  140. Martin has joined
  141. la|r|ma has joined
  142. la|r|ma has joined
  143. jonasw tux, in my defense, the platform I tried it on was VHDL ... soo ... ;-) but given that there exist libre implementation of the zlib CRC32, it would be easy to port to any language, if there are really any which don’t have access to a CRC32 implementation with that polynomial
  144. tim@boese-ban.de has joined
  145. tux jonasw: yes, it is. Maybe it makes sense to link to a normative description for CRC32. I'll have a look during the weekend.
  146. edhelas do you guys know XMPP clients that are doing Jingle with WebRTC ?
  147. jonasw yes, I hadn’t found one
  148. jonasw edhelas, jitsi maybe?
  149. jonasw tux, if you could find a nice normative reference for the zlib CRC32 or CRC32 in general and the zlib polynomial, that would be of great help
  150. dwd jonasw, No, Jitsi-the-desktop-client doesn't interop with JitsiMeet.
  151. jonasw dwd, aw, pity
  152. jonasw put them on a stake and burn them with flames
  153. jonasw :)
  154. dwd edhelas, The only ones I know of are bespoke Web ones.
  155. la|r|ma has joined
  156. jonasw (just kidding)
  157. edhelas dwd, that's what I thought
  158. la|r|ma has joined
  159. intosi The benefit of MD5, is that every XMPP implementation already knows how to do that.
  160. dwd jonasw, "Classic" Jingle VOIP doesn't interop with WebRTC Jingle VOIP.
  161. edhelas so we don't have any client, except Movim, that implement Jingle using WebRTC
  162. jonasw intosi, isn’t it a MUST NOT by now? :)
  163. dwd intosi, True. Also there are loads of implementations everywhere.
  164. intosi jonasw: sure, but legacy.
  165. jonasw intosi, will legacy implement new things?
  166. dwd jonasw, In security cases.
  167. intosi Fine, then propose SHA-1, which is definitely required, for things like CAPS.
  168. jonasw and I’m sure those implementations depend on lib*ssl for those; will lib$whateverssl support MD5 in the future?
  169. jonasw (SHA1 will probably work better, indeed)
  170. jonasw (support-wise)
  171. dwd jonasw, There's a number of issues with MD5, but the worst one now is speed. MD5 is so fast that brute-forcing is practical. At the same time, and increasing number of people are using it in this kind of thing because of that.
  172. jonasw dwd, fun fact: sha1 is faster than md5
  173. Tobias fun fact: BLAKE2 is faster than SHA1 :)
  174. jonasw dwd, https://sotecware.net/images/dont-puush-me/9n701UwrIuU2NFuTexy7rFpu3Auf7zbQlVsEyFTVqAM.png
  175. intosi If speed of nickname colour hashing is going to be your issue, I wonder how your client is to keep up in such a room with all the messages ;)
  176. Steve Kille has left
  177. Steve Kille has joined
  178. jonasw intosi, frankly, *I* do not care much about it; my client will cache the colors anyways.
  179. jonasw but I heard that it’s not that trivial for other implementations.
  180. dwd jonasw, I thought it was only faster where the silicon supports it? But in any case, SHA-1 sounds good then.
  181. jonasw dwd, the difference seems to small for silicon support to be the reason in this graph, I think. so yeah, seems to be faster
  182. jonasw (not that it’d matter on our input sizes)
  183. intosi I like hashing methods that are already in use in code ;)
  184. dwd intosi, To be honest, I'd go for SHA-1 ver CRC32-with-some-polynomial just for the ease of specification.
  185. intosi Yeah
  186. dwd intosi, To be honest, I'd go for SHA-1 over CRC32-with-some-polynomial just for the ease of specification.
  187. intosi I tried to calculate my nick colour yesterday evening, and wasn't sure whether I was using the correct polynomial.
  188. jonasw I’m all in for that
  189. intosi As in some environments, folks just mention it's a crc32, and never bother telling you which one it actually is ;)
  190. jonasw the question is: shall I update the protoxep or update it when it goes experimental?
  191. dwd intosi, On this client, it is, rather fittingly, orange.
  192. daniel 👍for sha1
  193. intosi Orange is good.
  194. dwd intosi, You say that, but it's not working out well for the US.
  195. intosi dwd: yeah, but they're holding it wrong.
  196. jonasw lol
  197. dwd jonasw, Just wait.
  198. jonasw dwd, great, that fits my schedule better
  199. tux Yeah, we should provide a sample set for software testing. With hashing methods it's always kind of a guess whether the results are correct.
  200. jonasw tux, there are test vectors
  201. tux Ah, okay.
  202. tux jonasw: hm.. You mean test vectors for CRC32 or for the Nick coloring?
  203. jonasw the latter
  204. jonasw has left
  205. tux Ack
  206. jubalh has joined
  207. andrey.g has joined
  208. andrey.g has left
  209. edhelas has left
  210. edhelas has joined
  211. andrey.g has joined
  212. lskdjf has joined
  213. andrey.g has left
  214. andrey.g has joined
  215. Vaulor has joined
  216. andrey.g has left
  217. andrey.g has joined
  218. andrey.g has left
  219. andrey.g has joined
  220. andrey.g has left
  221. aluisyo has left
  222. fp-tester has left
  223. edhelas has left
  224. nyco has left
  225. fp-tester has joined
  226. edhelas has joined
  227. andrey.g has joined
  228. andrey.g has left
  229. Alex has joined
  230. Wiktor has joined
  231. Wiktor has joined
  232. Wiktor has left
  233. Wiktor has joined
  234. andrey.g has joined
  235. Wiktor has joined
  236. andrey.g has left
  237. Wiktor has joined
  238. Link Mauve edhelas, Jitsi Meet is a Jingle client, just like Movim.
  239. Wiktor has left
  240. Wiktor has joined
  241. Wiktor has left
  242. Wiktor has left
  243. Wiktor has joined
  244. Wiktor has left
  245. Wiktor has joined
  246. Wiktor has joined
  247. jonasw 'p
  248. Wiktor has joined
  249. lumi has joined
  250. Wiktor has joined
  251. Wiktor has left
  252. Wiktor has joined
  253. ralphm has joined
  254. stefandxm has left
  255. stefandxm has joined
  256. tim@boese-ban.de has joined
  257. ralphm has joined
  258. jubalh has left
  259. jubalh has left
  260. edhelas has left
  261. edhelas has left
  262. andrey.g has joined
  263. Guus Link Mauve - do you think Jitsi Meet will do interop Jingle? I know that they recently added p2p support, but otherwise, everything typically flows through the videobridge. Jingle is involved there, but is it functional outside of their own solution?
  264. Guus It'd be great if they do though
  265. la|r|ma has joined
  266. edhelas does the visioconference part of Jitsi do even pass by Jingle ?
  267. edhelas looks like their solution is not a full XMPP based solution
  268. Holger edhelas: The Videobridge is XEP-0340.
  269. stefandxm has left
  270. stefandxm has joined
  271. edhelas Holger, okay
  272. Guus oh, there's definately a lot of XMPP in there. I'm not sure if it's interoperable, though, with non-Jitsi clients
  273. stefandxm has left
  274. stefandxm has joined
  275. jubalh has joined
  276. Wiktor has left
  277. dwd Guus, I believe that Talky uses it well enough.
  278. jabberatdemo has joined
  279. lskdjf has joined
  280. lskdjf has joined
  281. Wiktor has joined
  282. jonasw dwd,
  283. jonasw (sorry, wrong window and tab completion fubar)
  284. Guus (he's talking about you in another window, Dave)
  285. la|r|ma has left
  286. jabberatdemo has left
  287. sonny has joined
  288. Ge0rG has joined
  289. ralphm has joined
  290. Guus has left
  291. jere has joined
  292. moparisthebest has joined
  293. moparisthebest has joined
  294. tim@boese-ban.de has joined
  295. Flow has left
  296. Ge0rG has left
  297. jubalh has joined
  298. ralphm has left
  299. daniel has left
  300. Guus has left
  301. daniel has left
  302. Ge0rG has left
  303. fippo talky is now based on a bunch of deferred standards :-)
  304. MattJ is currently in a call on Talky
  305. MattJ I might have to end it now I know this
  306. SouL Haha
  307. Guus has left
  308. Guus has left
  309. Alex has left
  310. moparisthebest has joined
  311. daniel has left
  312. daniel has joined
  313. Ge0rG has left
  314. fippo mattj: there is also a proprietary namespace used. nothing critical at least :-p
  315. Guus has left
  316. moparisthebest has joined
  317. Flow has joined
  318. jubalh has joined
  319. Guus has left
  320. moparisthebest fippo: isn't everything based on deferred standards? :'(
  321. Ge0rG has left
  322. Guus has left
  323. Guus has left
  324. moparisthebest even the 2017 compliance suite specifies deferred standards, or at least ones that have been in last call for months and should be deferred
  325. fippo the internet runs on drafts
  326. jonasw has left
  327. mimi89999 fippo: 👍
  328. Ge0rG has left
  329. Flow has left
  330. lskdjf has joined
  331. lskdjf has joined
  332. Guus has left
  333. jere has joined
  334. jere has joined
  335. stefandxm has left
  336. stefandxm has joined
  337. waqas has joined
  338. jere has left
  339. jere has joined
  340. Ge0rG has left
  341. Neustradamus has left
  342. Ge0rG has left
  343. daniel has left
  344. daniel has left
  345. Alex has joined
  346. daniel has left
  347. Guus has left
  348. mimi89999 has left
  349. Wiktor has joined
  350. la|r|ma has left
  351. stefandxm has left
  352. Ge0rG has left
  353. Vaulor has left
  354. stefandxm has joined
  355. Ge0rG has left
  356. daniel has left
  357. daniel has joined
  358. ralphm has joined
  359. waqas has left
  360. tux has left
  361. waqas has joined
  362. mimi89999 has left
  363. Ge0rG has left
  364. jonasw regarding the coloring thing, I’m still uncertain whether using the roster name or the JID is preferable. using the roster name has the advantage that multiple JIDs to the same contact can have the same color. using the JID has the advantage that the color is stable even if I change the name.
  365. jonasw opinions?
  366. sonny has joined
  367. jonasw using the JID also has the advantage that the three different Martins in my roster could have different colours
  368. jonasw and I wonder how relevant the "I have the same person with multiple different JIDs in my roster" use-case really is
  369. sonny has joined
  370. Zash has left
  371. lumi has joined
  372. Ge0rG has left
  373. SamWhited I'm a fan of the JID. Although it would be a bit weird because toys have to do the bare for 1:1s and the resourcepart only for mucs probably.
  374. jonasw "toys"?
  375. Zash Weren't public semi-anon MUCs an edge case only used by nerds who nobody cares about (ie us)?
  376. jonasw for MUC the situation is indeed so that the nickname is used if the muc is anonymous, otherwise roster name or JID, depending on what we decide on
  377. SouL JID sounds really nice to me.
  378. jonasw I also tend to JID by now, even though I first thought that roster name would be nice
  379. Ge0rG No opinion from me
  380. SamWhited *sigh* phones
  381. SamWhited I think that was supposed to be "you would have to use…"
  382. Wiktor has joined
  383. SamWhited Also what Zash said though; probably best to just ignore MUC to keep things simple. The XEP already *looks* too long for such a simple client feature (I read through it, it seems fine, but initial impressions are everything and I'm already concerned that it looks complicated enough that clients won't bother trying to implement it)
  384. jonasw SamWhited, I thnik on the other hand that many XEPs are way too short because they lack detail.
  385. jonasw the part on MUC is literally three short paragraphs, I wouldn’t omit that
  386. Ge0rG SamWhited: MUC nick coloring was the actual reason for inventing that XEP
  387. jonasw we can move the test vectors to some appendix or so and not put each case in its own section, that’ll shorten the TOC a bit
  388. SamWhited jonasw: It's not a big deal, it looks like a really good XEP overall, I just worry about these things.
  389. stefandxm has left
  390. jonasw thanks, and ok
  391. Ge0rG has left
  392. jonasw (also the thing isn’t that simple anymore once you consider color vision deficiencies and such)
  393. Ge0rG Maybe I should read the XEP as well, instead of just relying on what I think it contains.
  394. SouL Ge0rG, haha :)
  395. jonasw :D
  396. Zash Ge0rG: Blasphemy!
  397. Ge0rG SouL: something I had to explain to a customer today: as a Ph.D., you learn to make confident statements about something you have no idea of.
  398. Zash Ge0rG: You better only look at the examples!
  399. Zash -xkcd 793
  400. Bunneh Physicists https://xkcd.com/793/
  401. Ge0rG actually, I just rely on jonasw writing down what we discussed at length multiple times ;)
  402. SamWhited I pretty much do only look at the examples the first time I "read" an XEP. I figure that's what client devs are going to do, so if they're confusing or lead to the wrong behavior it's probably something that should be fixed
  403. jonasw what hurt most while writing the XEP was trying to stick to en_US ;-)
  404. Ge0rG Yeah, blaming client devs for (even major) failures is very disappointing and surprisingly hard work. BTDT.
  405. Neustradamus has left
  406. SamWhited I'm not actually sure how to read that; if it sounded like I was blaming them, I'm not. I think that it's fine for them to only glance at the examples and it's our (XEP authors') fault if we don't communicate clearly with our examples.
  407. SouL Ge0rG, super good one :)
  408. Ge0rG SamWhited: you are absolutely right, my remark was rather tangentially related than a direct answer to yours
  409. SamWhited *nods* I think we're on the same page
  410. Ge0rG It just made me remember the Carbons attribution issue from earlier this year, and I think the Carbons spec is rather clear.
  411. Ge0rG At least in that regard.
  412. SamWhited ah yah, that one was bad
  413. Ge0rG And so were the reactions from developers.
  414. Ge0rG And so were the reactions from many developers.
  415. Steve Kille has left
  416. SamWhited Were they? The one or two issues I submitted (Mcabber and Jitsi, I think) were pretty good
  417. Steve Kille has left
  418. Ge0rG SamWhited: some developers just didn't care
  419. SamWhited figures
  420. SamWhited *sigh* oh well.
  421. jonasw Ge0rG, did you send them carbons claiming to be from themselves to confuse them? :)
  422. tim@boese-ban.de has left
  423. Ge0rG jonasw: I sent some, but not to the devs
  424. Ge0rG Or at least not claiming their identities
  425. Ge0rG has left
  426. jonasw why not? :( ;-)
  427. Ge0rG It didn't appear to me, back then
  428. Ge0rG Instead I claimed to be an unpopular political character.
  429. tim@boese-ban.de has left
  430. stefandxm has joined
  431. jere has joined
  432. Ge0rG has left
  433. uc has joined
  434. goffi has joined
  435. lumi has left
  436. daniel has left
  437. uc has joined
  438. daniel has joined
  439. goffi has left
  440. Guus has left
  441. fp-tester has left
  442. fp-tester has joined
  443. Ge0rG has left
  444. ralphm has joined
  445. goffi has joined
  446. goffi has left
  447. ralphm has left
  448. Ge0rG What would be the least inelegant way to implement a self-ping feature on MUC JIDs? It needs to be discoverable via caps info, and it needs to be something that doesn't have meaning yet. Maybe a certain IQ to the bare JID?
  449. dwd Discoverable by caps? That's hard.
  450. jonasw Ge0rG, make a feature var which defines a ping to the bare MUC jid to only succeed iff the requesting resource is joined and return <item-not-found/> or somtehing otherwise
  451. jonasw Ge0rG, make a feature var which defines a ping to the bare MUC jid to only succeed iff the requesting resource is joined and return <item-not-found/> or some other error if the user is not joined
  452. Ge0rG jonasw: that would probably make sense.
  453. jonasw currently how that ping behaves is undefined-ish I think
  454. Ge0rG we need to feature-check it anyway.
  455. jonasw yupp
  456. Ge0rG jonasw: currently I'm pinging my own participant JID, which is a double-RTT va banque game.
  457. jonasw I know
  458. Ge0rG jonasw: I think that ping IQ semantics are defined already, and changing them is actually incompatible. Maybe a dedicated IQ makes more sense?
  459. goffi has joined
  460. jonasw Ge0rG, is the ping to a bare MUC jid really defined?
  461. jonasw daniel, you have some insight in the OMEMO topic, right? can you confirm that this is the result of the recent discussion which should be merged? https://github.com/xsf/xeps/pull/482
  462. dwd Ge0rG, What are you doing to do with this ping?
  463. Ge0rG jonasw: Oh, right. IQs must go to a full JID
  464. dwd Ge0rG, Erm, no.
  465. Ge0rG dwd: I need to figure out if I'm still joined to a MUC
  466. dwd Ge0rG, OK. And if you're joined, you'll do nothing, and if not, you'll rejoin?
  467. Ge0rG has left
  468. Ge0rG dwd: exactly
  469. dwd Ge0rG, So - and I admit this has inefficiencies - as a first step, could you not just send presence?
  470. jonasw Ge0rG, the ping to the MUC component domain makes sense, the ping to the occupant JID does too, the ping to the bare MUC jid doesn’t really
  471. Ge0rG dwd: no.
  472. goffi has left
  473. dwd Ge0rG, Why not?
  474. Ge0rG dwd: sending presence is a "groupchat 1.0 leagacy" join
  475. Ge0rG dwd: sending presence is a "groupchat 1.0 legacy" join
  476. Ge0rG jonasw: not practically, but technically.
  477. jonasw Ge0rG, sure
  478. dwd Ge0rG, Well, yes, you'd get unwanted history potentially. But if that's *quite* close, is it somewhere to build from?
  479. jonasw and if the behaviour is practically undefined, you can re-define it to be something useful with a feature var
  480. Ge0rG dwd: the MUC implementation might mark me as a legacy client.
  481. blabla has left
  482. jonasw Ge0rG, and sending presence with <x/>?
  483. Ge0rG jonasw: would do a full rejoin every time.
  484. jonasw ugh
  485. jonasw even for a joined client?
  486. Ge0rG jonasw: you remember my last PR? ;)
  487. jonasw yeah
  488. Ge0rG it was exactly about that.
  489. jonasw do implementations behave that way?
  490. Ge0rG I have no idea. I think prosody trunk might.
  491. dwd jonasw, Rejoin handling? M-Link, Openfire, possibly ejabberd.
  492. dwd Ge0rG, When you say "might mark me as a legacy client", what do you think this would do? No servers I'm aware of do this.
  493. Ge0rG dwd: I have no idea. I consider "legacy groupchat" to be something to burn with fire, or at least to avoid.
  494. Ge0rG dwd: if I were God of XSF, I'd completely remove legacy groupchat from 45.
  495. Zash I sorta wanna remove it from Prosody. IIRC it'd simplify somewhat.
  496. goffi has joined
  497. Ge0rG dwd: I have no idea if anybody is still using it, or if there are dragons inside the implementations.
  498. Ge0rG MUC got enough hairy corner cases without groupchat legacy.
  499. SamWhited What is "legacy groupchat"? I don't see any mention of that grepping for "legacy" in 0045
  500. Ge0rG Though I must admit, "Groupchat Legacy" would make for an awesome title for an XSF-themed movie. Or computer game. Or rock band.
  501. jonasw SamWhited, search for Groupchat 1.0 Protocol
  502. Ge0rG SamWhited: https://xmpp.org/extensions/xep-0045.html#enter-gc
  503. goffi has left
  504. SamWhited ahh, yes, thanks. Kill it with fire.
  505. jere has left
  506. jere has joined
  507. dwd Ge0rG, The only difference is the join, though. Once you're joined, its exactly the same.
  508. Ge0rG SamWhited: I volunteer to make the diff to 45, provided that council will signal pre-approval.
  509. dwd Ge0rG, So by periodically reflashing presence, you're just risking getting the wrong history.
  510. Zash dwd: Like gmail did?
  511. Ge0rG dwd: will my presence get forwarded to all participants?
  512. Ge0rG dwd: I have a MUC with histsize=500.
  513. dwd Zash, Ah, gmail re-sent a '45 join periodically as well. That was mega-annoying.
  514. Zash Rebroadcasted all directed presence too iirc
  515. dwd Ge0rG, Yes, and also erk. But I think it's an interesting place to start.
  516. jonasw I think a ping is a cleaner solution. nothing wrong if it’s with a feature var, is there?
  517. Zash In such a way that if they changed nickname, they'd periodically switch back and forth
  518. dwd Ge0rG, If your server both maintains, and always sends by default, 500 lines of history there's something badly wrong somewhere.
  519. dwd Zash, Indeed. I'm not suggesting that.
  520. Ge0rG dwd: I totally could live with a <presence><limited history><I'mtherealready></p>
  521. dwd Ge0rG, In principle, a server could/should not rebroadcast presence where its identical anyway. But that's a small point.
  522. Ge0rG dwd: I think that having 500 lines of history in the default buffer beats MUC-MAM.
  523. SamWhited Ge0rG: I can't speak for anyone else, but I'd be all for that.
  524. Ge0rG dwd: it's a small O(N²) point.
  525. SamWhited Others are probably more conservative since it is in draft, after all.
  526. Ge0rG Eternal draft.
  527. Zash <presence><{muc}x><{mam}history plz/><//
  528. SamWhited Ge0rG: Is there some reason to move it on past draft?
  529. dwd SamWhited, The fallback is it's a rejoin/rebroadcast.
  530. Ge0rG dwd: there is another problem with the presence approach: if you lost sync, you'll get the history (mkay), and you'll get a full participant list. But you need to know in advance that you are receiving a full list so you can clear your previous list.
  531. Ge0rG dwd: otherwise you'll end up with stale participants in your cache
  532. Ge0rG has left
  533. jjrh has left
  534. Ge0rG and race conditions will prevent any sensible workaround
  535. jonasw right
  536. Ge0rG Besides of all that, some client (library) implementations don't expect to receive a join from a MUC they are already joined into. So they might lose sync anyway.
  537. dwd Ge0rG, Well a library written to use a periodic presence as a ping-or-rejoin will work fine, surely?
  538. Ge0rG dwd: yes, unless you hacked the ping-or-rejoin code on top of an old library. ;)
  539. Ge0rG Maybe it would be cleaner to respond to a non-x-ed <presence> with an error, so the client can rejoin?
  540. Vaulor has joined
  541. Ge0rG But still, we have the O(N²) problem that every client, sending a periodic presence, will flood everybody else.
  542. jjrh has left
  543. Ge0rG Can anybody gather stats on "groupchat 1.0" usage?
  544. MattJ https://matthewwild.co.uk/uploads/gc_pinger.html
  545. MattJ (not an answer to your question about usage stats)
  546. dwd Ge0rG, "If I write my code badly it might be written badly" is not a tremendous argument.
  547. dwd MattJ, You're suggesting that this be done server-side instead?
  548. MattJ I'm merely dropping a historical anecdote :)
  549. Ge0rG dwd: it's not a tremendous argument indeed. Please focus on my two material arguments instead.
  550. dwd Ge0rG, Excellent. So if the client is dropped from the MUC without its knowledge, and simply sends an updated presence, then you'll be inadvertantly getting the same problem but this time it's unavoidable.
  551. Ge0rG dwd: right. But this is another argument.
  552. MattJ Server-side doesn't tell the client that they are disconnected, does it even help? It helps them not be de-synced when they rejoin, but only if the server happened to ping them in that time period
  553. dwd Ge0rG, The only solution would be to, before updating presence, send your IQ-based ping beforehand. But then there's a minute race condition, which you'll no doubt be disproportionally upset about.
  554. Ge0rG dwd: I don't think it is wrong to focus on corner cases when aiming to design robust protocols.
  555. Ge0rG dwd: if we design a 90% protocol, we'll end up in the place we are in today.
  556. MattJ +1, corner cases matter
  557. Ge0rG where my desktop client at home disconnects from a MUC because I'm joined to the same MUC with the same nickname from my mobile device when on the go.
  558. Zash If we design a 100% protocol, we'll be done in the year 3000?
  559. MattJ Zash, then we can release 0.10
  560. dwd Ge0rG, Excellent. So I've given you a corner case which your design fails to address, and my (sketched) design does.
  561. Ge0rG Zash: fixing MUC isn't _that_ complicated. If we can get rid of legacy.
  562. dwd Ge0rG, Legacy meaning gc?
  563. jonasw dwd, and how to solve the issue with inconsistent occupant state?
  564. MattJ I'm inclined to agree with finally dropping GC 1.0 support
  565. jonasw when I’m re-sending presence and in fact I’m doing a join, I don’t get presence notifications for occupants which left in the meantime
  566. Ge0rG dwd: I'm not saying your design is bad, or that it's wrong to follow that approach. I'm just pointing out that your sketch won't work.
  567. jonasw I think both designs don’t work
  568. Ge0rG dwd: in the current context, legacy means GC. But I'd be glad to kick out more legacy when appropriate.
  569. jonasw and ideally there would be an IQ based join which either fails or succeeds and only after the IQ returns you get the presence updates, so that it’s fully synchronous
  570. dwd jonasw, Sure, but that's MIX.
  571. Ge0rG jonasw: I'm okay with a presence based join that succeeds as soon as you get a presence reflection.
  572. Ge0rG has left
  573. Ge0rG Which is MUC.
  574. tux has joined
  575. ralphm has joined
  576. uc has joined
  577. Ge0rG dwd: I could imagine a periodic presence with yet another additional element, where the server would respond with a presence-unavailable, followed by a full rejoin.
  578. Ge0rG dwd: and all of this would depend on a feature flag.
  579. Ge0rG dwd: and the server wouldn't forward such a presence to other participants, unless it contains a delta.
  580. Guus has left
  581. Ge0rG dwd: the presence-unavailable (or any other response marker) is needed to make the client flush the cached data.
  582. jonasw Ge0rG, "succeeds as soon as you get a presence reflection"? I don’t understand that part
  583. goffi has joined
  584. Ge0rG jonasw: a MUC always reflects presence to you. So once you get that reflected presence from the MUC, you know you are inside.
  585. Ge0rG reflects your own presence, that is.
  586. jonasw sure, but ... how do you know the occupants list when you didn’t know that you re-joined?
  587. Ge0rG jonasw: "the presence-unavailable (or any other response marker) is needed to make the client flush the cached data."
  588. jonasw ahh
  589. dwd (Or: The occupant data could have a delay tag in)
  590. jonasw dwd, does that help you to identify which occupants have left in the mean time?
  591. Ge0rG 1. MUC advertises "smart-resync" 2. you join, normally. 3. you send a <presence><smart-resync> 4a. you get a presence reflection 4b. you get a presence-unavailable followed by a full resync
  592. dwd No, but you know when the end of the occupant list is, so that should be OK.
  593. Ge0rG dwd: you need to know the beginning of the occupant list.
  594. Lance has joined
  595. Ge0rG dwd: so essentially you must strip <delay> from inbound client presences
  596. dwd Ge0rG, What?
  597. Ge0rG and if the client receives a presence with a delay, it knows that it's at the beginning of a rejoin.
  598. lovetox has joined
  599. Zash Was there a status code for 'this means you just joined'
  600. dwd Ge0rG, I suppose you could do it that way. Or spot your own afterward and clear any untainted. Or ...
  601. Ge0rG Zash: yes, it will be in your own reflected presence at the end of the occupant list
  602. Ge0rG dwd: RACE CONDITIONS!!1!!
  603. Ge0rG Sorry, I just couldn't resist.
  604. dwd Ge0rG, I don't think there are any there.
  605. dwd Ge0rG, Unless you're getting stanzas out of order.
  606. Ge0rG dwd: any participant presence you receive after sending your smart-resync-presence might be either old presence from your previous MUC session or the beginning of the occupant list. No way to know.
  607. Ge0rG So what you could do is to put all the presences into a queue until you get your own reflection. Or the subject.
  608. Ge0rG I think it's your own with the appropriate status code
  609. Ge0rG has left
  610. dwd Ge0rG, You'd get your own afterward, certainly. And any presence you get after a smart-resync is either un-delayed, in which case it's the first stanza(s) you'll get and it potentially stale but who cares because you'll notice this later - or else is delay marked, and therefore part of a resync.
  611. Ge0rG dwd: unless it is a delayed presence because the sending client added a delay element.
  612. dwd Ge0rG, The only pattern, in other words is: *non-delay [ *delay ] your-reflection
  613. dwd Ge0rG, Yes, but there's a thing in delays to tell you who is delaying.
  614. Ge0rG dwd: and I need to put all the non-delayed presences into a queue and unwind them once I realize it's a resync.
  615. Ge0rG dwd: that's not how you design a robust protocol.
  616. Ge0rG dwd: and really, what's wrong with injecting a presence-unavailable?
  617. dwd Ge0rG, No you don't.
  618. MattJ So what isn't solved by <presence type="error"> if the client isn't in the room and they send presence with no <x>?
  619. dwd Ge0rG, The moment you see a presence delayed by the MUC, you're rejoining. You weren't before, you now are.
  620. Ge0rG dwd: okay, you try to make it work in a backward compatible way. I appreciate that. But it's not easy.
  621. Ge0rG MattJ: groupchat 1.0
  622. MattJ and apart from that?
  623. dwd MattJ, Breaks compatibility with gc, of course. Whether that's now safe to do I'm not sure, though it feels dangerous.
  624. Zash What clients do gc?
  625. MattJ I'm willing to do it
  626. Zash What *clients* do it, not counting advanced users manually typing XML in netcat (like I do sometimes)?
  627. MattJ I don't mind if 20 year-old clients break, and probably some bots. Any actively maintained clients likely do the right thing already or will be fixed promptly
  628. Ge0rG MattJ: you could create stats on GC1 clients.
  629. Ge0rG MattJ: presence-error would also be a nice way to make GC1 client devs care.
  630. Zash Prosody trunk MUC logs such conditions already
  631. Zash Debug level, but still
  632. Ge0rG most of it will probably be resync problems.
  633. dwd Does/did gc have any discovery? I suspect not.
  634. Zash Ge0rG: It logs joins without <x> and presence with <x>
  635. Ge0rG Okay, I'm late for my weekend already. Thanks very much for the productive discussion. Maybe you can bring up killing GC in the next council meeting?
  636. MattJ I think that's the best solution, and I'm willing to move forwards on it as a server dev
  637. Ge0rG I think that would be a good first step, with the second step being an explicit smart-resync presence feature
  638. Ge0rG &
  639. MattJ fg
  640. Martin has left
  641. SamWhited I'll add it to the agenda when I get back to my desk if someone else hasn't already (leaving this here as a note to myself)
  642. dwd kill -STOP %1
  643. MattJ Now he'll never get home
  644. dwd MattJ, "SIGSTOP cannot be caught or ignored."
  645. jonasw SamWhited, did it for you
  646. SamWhited Thanks
  647. tux has joined
  648. jonasw who has power over https://hub.docker.com/r/xmppxsf/xeps/builds/ ?
  649. jonasw I could use someone hitting a retry button.
  650. jonasw that build failed due to some remote network issue
  651. dwd jonasw, Randomly update the README?
  652. jonasw good point, I wanted to merge my readme stuff anyways
  653. goffi has left
  654. Yagiza has left
  655. Ge0rG has left
  656. efrit has joined
  657. jjrh has left
  658. jjrh has left
  659. Ge0rG has left
  660. ralphm has left
  661. ralphm has joined
  662. jere has joined
  663. vanitasvitae has left
  664. vanitasvitae has left
  665. jjrh has left
  666. jjrh has left
  667. lumi has joined
  668. lumi has joined
  669. lumi has joined
  670. jjrh has left
  671. tim@boese-ban.de has left
  672. fp-tester has joined
  673. valo has joined
  674. jjrh has left
  675. Ge0rG has left
  676. ralphm has left
  677. efrit has left
  678. jjrh has left
  679. fp-tester has joined
  680. jjrh has left
  681. Ge0rG has left
  682. tux has joined
  683. tux has joined
  684. dwd has left
  685. jjrh has left
  686. Guus has left
  687. Vaulor has left
  688. Ge0rG has left
  689. daniel has left
  690. daniel has joined
  691. ralphm has joined
  692. Guus has left
  693. Guus has left
  694. SouL has left
  695. Ge0rG has left
  696. tux has left
  697. moparisthebest woah jonasw warning: failed to load external entity "http://xsltsl.sourceforge.net/modules/node.xsl" the xep build depends on sourceforge being up? that sounds like a bad bet
  698. moparisthebest can it be fixed to not depend on any remote entities?
  699. Guus Hey, did Thiago become active again?
  700. jjrh has left
  701. fippo nice change @ jingle relay nodes.
  702. Ge0rG has left
  703. lovetox has left
  704. lovetox has joined
  705. jjrh has left
  706. uc has left
  707. fippo mattj: remember that xep-0215 is much better though!
  708. Steve Kille has joined
  709. SamWhited has left
  710. pep. edhelas, DNS resolution failed on movim.eu
  711. edhelas which DNS ?
  712. pep. movim@conference.movim.eu/pep.: cancel: Server-to-server connection failed: DNS resolution failed
  713. uc has joined
  714. pep. I can dig it from here actually :/
  715. pep. And from my server
  716. edhelas IPv6 maybe ?
  717. pep. works as well
  718. Steve Kille has left
  719. Ge0rG has left
  720. moparisthebest has joined
  721. Ge0rG has left
  722. SamWhited has left
  723. SamWhited has joined
  724. jere has joined
  725. ralphm has joined
  726. jjrh has left
  727. Ge0rG has left
  728. jjrh has left
  729. sonny has left
  730. sonny has joined
  731. jjrh has left
  732. SamWhited has left
  733. SamWhited has joined
  734. moparisthebest has joined
  735. Ge0rG has left
  736. lskdjf has joined
  737. lskdjf has joined
  738. moparisthebest has joined
  739. ralphm has joined
  740. Alex has left
  741. Ge0rG has left
  742. la|r|ma has left
  743. Ge0rG has left
  744. lskdjf has joined
  745. lskdjf has joined
  746. moparisthebest has joined
  747. Tobias has left
  748. moparisthebest has joined
  749. Ge0rG has left
  750. ralphm has joined
  751. Ge0rG has left
  752. jere has joined
  753. ralphm has joined
  754. Ge0rG has left
  755. ralphm has left
  756. ralphm has joined
  757. moparisthebest has joined
  758. ralphm has left
  759. ralphm has joined
  760. moparisthebest has joined
  761. tim@boese-ban.de has joined
  762. fp-tester has left
  763. Ge0rG has left
  764. fp-tester has joined
  765. Steve Kille has joined
  766. jere has joined
  767. sonny has joined
  768. Steve Kille has left
  769. daniel has left
  770. Ge0rG has left
  771. tim@boese-ban.de has left
  772. Alex has left
  773. Guus has left
  774. Ge0rG has left
  775. tux has left
  776. tux has joined
  777. fp-tester has joined
  778. moparisthebest has joined
  779. moparisthebest has joined
  780. Steve Kille has joined
  781. Ge0rG has left
  782. waqas has left
  783. SamWhited has left
  784. Guus has left
  785. Ge0rG has left
  786. waqas has joined
  787. lskdjf has left
  788. Ge0rG has left
  789. la|r|ma has left
  790. la|r|ma has joined
  791. lskdjf has joined
  792. waqas has left
  793. waqas has joined
  794. lovetox has left
  795. Ge0rG has left
  796. SamWhited has left
  797. lskdjf has joined
  798. Ge0rG has left