XSF Discussion - 2018-01-03

  1. Steve Kille has left
  2. la|r|ma has joined
  3. winfried has left
  4. winfried has joined
  5. dwd has left
  6. dwd has left
  7. dwd has left
  8. moparisthebest has left
  9. moparisthebest has joined
  10. lskdjf has joined
  11. dwd has left
  12. goffi has left
  13. lumi has joined
  14. la|r|ma has left
  15. jere has joined
  16. la|r|ma has left
  17. la|r|ma has joined
  18. la|r|ma has left
  19. lskdjf has joined
  20. Tobias has joined
  21. xnyhps has joined
  22. tux has left
  23. tux has joined
  24. Ge0rG has left
  25. dwd has left
  26. Tobias has joined
  27. dwd has left
  28. matlag has left
  29. matlag has joined
  30. matlag has left
  31. matlag has joined
  32. jere has joined
  33. moparisthebest has left
  34. moparisthebest has joined
  35. dwd has left
  36. ralphm has joined
  37. @Alacer has left
  38. @Alacer has joined
  39. moparisthebest has left
  40. moparisthebest has joined
  41. Ge0rG has left
  42. valo has left
  43. valo has joined
  44. sonny has joined
  45. moparisthebest has left
  46. Tobias has left
  47. Tobias has joined
  48. moparisthebest has joined
  49. efrit has joined
  50. dwd has left
  51. Tobias has left
  52. Tobias has joined
  53. ralphm has joined
  54. SouL has left
  55. efrit has left
  56. ralphm has joined
  57. tim@boese-ban.de has joined
  58. SouL has left
  59. valo has joined
  60. valo has joined
  61. Steve Kille has left
  62. Steve Kille has joined
  63. Steve Kille has left
  64. Steve Kille has joined
  65. lumi has joined
  66. zinid has joined
  67. lumi has joined
  68. sonny has joined
  69. ralphm has left
  70. Guus has joined
  71. Steve Kille has left
  72. Steve Kille has left
  73. Steve Kille has joined
  74. moparisthebest has left
  75. Guus has left
  76. Guus has joined
  77. ralphm has left
  78. Guus has left
  79. goffi has joined
  80. ralphm has joined
  81. ralphm has joined
  82. mimi89999 has joined
  83. Ge0rG has joined
  84. Guus has joined
  85. zinid has left
  86. zinid has joined
  87. tux has joined
  88. tux has joined
  89. Guus has left
  90. Guus has joined
  91. daniel has left
  92. uc has joined
  93. zinid has left
  94. winfried has left
  95. winfried has joined
  96. uc has joined
  97. Guus has left
  98. Alex has joined
  99. Guus has joined
  100. goffi has left
  101. winfried has left
  102. winfried has joined
  103. goffi has joined
  104. Guus has left
  105. Guus has joined
  106. uc has joined
  107. uc has joined
  108. Steve Kille does anyone have any idea why a fetch from github xsf/xeps is failing?
  109. Steve Kille I want to get the latest, so I can start on Dave's comments
  110. jonasw care to give more details?
  111. jonasw error message setc
  112. jonasw error messages etc
  113. Steve Kille Git GU says it is fetching, works for ages, and then complains connection timed out
  114. Steve Kille Has been fine before
  115. Steve Kille fatal: unable to access 'https://github.com/xsf/xeps/': Failed to connect to github.com port 443: Timed out
  116. jonasw hmm works for me
  117. jonasw can you open that https url manually in your browser?
  118. la|r|ma has joined
  119. Steve Kille fine in my browser
  120. Steve Kille pushes of commits to Guithub was working fine yesterday
  121. Steve Kille I did the fetch from a different network two days ago, so I guess it could be our proxy
  122. Guus has left
  123. Zash Proxies seem like a sensible thing to blame
  124. @Alacer has left
  125. @Alacer has joined
  126. daniel has left
  127. SouL has left
  128. SouL has left
  129. zinid has joined
  130. Steve Kille yup - proxy
  131. SouL has left
  132. Ge0rG has joined
  133. daniel has left
  134. daniel has joined
  135. Guus has joined
  136. lskdjf has joined
  137. SouL has left
  138. uc has joined
  139. uc has joined
  140. SouL has left
  141. zinid has left
  142. SouL has left
  143. valo has left
  144. valo has joined
  145. zinid has joined
  146. SouL has left
  147. marc has left
  148. matlag has left
  149. matlag has joined
  150. ralphm has joined
  151. Martin has joined
  152. uc has joined
  153. sonny has joined
  154. uc has joined
  155. intosi has left
  156. intosi has joined
  157. ralphm has left
  158. edhelas I'm thinking of extending 0277, having 2 nodes, one for public publication, one restricted to presences
  159. edhelas has left
  160. edhelas has joined
  161. @Alacer has left
  162. @Alacer has joined
  163. Martin has left
  164. Alex has left
  165. oachkatzl has joined
  166. oachkatzl has left
  167. oachkatzl has joined
  168. uc has left
  169. uc has joined
  170. vanitasvitae has left
  171. la|r|ma has joined
  172. la|r|ma has joined
  173. Alex has joined
  174. goffi edhelas: we have since talked in private, but for the record I have tried the 2 nodes options years ago, and it doesn't work that well. The fine permission tuning (aka items permissions) is the best option from my experience. I still need to propose a protoXEP, but lacking time to write one.
  175. vanitasvitae has joined
  176. uc has joined
  177. uc has joined
  178. uc has joined
  179. uc has joined
  180. @Alacer has left
  181. @Alacer has joined
  182. oachkatzl has left
  183. moparisthebest has joined
  184. SouL has joined
  185. ralphm has left
  186. Syndace has left
  187. Syndace has joined
  188. ralphm has joined
  189. matlag has left
  190. matlag has joined
  191. dwd has left
  192. dwd has joined
  193. uc has joined
  194. uc has joined
  195. uc has left
  196. uc has joined
  197. lskdjf has joined
  198. uc has joined
  199. uc has joined
  200. SamWhited has joined
  201. zinid has left
  202. zinid has joined
  203. lskdjf has joined
  204. sonny has left
  205. sonny has joined
  206. Ge0rG has left
  207. Ge0rG has left
  208. mimi89999 has joined
  209. ralphm has joined
  210. lskdjf has joined
  211. lskdjf has joined
  212. Ge0rG has left
  213. zinid has left
  214. daniel has left
  215. marc has left
  216. edhelas I'd like to know if we can deprecate 0084 and go back to the good old "presence notification" for vcards
  217. edhelas we have 2 solutions and I though after 5 years that everyone will move to a full PEP solution
  218. edhelas that didn't worked
  219. edhelas also it doesn't work for MUC vcards
  220. edhelas also barelly no client is implementing it https://nl.movim.eu/?about#caps_widget_tab
  221. SamWhited has left
  222. moparisthebest edhelas, did you see inputmice's talk about it?
  223. edhelas I was at the 34c3
  224. tim@boese-ban.de has left
  225. edhelas which talk ?
  226. moparisthebest might have been that one, doesn't that fix the problem server-side ?
  227. edhelas I didn't been to his talk then
  228. edhelas what was it about
  229. moparisthebest I'm trying to find a link but not having any luck yet
  230. edhelas https://github.com/iNPUTmice/talks/blob/master/2017_12_27_-_jabber_xmpp_the_past_the_presence_and_the_future.md
  231. Alex has left
  232. moparisthebest yep that's it specifically https://github.com/iNPUTmice/talks/blob/master/2017_12_27_-_jabber_xmpp_the_past_the_presence_and_the_future.md#avatars
  233. moparisthebest it's not perfect, but you see what happens when we try to create perfect, we get MIX, and it never goes anywhere
  234. lskdjf has joined
  235. edhelas yup
  236. moparisthebest can I officially propose the future cut-down-to-useable-proportions MIX replacement be called MUX ?
  237. edhelas I just read about MUC-SUB https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/
  238. edhelas it's quite great, also retro-compatible
  239. zinid has joined
  240. moparisthebest ah will read, I was only aware of https://xmpp.org/extensions/inbox/muc-light.html
  241. moparisthebest but retro-compatible sounds great
  242. daniel has left
  243. Ge0rG We could probably make a MUC-actor thing where your account joins MUCs on your behalf.
  244. Ge0rG Maybe even without changing the protocol.
  245. moparisthebest and requiring all user's servers to be updated would be a good test for how feasible mix is :)
  246. Ge0rG There are voices saying that the big servers will update fast.
  247. goffi is there any server MIX implementation based on current specs ? I know about the one from Ejabberd but it was on first draft and I don't think it has been maintained.
  248. edhelas same
  249. edhelas Muc/Pub is used by several clients in production as well
  250. moparisthebest which ones?
  251. winfried has left
  252. zinid has left
  253. zinid has joined
  254. Holger moparisthebest: Commercial ones.
  255. zinid has left
  256. zinid has joined
  257. zinid has left
  258. zinid has joined
  259. Alex has joined
  260. daniel has left
  261. dwd goffi, We have a MIX implementation, but it's not quite the current spec.
  262. goffi dwd: is it public, can we test it ?
  263. dwd goffi, It is public-ish - in surevine's github in our Openfire fork. You'll need a real database, though - the embedded one doesn't work.
  264. dwd goffi, Also, no presence, since we didn't need that.
  265. goffi dwd: ok cool. Would be nice to have a simple wiki page with links to current implementations, so the day I want to start client implementation I can select a server one.
  266. la|r|ma has left
  267. la|r|ma has joined
  268. moparisthebest has joined
  269. moparisthebest you need 2 server implementations though
  270. moparisthebest uh, in that your server needs support, as well as a mix component
  271. moparisthebest so when looking for server support you need those 2 different things right?
  272. MattJ It means MIX is going to take years (that's years + whatever time it takes to get implementations released)
  273. MattJ Because MIX is not usable by the ordinary user if they can't just invite anyone on their contact list, and most people are going to be running from OS packages
  274. moparisthebest years or never, like privacy lists, original archiving etc
  275. MattJ Privacy lists was pretty widely implemented, back in the day, actually :)
  276. MattJ Just with a terrible UI
  277. Ge0rG Damn, where's my "told you so" stamp?
  278. moparisthebest especially if you have something simple that solves 99% of use cases and is backwards compatible, like maybe this muc-sub thing, haven't read it yet
  279. edhelas Ge0rG you didn't had enough ink to stamp last time, need to buy more
  280. edhelas muc-sub seems to be a good 50%-50% between the two XEPs
  281. Syndace has left
  282. lovetox has joined
  283. daniel has left
  284. goffi has left
  285. Ge0rG has left
  286. Steve Kille has left
  287. Steve Kille has left
  288. uc has joined
  289. uc has joined
  290. ralphm has left
  291. Steve Kille has joined
  292. SouL has joined
  293. uc has joined
  294. SouL has left
  295. dwd has left
  296. uc has joined
  297. Flow moparisthebest: which "future cut-down-to-useable-proportions MIX replacement"?
  298. uc has joined
  299. jjrh has left
  300. had-hoc has left
  301. had-hoc has joined
  302. __ has joined
  303. __ -____-
  304. __ has left
  305. had-hoc has left
  306. lumi has joined
  307. dwd has left
  308. moparisthebest Flow, all I know is it should be called MUX
  309. moparisthebest I'm just assuming there will be one in the great tradition of the XSF
  310. Ge0rG Flow: is it possible that smack will never cache entity caps for JIDs it didn't previously receive presence from? https://github.com/igniterealtime/Smack/blob/master/smack-extensions/src/main/java/org/jivesoftware/smackx/disco/ServiceDiscoveryManager.java#L510
  311. Holger has left
  312. Ge0rG has left
  313. had-hoc has joined
  314. Flow moparisthebest, i'm not sure about it, but I would really like a little competition
  315. had-hoc has left
  316. jjrh has left
  317. had-hoc has joined
  318. Flow Ge0rG, possible, I think Smack should maybe calcucate the version itself
  319. Ge0rG Flow: yeah. Just noticed that in smack3, I only have persistent cache items from my own caps
  320. Flow I can tell from the variable naming that this is veery old code ;)
  321. Ge0rG it's actually the same in smack3:P
  322. jjrh has left
  323. had-hoc has left
  324. Flow looks like a good incentive to start on caps2
  325. ralphm has left
  326. had-hoc has joined
  327. jjrh has left
  328. dwd has left
  329. had-hoc has left
  330. had-hoc has joined
  331. Flow on a second look, that code locks correct, and is covered by integration tests
  332. ralphm has joined
  333. Ge0rG has left
  334. had-hoc has left
  335. had-hoc has joined
  336. had-hoc has left
  337. had-hoc has joined
  338. valo has joined
  339. valo has joined
  340. winfried has joined
  341. ralphm has joined
  342. had-hoc has left
  343. had-hoc has joined
  344. Guus has left
  345. Guus has joined
  346. SamWhited has joined
  347. goffi has joined
  348. SouL has left
  349. had-hoc has left
  350. Tobias has joined
  351. SouL has left
  352. Guus has left
  353. had-hoc has joined
  354. Guus has joined
  355. had-hoc has left
  356. SamWhited has left
  357. had-hoc has joined
  358. daniel has left
  359. daniel has joined
  360. had-hoc has left
  361. had-hoc has joined
  362. sonny has joined
  363. sonny has joined
  364. had-hoc has left
  365. zinid has left
  366. had-hoc has joined
  367. zinid has joined
  368. Syndace has joined
  369. pep. reading daniel's talk re avatars. Does 0153 really requires you to download your own avatar on every connection? If you have it locally you can just hash it and compare to what the server is sending you, right?
  370. sonny has left
  371. sonny has joined
  372. daniel pep.: how do you know it hasn't been changed by another client?
  373. pep. You hash the one you have locally and compare it, if it's not the same your redownload it
  374. pep. I mean there's not need to download it _everytime_
  375. pep. right?
  376. zinid has joined
  377. moparisthebest don't you have to download it to calculate the hash?
  378. pep. You have a copy locally right?
  379. pep. What's different from PEP here?
  380. moparisthebest how does that tell you what's on the server?
  381. pep. "A client MUST NOT advertise an avatar image without first downloading the current vCard", that's meh
  382. pep. Indeed.
  383. pep. Isn't there a way that the server sends back a hack of the current avatar instead?
  384. lovetox what do you mean with is there a way
  385. lovetox like with a current xep?
  386. sonny has joined
  387. lovetox no, but it would probably be trivial to add to 0153 that the server sends the hash on request
  388. pep. Well, not 0084, as it doesn't work in groupchats
  389. lovetox ..
  390. pep. yeah
  391. lovetox but downloading a vcard is really nothing i would sweat about
  392. zinid has left
  393. pep. I don't know, daniel put it in "downsides" in his talk
  394. lovetox i guess on mobile it is sometimes a downside
  395. lovetox and its not particular pretty
  396. pep. yeah but it's not like it couldn't be fixed
  397. lovetox but nothing that would stop me implementing it
  398. moparisthebest pep., more trivial than not changing the xep and having a server plugin just do it all for you? :P
  399. moparisthebest either way you are writing code and deploying it to a server
  400. moparisthebest I like daniel 's approach better
  401. pep. moparisthebest, sure, things take time. But 153 has been out for a while now
  402. lovetox but 153 is historical
  403. lovetox i dont think these are meant to be changed
  404. pep. Hmm.
  405. pep. How do you change that? You fork it?
  406. moparisthebest what problem are you trying to solve
  407. lovetox and do a pr, but i guess this will not make it :)
  408. moparisthebest why would you try to solve it with a xep change, client change, and server change
  409. moparisthebest when you could solve it with just a server change, and end up with a simpler client using less bandwidth?
  410. pep. lovetox, yeah, honestly I don't really care
  411. pep. I have enough GB on my plan so that it doesn't matter at all
  412. moparisthebest it's not really that, it's the added time a connection takes in my opinion
  413. pep. I just find sad that we have to go through convoluted ways (PEP -> vcard) to fix this kind of things
  414. moparisthebest the other way sounds far more convoluted
  415. pep. How so? Making people update their software ?
  416. pep. How so? Making people update their software?
  417. daniel > I just find sad that we have to go through convoluted ways (PEP -> vcard) to fix this kind of things I find that extremely simple and straightforward
  418. daniel And it's already supported by the important servers
  419. moparisthebest pep., again "xep change, client change, and server change, and clients use more bandwidth" vs "server change (major servers already support it)"
  420. moparisthebest which sounds easier and more preferable?
  421. pep. So that means if I want to implement a server, I'll have to support both 0153 _and_ 0084 (and PEP) for avatars? Plus also the PEP -> vcard thing
  422. pep. How isn't this convoluted
  423. pep. (No I'm not planning to implement a server, still I hope you get my point)
  424. moparisthebest ok, well you have to support both 0153 _and_ 0084 anyway
  425. moparisthebest I guess you might complain about converting, but a sane structure would have you storing them in the same place anyway?
  426. Guus has left
  427. Guus has joined
  428. pep. I'm complaining about the workarounds mostly. I'm not sure how fixing a historical XEP works, but adding a "Server returns vcard hash" wouldn't be difficult
  429. pep. heh, the compliance suite doesn't state 153 at all?
  430. moparisthebest also your argument seems to be make it slightly easier to write a new server by making all existing servers add features to existing historical plugins
  431. moparisthebest still not buying it
  432. moparisthebest when in doubt go with the simplest thing that works
  433. moparisthebest KISS
  434. pep. moparisthebest, not "historical plugins" no, just "mostly used solutions", just like edhelas showed above, 0084 isn't really implemented anywhere
  435. pep. Also 0084 doesn't work anyway, re groupchats
  436. daniel I'd rather you not write a new server in the first place
  437. pep. daniel, sure
  438. pep. s/mostly/most/
  439. moparisthebest I'm just waiting for Link Mauve to write a server in rust so I can switch
  440. pep. I don't think xmpp-rs is going to be designed for servers
  441. moparisthebest I don't care what library he uses :)
  442. pep. heh. I don't think he's mad enough to do that anyway
  443. Link Mauve You never know!
  444. pep. I know you're mad, don't worry
  445. moparisthebest on a side note, why are the majority of major xmpp servers written in crazy esoteric languages :)
  446. Link Mauve :p
  447. moparisthebest does that say something about the people who use xmpp :'(
  448. pep. Link Mauve, any idea what's become of Freyskeyd and his talk of writing a server?
  449. pep. https://github.com/Freyskeyd/xmpp-rs/tree/master/server
  450. pep. fn it_works() {} :)
  451. Link Mauve pep., he seems to have stopped working on his library altogether.
  452. moparisthebest "It's goal is to be fully tested and usable."
  453. moparisthebest he is halfway there (it's fully tested)
  454. pep. it even says it works!
  455. Guus has left
  456. moparisthebest is anyone aware of any xmpp test domains for client and/or server devs to test proper srv fallback etc ?
  457. moparisthebest similar to like http://www.dnssec-failed.org/ for testing dnssec
  458. moparisthebest many, possibly most, clients and such don't end up falling back correctly or at all turns out
  459. moparisthebest like they fallback if the port isn't listening, but not if it sends invalid xml, or doesn't support ciphers it likes, or various other errors
  460. suzyo has joined
  461. Holger moparisthebest: You're suggesting Rust for an internet service and complaining about esoteric language choices?
  462. moparisthebest no I think rust would neatly fall in there right now
  463. moparisthebest (the esoteric lang category)
  464. Holger pep.: I think it's right to have the complexity on the server side.
  465. Link Mauve moparisthebest, you can use OpenFire or Tigase, for a very non-esoteric language.
  466. Link Mauve There is also Jabberd and Jabberd2.
  467. Link Mauve People have been writing one in PHP and one in JS too IIRC.
  468. Link Mauve I would know, I’ve written one in JS.
  469. Link Mauve (Never again. ;_;)
  470. moparisthebest I'd guess ejabberd/prosody/openfire is most of the public network though, and if so, that's 66% esoteric langs :P
  471. moparisthebest and my guess is openfire is distant 3rd there
  472. Tobias has joined
  473. ralphm has left
  474. Kev has joined
  475. @Alacer has left
  476. @Alacer has joined
  477. SouL has joined
  478. ralphm has joined
  479. Alex has joined
  480. winfried has left
  481. jere has joined
  482. uc has joined
  483. uc has joined
  484. la|r|ma has joined
  485. SamWhited has left
  486. ralphm has joined
  487. suzyo has joined
  488. mimi89999 has joined
  489. pep. Holger, what annoys me the most is that, from what I understand, we're just choosing the path of least resistance for the features we want out there. Yes we are mostly volonteers, and I get we don't have all the time we want. Plus users are running old software (debian I'm looking at you), etc., Still I don't think we should stop here
  490. pep. "That only has to be implemented server-side, let's prefer that over X", I'm not really into this kind of thought
  491. moparisthebest pep., good luck getting anything actually put into use then :) (looking at you MIX yet again)
  492. pep. daniel, do you have stats btw of what version of Conversations people are using?
  493. jere has joined
  494. pep. Or maybe services like jabberfr do? (Link Mauve, mathieui)
  495. daniel pep.: no
  496. mathieui pep., I don’t think there’s a prosody module for that yet
  497. Holger pep.: The amount of madness a client developer new to XMPP is confronted with is insane. Avatar support is a very basic IM feature. We should be able to show him a simple XEP he needs to implement to make avatars 'just work'. If server-side hacks help with hiding the compatibility madness from him, I'd prefer those hacks.
  498. jere has joined
  499. pep. For this particular case I'm not sure what's best, implement PEP _and_ 0084 _and_ 0153, or fix 0153 to have the small fix we talked about earlier, and implement only that
  500. pep. As a client developer, maybe I'm biased :P
  501. moparisthebest so implement only the historical one?
  502. moparisthebest seems questionable
  503. Alex has left
  504. pep. moparisthebest, if you come up with a non-historical just for the sake of it, that has the same features, and make people use it, why not
  505. moparisthebest I'm also under the impression the pep one is easier for clients
  506. Holger Well but by now both are implemented.
  507. pep. That's why people are trying to shoehorn everything into PEP?
  508. ralphm has joined
  509. moparisthebest it's done, accept the fact and move on 😛
  510. Holger I don't know why they are. I would've been opposed to that if I had been around back then.
  511. pep. moparisthebest, I would if it worked
  512. Holger I'm just saying we have both now, and we either deal with that or we break interop.
  513. moparisthebest omemo requires it too
  514. moparisthebest probably other things I don't really know about?
  515. daniel Neither 84 nor 153 are particularly difficult to implement.
  516. daniel On the client side that is
  517. pep. daniel, it's just an example
  518. daniel For what?
  519. pep. For what I said to Holger above, we're just choosing the path of least resistance, "because this way we'll have it implemented and usable no matter how ugly/workaroundy that is"
  520. pep. That's just a feeling, I would be happy to be proven wrong
  521. sonny has left
  522. sonny has joined
  523. daniel I have quite the opposite impression. The Xsf is the textbook example of perfect is the enemy of good. That's why we have so many widely deployed XEPs stuck in experimental.
  524. moparisthebest if you want to fully reinvent the wheel pull a matrix :)
  525. daniel That's why we have been working on mix for three years now
  526. pep. moparisthebest, that's not my point.
  527. pep. daniel, true
  528. moparisthebest I agree daniel my impression is we create a complex monster of a xep where all possible usecases have to be fulfilled rather than a much simpler solution that fills 90% of usecases
  529. pep. so.. MIX and avatars are two extremes? :p
  530. daniel pep., moparisthebest: fwiw I'm not trying to be overly negative towards mix here. But choosing the complex solution over the much simpler one that fills 90% of the use cases is a pattern I see in a lot of XEPs
  531. pep. daniel, gotcha. I guess I wasn't around long enough
  532. uc has joined
  533. winfried has left
  534. zinid has joined
  535. uc has joined
  536. jjrh has left
  537. jjrh has left
  538. uc has joined
  539. pep. Anybody implementing 0306?
  540. pep. -xep 306
  541. Bunneh pep.: Extensible Status Conditions for Multi-User Chat (Standards Track, Deferred, 2016-06-07) See: https://xmpp.org/extensions/xep-0306.html
  542. uc has joined
  543. jjrh has left
  544. moparisthebest has left
  545. moparisthebest has left
  546. MattJ pep., none that I know of
  547. marc has left
  548. ralphm has joined
  549. had-hoc has left
  550. edhelas has left
  551. edhelas has joined
  552. lumi has left
  553. goffi has left
  554. goffi has left
  555. valo has joined
  556. jjrh has left
  557. jjrh has left
  558. daniel has left
  559. goffi has left
  560. jere has joined
  561. tux has left
  562. dwd has left