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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  485. jonasw

    even for a joined client?

  486. Ge0rG

    jonasw: you remember my last PR? ;)

  487. jonasw


  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


  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


  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


  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


  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


  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