XSF Discussion - 2017-12-18

  1. daniel has left
  2. Ge0rG has left
  3. marc has left
  4. Ge0rG has left
  5. ralphm has left
  6. Ge0rG has left
  7. tux has left
  8. tux has joined
  9. sonny has left
  10. sonny has joined
  11. Ge0rG has left
  12. sonny has joined
  13. sonny has joined
  14. Ge0rG has left
  15. sonny has left
  16. sonny has joined
  17. Ge0rG has left
  18. lumi has joined
  19. Ge0rG has left
  20. sonny has left
  21. sonny has joined
  22. Ge0rG has left
  23. Ge0rG has left
  24. la|r|ma has joined
  25. daniel has left
  26. daniel has joined
  27. @Alacer has left
  28. @Alacer has joined
  29. Ge0rG has left
  30. daniel has left
  31. Ge0rG has left
  32. Ge0rG has left
  33. Ge0rG has left
  34. la|r|ma has joined
  35. la|r|ma has joined
  36. la|r|ma has left
  37. daniel has joined
  38. Zash has left
  39. Ge0rG has left
  40. daniel has left
  41. daniel has joined
  42. daniel has left
  43. daniel has joined
  44. @Alacer has left
  45. @Alacer has joined
  46. Ge0rG has left
  47. Ge0rG has left
  48. lskdjf has joined
  49. SamWhited has left
  50. Ge0rG has left
  51. arc has left
  52. uc has left
  53. uc has joined
  54. Ge0rG has left
  55. daniel has left
  56. daniel has joined
  57. lskdjf has joined
  58. Ge0rG has left
  59. daniel has left
  60. daniel has joined
  61. Ge0rG has left
  62. @Alacer has left
  63. @Alacer has joined
  64. arc has joined
  65. Ge0rG has left
  66. la|r|ma has joined
  67. Ge0rG has left
  68. daniel has left
  69. daniel has joined
  70. Ge0rG has left
  71. Ge0rG has left
  72. Syndace has left
  73. Syndace has joined
  74. Ge0rG has left
  75. arc has joined
  76. Ge0rG has left
  77. daniel has left
  78. daniel has joined
  79. daniel has left
  80. daniel has joined
  81. daniel has left
  82. daniel has joined
  83. Ge0rG has left
  84. matlag has joined
  85. Ge0rG has left
  86. @Alacer has left
  87. @Alacer has joined
  88. Ge0rG has left
  89. daniel has left
  90. daniel has joined
  91. goffi has joined
  92. ralphm has left
  93. zinid has left
  94. zinid has joined
  95. Ge0rG has left
  96. ralphm has left
  97. ralphm has joined
  98. Guus has joined
  99. Ge0rG has left
  100. Ge0rG has left
  101. uc has left
  102. uc has joined
  103. ralphm has left
  104. daniel has left
  105. ralphm has joined
  106. Ge0rG has left
  107. Ge0rG pep.: the message you sent to standards@ re MUC and presence=error. Did you have multiple clients joined to the MUC at that time with MSN?
  108. remko has joined
  109. Ge0rG has left
  110. Holger has left
  111. Guus has left
  112. Guus has joined
  113. Guus has left
  114. @Alacer has left
  115. @Alacer has joined
  116. Ge0rG has left
  117. ralphm has joined
  118. sonny has left
  119. sonny has joined
  120. vanitasvitae has left
  121. Ge0rG has left
  122. goffi has left
  123. vanitasvitae has joined
  124. goffi has joined
  125. marc has joined
  126. Ge0rG has left
  127. Guus has joined
  128. sonny has left
  129. sonny has joined
  130. ralphm has joined
  131. marc has left
  132. marc has joined
  133. Ge0rG has left
  134. uc has joined
  135. daniel has left
  136. lumi has joined
  137. sonny has left
  138. sonny has joined
  139. ralphm has left
  140. marc has left
  141. marc has joined
  142. ralphm has joined
  143. @Alacer has left
  144. @Alacer has joined
  145. daniel has left
  146. xnyhps has joined
  147. daniel has left
  148. uc has joined
  149. Ge0rG has left
  150. marc has left
  151. ralphm has joined
  152. Steve Kille has left
  153. Ge0rG has left
  154. daniel is there are requirement on how short shortnames have to be?
  155. jonasw nafaik
  156. Martin has joined
  157. Martin has left
  158. marc has left
  159. ralphm has joined
  160. Ge0rG has left
  161. stefandxm has left
  162. daniel has left
  163. Steve Kille has joined
  164. marc has left
  165. Guus has left
  166. Guus has joined
  167. ralphm has joined
  168. Ge0rG has left
  169. marc has left
  170. stefandxm has joined
  171. moparisthebest has joined
  172. moparisthebest has joined
  173. Guus has left
  174. daniel has left
  175. stefandxm has left
  176. marc has left
  177. Ge0rG has left
  178. Guus has joined
  179. ralphm has joined
  180. jonasw when marc is done-ish with his XEP, I should start a MUC Invite URL XEP which would be something like PARS but for MUCs
  181. jonasw (integrated with both PARS and what marc did)
  182. marc jonasw, that's nice, I had the same idea
  183. marc :)
  184. jonasw and then I’ll have to work on prosody to make all that happen and then I can actually invite people to XMPP
  185. SouL +1
  186. marc jonasw, are you prosody dev?
  187. jonasw no
  188. jonasw but writing a module isn’t that hard :)
  189. marc yes, I know
  190. marc I looked at bit into the prosody code
  191. daniel has left
  192. Ge0rG has left
  193. marc has left
  194. Ge0rG jonasw: what's wrong with xmpp:muc@service?join ?
  195. daniel has left
  196. zinid has joined
  197. marc Ge0rG, the action parameter :P
  198. Ge0rG marc: what about it?
  199. marc Ge0rG, just kidding and a bit trolling ;)
  200. Ge0rG marc: awww. now I'm really disappointed. You promised you'd never troll.
  201. jonasw Ge0rG, members-only MUC
  202. marc yes, just a second and I thought it's obviously :)
  203. Ge0rG jonasw: fake it by adding a password.
  204. jonasw Ge0rG, that still doesn’t give people an account and presence subscription to me
  205. Ge0rG jonasw: wait, so you want an account, prsence subscription AND a MUC?
  206. jonasw Ge0rG, yes.
  207. jonasw integrate all the things
  208. Ge0rG jonasw: one-push-warm-and-cozy?
  209. jonasw what?
  210. Ge0rG Also including Mr. Robot trivia?
  211. SouL Hahaha
  212. jonasw I have no Mr. Robot trivia
  213. Ge0rG one-tap would've been more appropriate, I suppose
  214. nyco has left
  215. Ge0rG jonasw: once you have them onboarded and added to your roster, you can just invite them into the MUC
  216. jonasw Ge0rG, true
  217. jonasw Ge0rG, that requires me to be online to make it work smoothly though
  218. Ge0rG jonasw: that's all client-side-PARS over again
  219. jonasw exactly
  220. jonasw token-based MUC invitation woul dbe neat
  221. ralphm has joined
  222. Alex has joined
  223. daniel > I have no Mr. Robot trivia I stopped watching after the fight club scene. That was a bit too much for me
  224. Ge0rG I stopped watching after the second episode. It was playing out way too slowly, and the main actor was reminding me of the Frodo performance in LotR.
  225. zinid Ge0rG: same here, two episodes was my PR
  226. Ge0rG But sorry for OTing this MUC once again.
  227. Ge0rG jonasw: you could use the `preauth` token in MUC invitations as well.
  228. Ge0rG I'm still struggling to create a yaxim UI to invite users into a MUC.
  229. Ge0rG has left
  230. zinid Ge0rG: just steal it somewhere
  231. ralphm has joined
  232. Guus has left
  233. Guus has joined
  234. zinid has left
  235. zinid has joined
  236. Steve Kille has left
  237. stefandxm has joined
  238. Ge0rG has left
  239. ralphm has joined
  240. Guus has left
  241. @Alacer has left
  242. @Alacer has joined
  243. andrey.g has joined
  244. andrey.g has joined
  245. andrey.g has joined
  246. jcbrand has joined
  247. andrey.g has joined
  248. Ge0rG has left
  249. Alex has left
  250. stefandxm has left
  251. stefandxm has joined
  252. andrey.g has joined
  253. andrey.g has joined
  254. intosi has joined
  255. daniel has left
  256. lskdjf has joined
  257. andrey.g has joined
  258. andrey.g has joined
  259. Ge0rG has left
  260. jubalh has joined
  261. andrey.g has joined
  262. andrey.g has joined
  263. Holger Just auto-join :-)
  264. Zash has joined
  265. Alex has left
  266. Alex has joined
  267. andrey.g has joined
  268. Ge0rG has left
  269. andrey.g has joined
  270. andrey.g has joined
  271. andrey.g has joined
  272. Ge0rG Holger: not to handle invitations, that part is already implemented in a nice way. To send invitations
  273. Holger Ah.
  274. zinid has joined
  275. andrey.g has joined
  276. la|r|ma has left
  277. la|r|ma has joined
  278. andrey.g has joined
  279. Ge0rG has left
  280. andrey.g has joined
  281. Ge0rG I suppose the most logica place would be inside the MUC, and it would need to have some "Add/Invite participant" button, which would then show a contact picker of some sort.
  282. andrey.g has joined
  283. zinid Brilliant solution
  284. Ge0rG zinid: I'm sure you have awesome ideas for that workflow
  285. andrey.g has joined
  286. zinid Ge0rG: nah, I'm here to demotivate only
  287. SouL It's the approach I would follow, at least it is the first thing that comes to my mind.
  288. andrey.g has joined
  289. Ge0rG Except I don't have a "contact picker", I'm using the main window for that.
  290. Ge0rG but it would be really confusing to fall back from the MUC invitation to the main window and have no way back.
  291. andrey.g has joined
  292. andrey.g has joined
  293. Ge0rG has left
  294. andrey.g has joined
  295. Guus has joined
  296. tim@boese-ban.de has left
  297. Tobias has joined
  298. andrey.g has joined
  299. andrey.g has joined
  300. ralphm has joined
  301. moparisthebest has joined
  302. Ge0rG has left
  303. andrey.g has joined
  304. andrey.g has joined
  305. marc has joined
  306. moparisthebest has joined
  307. daniel has left
  308. daniel has left
  309. andrey.g has joined
  310. andrey.g has joined
  311. Tobias has joined
  312. andrey.g has joined
  313. andrey.g has joined
  314. Ge0rG has left
  315. @Alacer has left
  316. @Alacer has joined
  317. uc has left
  318. uc has joined
  319. andrey.g has joined
  320. andrey.g has joined
  321. daniel has left
  322. stefandxm has left
  323. stefandxm has joined
  324. andrey.g has joined
  325. andrey.g has joined
  326. Ge0rG has left
  327. ralphm has left
  328. andrey.g has joined
  329. andrey.g has joined
  330. andrey.g has joined
  331. andrey.g has joined
  332. Tobias has left
  333. Tobias has joined
  334. andrey.g has joined
  335. andrey.g has joined
  336. Ge0rG has left
  337. andrey.g has joined
  338. andrey.g has joined
  339. andrey.g has joined
  340. SamWhited has joined
  341. andrey.g has joined
  342. andrey.g has joined
  343. SouL has left
  344. Ge0rG has left
  345. Tobias has joined
  346. moparisthebest has joined
  347. andrey.g has joined
  348. andrey.g has joined
  349. moparisthebest has joined
  350. zinid has left
  351. zinid has joined
  352. Tobias has joined
  353. andrey.g has left
  354. andrey.g has joined
  355. Steve Kille has joined
  356. andrey.g has joined
  357. Ge0rG has left
  358. uc has left
  359. uc has joined
  360. daniel has left
  361. andrey.g has joined
  362. andrey.g has joined
  363. andrey.g has joined
  364. andrey.g has joined
  365. Ge0rG has left
  366. daniel has left
  367. andrey.g has joined
  368. andrey.g has joined
  369. andrey.g has joined
  370. andrey.g has joined
  371. jcbrand has left
  372. Syndace has left
  373. Syndace has joined
  374. andrey.g has joined
  375. andrey.g has joined
  376. Ge0rG has left
  377. @Alacer has left
  378. @Alacer has joined
  379. andrey.g has joined
  380. andrey.g has joined
  381. Ge0rG has left
  382. andrey.g has joined
  383. daniel has left
  384. nyco has left
  385. daniel has left
  386. andrey.g has joined
  387. daniel has left
  388. daniel has left
  389. jmpman has joined
  390. jmpman has joined
  391. daniel has left
  392. Syndace has left
  393. Syndace has joined
  394. andrey.g has joined
  395. andrey.g has joined
  396. daniel has left
  397. Ge0rG has left
  398. daniel has left
  399. andrey.g has joined
  400. ralphm has joined
  401. daniel has left
  402. Guus has left
  403. Guus has joined
  404. @Alacer has left
  405. @Alacer has joined
  406. Ge0rG has left
  407. Steve Kille has left
  408. jubalh has left
  409. jubalh has left
  410. Guus has left
  411. Tobias has joined
  412. pep. has left
  413. daniel has left
  414. Guus has joined
  415. Steve Kille has joined
  416. daniel has left
  417. nyco has left
  418. Ge0rG has left
  419. Guus has left
  420. Guus has joined
  421. Steve Kille has left
  422. Ge0rG has left
  423. Guus has left
  424. ralphm has left
  425. Ge0rG has left
  426. Alex has left
  427. Ge0rG has left
  428. Guus has joined
  429. pep. has left
  430. Ge0rG has left
  431. Ge0rG has left
  432. pep. has left
  433. daniel can I use links in a XEP?
  434. daniel to link to another section?
  435. pep. jonasw, re https://mail.jabber.org/pipermail/standards/2017-December/034058.html should we PR? Or wait for a bit more input? Or PR and wait for input on these? :P
  436. Ge0rG has left
  437. nyco has left
  438. pep. I'll comment on the thread, but it actually "works fine" on ejabberd and mlink, or rather it's just not shown as a kick, they don't include 307. https://bpaste.net/raw/5eb5eda0bd42
  439. pep. I agree a new code would be more explicit, but then changing the XEP, and people updating their clients..
  440. marc has left
  441. jonasw pep., sorry, I think that omitting 307 is the wrong way to go here.
  442. jonasw it’s misleading, while kick is just confusing
  443. pep. right
  444. marc has left
  445. pep. hmm, Conversations doesn't show kicks at all?
  446. pep. Unless it's me I suppose
  447. pep. This is meh
  448. jonasw conversations is minimalistic regarding these things
  449. pep. yeah I get that, still.
  450. pep. So I guess dino will have more or less the same pitch
  451. jonasw especially in the self-presence (code='110') it is highly misleading to omit any type of status code which indicates what’s going on
  452. jcbrand has joined
  453. jonasw pep., I think preparing a PR makes sense
  454. jonasw I don’t care who of us does it. If you won’t, I’ll do it right away.
  455. pep. Not that I don't want to, but I have no idea how to formulate it
  456. jonasw k, will do
  457. pep. Thanks
  458. Flow wouldn't that be an example for a change either requiring a namespace bump of xep45, or, if you make it optiona, provide no real benefit?
  459. Ge0rG has left
  460. uc has joined
  461. jonasw Flow, no
  462. jonasw optional is fine
  463. jonasw it only matters for UI purposes anyways
  464. Flow ahh, ok
  465. jonasw it may also matter for other things in some special cases, but having it as a MAY is still better than nothing
  466. jonasw brb
  467. jonasw Flow, in fact, the status codes are a registry
  468. jonasw so trivial to add new ones
  469. jonasw except that we probably don’t have anything to update the registry HTML files in pace
  470. jonasw except that we probably don’t have anything to update the registry HTML files in place
  471. Tobias has joined
  472. mimi89999 has left
  473. uc has left
  474. mimi89999 has joined
  475. mimi89999 has joined
  476. uc has joined
  477. Ge0rG has left
  478. Flow Doesn't matter if there is a registry: if the spec would suddenly say that this code is required for this case, then it would be a breaking change. But it's probably fine if you make it optional
  479. mimi89999 has left
  480. mimi89999 has left
  481. Guus has left
  482. Guus has joined
  483. Steve Kille has left
  484. Steve Kille has left
  485. Ge0rG has joined
  486. Ge0rG has left
  487. Guus has left
  488. Steve Kille has left
  489. stefandxm has left
  490. ralphm has left
  491. stefandxm has joined
  492. @Alacer has left
  493. Ge0rG has left
  494. @Alacer has joined
  495. Steve Kille has joined
  496. SouL has left
  497. SouL has joined
  498. pep. jonasw, thanks, just saw the PR!
  499. Ge0rG has left
  500. pep. jonasw, Flow, in any case any client is going to need an update for this right? Because atm 307 is displayed as a kick
  501. jonasw pep., yes
  502. pep. jonasw, Flow, in any case all clients are going to need an update for this right? Because atm 307 is displayed as a kick
  503. jonasw I wonder why this has come up only now. It has been like this for ages.
  504. pep. So bump or not bump, it's the same issue right?
  505. pep. I'd say bump in this case, and make it required :x
  506. pep. jonasw, prosody rewrote their muc implementation in trunk
  507. pep. I guess they had a similar behavior to ejabberd/mlink before
  508. jonasw pep., I’m very sure that not
  509. jonasw because I’m observing this behaviour in prosody MUCs on 0.9
  510. pep. oh
  511. pep. ok
  512. jonasw bump MUC, are you out of your mind?!
  513. pep. yay standards
  514. pep. Well not just standards
  515. stefandxm has left
  516. pep. *Dear Santa, please help me deliver features to users faster, without bumps on the road*
  517. jonasw pep., this change allows you to do that. My suspicion is that it is only now that people notice because we have more non-technical people. Those people use clients which are actively developed and which will be able to adapt to 333 quickly
  518. tux There's a reason it is often called "bump version to X.X".
  519. pep. jonasw, how do we have more non-technical people
  520. jonasw pep., it is just my suspicion
  521. pep. This particular discussion about muc spawned from Link Mauve and me
  522. Ge0rG has left
  523. Ge0rG has left
  524. Steve Kille has left
  525. jjrh has left
  526. ralphm has joined
  527. goffi has left
  528. Ge0rG has left
  529. Ge0rG has left
  530. Tobias has joined
  531. Tobias has joined
  532. ralphm has joined
  533. jjrh has left
  534. SamWhited has left
  535. stefandxm has joined
  536. jjrh has left
  537. Tobias has joined
  538. Tobias has joined
  539. daniel has left
  540. lovetox has joined
  541. Ge0rG has left
  542. Guus has joined
  543. sonny has left
  544. sonny has joined
  545. efrit has joined
  546. sonny has joined
  547. sonny has joined
  548. ralphm has left
  549. Ge0rG has left
  550. efrit has left
  551. daniel feedback welcome: https://gultsch.de/files/pep-vcard-conversion.html
  552. jonasw daniel, when you get a chance, update your CSS, it’s nicer to read then.
  553. jonasw daniel, neat
  554. jonasw Does it make sense to have servers apply the same Access Control for the vCard as they do for PEP-Avatar?
  555. sonny has joined
  556. sonny has joined
  557. sonny has joined
  558. daniel i rather not change a historical xep; the default access model would not work in muc
  559. Tobias has joined
  560. daniel the only sensible way is to do the conversion only if the access model of pep is whitelist
  561. jonasw why is that?
  562. daniel what?
  563. jonasw I don’t understand why it makes sense to do the conversion iff the whitelist access_model is used.
  564. jonasw I would have expected the opposite?
  565. moparisthebest has joined
  566. sonny has joined
  567. sonny has joined
  568. daniel if you would expect vcard to have the same access control as pep; you can't do that by changing vcards. but you could only do the conversion if the pep access model is that of vcards (=whitelist)
  569. jonasw I thought vcards is open access?
  570. daniel s/whitelist/open/ in everything i said
  571. jonasw now it makes sense, thanks!
  572. jonasw how would a server deal with a client which does both vcard and pep-avatar?
  573. daniel that uploads both after each other?
  574. jonasw yeah
  575. daniel they would simply override each other
  576. jonasw I see
  577. daniel it's not ideal but i don't see how that can cause conflict
  578. daniel if iq queries are processed in order
  579. daniel which they are
  580. jonasw I love it :)
  581. jonasw we’re working on our vcard impl currently, we might integrate that as well
  582. daniel i should say that i didn't come up with that. both prosody and ejabberd have implemenations for that already
  583. ralphm has left
  584. daniel minus the presence broadcast thing on prosody
  585. jonasw do they advertise the feature already?
  586. daniel no
  587. jonasw k
  588. daniel the presence broadcast thing is essential for the method to work properly though. but should be an easy fix in prosody
  589. jonasw it is indeed
  590. jonasw the presence broadcast rules of xep-0153 are crazy, I’m happy to see that this might be fixed magically
  591. daniel jonasw, crazy because you have to download it first?
  592. jonasw yeah, and the interaction with non-153 clients
  593. jonasw now I wonder if it should be possible to set the vcard without changing the photo, to be able to modify non-avatar things there.
  594. daniel to what end? not triggering a notification in PEP?
  595. ralphm has joined
  596. jonasw hm
  597. jonasw nevermind I guess
  598. marc has joined
  599. stefandxm has left
  600. Kev has left
  601. tux has left
  602. zinid daniel, thanks a ton for the XEP 🙂
  603. daniel zinid, did you write the ejabberd module that does this?
  604. zinid yes
  605. daniel in that case i'm gonna mention you in the acknowledge section of the xep
  606. daniel (unless you object to that of course)
  607. zinid there is a minor bug though: vcard:x:update is not injected into direct presences
  608. zinid no objection of course
  609. sezuan has joined
  610. zinid I mean it's injected, but not resent on avatar update (unlike broadcast, which is resent)
  611. daniel zinid: oh. I haven't thought of that. That might be difficult...
  612. jonasw daniel, I think it’s reasonable to state that clients need to re-send that themselves
  613. jonasw they need to handle directed presence manually anyways
  614. zinid jonasw, probably a good idea
  615. jonasw (and it is sufficient for them to send a blank presence, the vcard thing will be injected)
  616. zinid not sure if client authors agree 🙂
  617. jonasw I’m a client author
  618. jonasw I’m not happy with having to re-send directed presence manually, but I need to do that anyways.
  619. Holger So if you publish a PEP avatar you're supposed to resend direct presence?
  620. jonasw having to do this for avatar updates is fine.
  621. zinid well, you're a special one, you're not afraid of difficulties 🙂
  622. jonasw Holger, no?
  623. daniel jonasw: yeah maybe. In reality it's probably not gonna be a huge problem
  624. daniel How often are you changing your avater
  625. jonasw daniel, ack. even if the update doesn’t get through immediately, so what :)
  626. jonasw having that written down is good though
  627. daniel Holger: not when publishing. But when receiving the notification about it
  628. zinid daniel, I know a guy with 15 year old avatar 😀
  629. daniel Otherwise it won't work if another client changes that
  630. daniel But yeah...
  631. daniel That's very very minor
  632. Holger It affects MUC right?
  633. jonasw yes
  634. Holger "Look guys my funny new avatar!"
  635. Holger But yes compared to today's situation it's minor.
  636. nyco has left
  637. zinid yeah, that's how I revealed the bug, hehe
  638. jonasw Holger, indeed, good point.
  639. marc has left
  640. daniel has left
  641. ralphm has left
  642. daniel Yeah I'll add it to the xep. It's not terribly complicated to resend directed presences when receiving a pep update *and* the server announces that feature
  643. ralphm has joined
  644. Holger Sounds weirdo to me.
  645. jonasw my vcard dev also thinks your XEP is great, daniel :)
  646. zinid Holger, in order to resent direct presences you need to store them on the server
  647. zinid do we want it?
  648. daniel Arguably better than tracking directed presences on the server
  649. jonasw zinid, don’t you have to do that anyways, because you must send unavailable when the server leaves?
  650. jonasw zinid, don’t you have to do that anyways, because you must send unavailable when the client disconnects?
  651. Holger zinid: I'm confused, don't we have that in the c2s state?
  652. Holger But I must run, BBL.
  653. zinid jonasw, no, direct presences are not affected during server broadcasts
  654. sezuan has left
  655. zinid ah
  656. zinid yes, it's resent on unavailable 😉
  657. sezuan has joined
  658. zinid but not the original presence, but the broadcasted one
  659. jonasw ah I see you rpoint
  660. jonasw you’d need to know how to compose the original directed presence
  661. jonasw makes sense
  662. zinid yes
  663. zinid they can be different
  664. daniel If the general modus operandi is that client developers push responsibility to the server developers and vice versa I'll happily take the responsibility in that case as a client dev
  665. jonasw daniel, I don’t see an issue with that, tbh, clients need to manage their directed presence either way.
  666. jonasw and they need to re-send their directed presence with vcard-temp too if they care
  667. jonasw this is still better
  668. daniel Totally
  669. sonny has joined
  670. sonny has joined
  671. zinid ah, another question is what to do if presence contains hash already
  672. zinid ejabberd currently rewrites it anyway
  673. jonasw zinid, if it doesn’t match, somebody made a mistake, and if the server overrides that, that’s probably good
  674. zinid but seems like someone doesn't like this, e.g. they don't want to propagate their avatars to mucs
  675. sezuan has left
  676. zinid jonasw, yes, but see my next point
  677. sezuan has joined
  678. jonasw ah, but then you wouldn’t write a hash in it?
  679. jonasw but an empty element?
  680. zinid so probably some mechanism to avoid injecting is needed
  681. daniel zinid: yeah that's why I said don't override
  682. jonasw zinid, maybe only override if clients send <x xmlns="vcard-temp-foobar"/>? that’s how clients signal "I know the vcard protocol, but I don’t know the hash"
  683. daniel zinid: however that doesn't work as a security feature. The avater can still be retrieved
  684. zinid daniel, I'm fine with not overriding it on server 🙂
  685. jonasw hm
  686. zinid <x xmlns="vcard-temp-foobar"/> means there is no avatar
  687. marc has joined
  688. zinid at least from what I rememeber
  689. daniel An empty photo means it's empty
  690. daniel An empty x means something else. Lol
  691. jonasw yup
  692. jonasw empty x means "I understand vcard, but I don’t know the current hash, don’t mind me"
  693. daniel Either way it's probably better to not touch it
  694. jonasw while absent x means "I don’t understand vcard-avatar, so neither of you all must publish vcard avatars"
  695. zinid on the other hand, there is a situation when a client has uploaded the avatar via vcard, the server transcoded the image (thus new hash) and we have problems here if we don't override
  696. jonasw daniel, but then clients would have to fetch the photo to properly join a MUC
  697. jonasw zinid, I’d suggest to override whenever there’s an <x/> element which doesn’t indicate absent avatar.
  698. daniel jonasw: no. Just don't set it at all
  699. jonasw daniel, I don’t think that’s a good idea
  700. jonasw or maybe it is
  701. zinid jonasw, a lot of stupid clients don't inject anything despite they have avatar, that's the problem...
  702. jonasw I’m not sure
  703. ralphm has joined
  704. lumi has left
  705. zinid that was initial goal of mod_vcard_xupdate actually, it's later I adopted it to new behav
  706. daniel Yeah I don't have hard feelings with that either way. Maybe just leave the xep as is for now and see if this creates problems
  707. zinid yeah, this is bikeshedding mostly
  708. jonasw true
  709. daniel has left
  710. daniel has joined
  711. zinid if you don't mind a little more bikeshedding, what I would suggest is to not rewrite the hash if it's empty
  712. nyco has left
  713. zinid so we work-around "transcoding" problem
  714. jonasw zinid, I think that’s sane
  715. zinid and make crypto paranoics happy
  716. jonasw yup
  717. zinid and regarding "an avatar anyway can be retrieved via vcard direct request": this could be solved by privacy rules, but we deferred them, hehe
  718. daniel > if you don't mind a little more bikeshedding, what I would suggest is to not rewrite the hash if it's empty > so we work-around "transcoding" problem An empty photo element?
  719. zinid yes
  720. zinid well, need to re-read xep-153 carefully to remember what empty photo element means
  721. zinid so we don't contradict
  722. lovetox no avatar published if i correctly remember
  723. jonasw zinid, it means "I don’t want to publish an avatar"
  724. jonasw or de-publishing essentially
  725. jonasw yes
  726. daniel I don't see the argument for touching the x element at all
  727. daniel If it exists
  728. Ge0rG has left
  729. zinid what if the server has changed the avatar, for example png->jpeg or something?
  730. lovetox why should he do that?
  731. zinid well, yes, that's a separate unrelated story, but anyway
  732. sezuan has left
  733. stefandxm has joined
  734. daniel zinid: ok. Fair enough
  735. zinid lovetox, because some put webp into avatars 😛
  736. lovetox yeah and? why would the server care?
  737. zinid lovetox, an admin might care about the users, you know, that can happen
  738. lovetox i think this opens a lot of problems
  739. lovetox we depend on hash
  740. lovetox i upload something, know my hash
  741. lovetox afterwards i get something different back
  742. zinid and?
  743. lovetox such a server mod would be bad in my opinion
  744. zinid what problems?
  745. sezuan has joined
  746. zinid you can receive another hash from another resource for example
  747. zinid so a client should be prepared to receive another hash
  748. jonasw has left
  749. jonasw yup
  750. jonasw lovetox, it’s just as if another resource of yours did that
  751. lovetox iam if its from another resource
  752. jonasw why would you care about the resource? :)
  753. sezuan has left
  754. lovetox i dont know, its just weird
  755. zinid it's xmpp
  756. lovetox makes no sense to me
  757. zinid of course it's weird
  758. jonasw I find this pretty elegant
  759. lovetox and you do this only because of conversations lol
  760. jonasw if more things work by doing less, that’s most of the time a good thing
  761. lovetox elegant is if clients support more than jpeg and png
  762. lovetox elegant would be clients respecting a standard and uploading in a agreed format
  763. lovetox this is all BUT elegant
  764. jonasw lovetox, except that the agreed-upon format does not cope well with the defined limits in the RFCs
  765. sezuan has joined
  766. lovetox i dont really care, i was just arguing that you seriously think thats elegant
  767. jonasw I wish we had a way to properly put multiple formats into the avatar node in an XMPPy way
  768. jonasw lovetox, I’m not arguing that doing some server-side conversion is particularly elegant
  769. lovetox maybe i should start uploading in some even more exotic format, so we can write more server mods
  770. zinid we probably need to consider a different format, I don't think this will hurt, because I don't think there are clients not understanding jpeg (i.e. png-only)
  771. jonasw I’m arguing that not caring about the /resource of vcard updates is elegant, because you don’t need that extra check.
  772. jonasw zinid, except that jpeg sucks
  773. zinid jonasw, yes, but png is really huge
  774. jonasw depends
  775. daniel Fwiw Conversations stopped uploading webp
  776. zinid so they both suck
  777. jonasw zinid, yes
  778. jonasw trade-offs all over again
  779. zinid daniel, good to know 😛
  780. daniel Should we create or own image format?
  781. jonasw daniel, like we created our own Markup?
  782. jonasw daniel, what does conversations do now?
  783. daniel Jpeg
  784. daniel Duh
  785. jonasw "meh"
  786. daniel Eps
  787. daniel Lol
  788. daniel jonasw: don't worry it will still work with your avatar because there is an exception if the image contains transparency
  789. jonasw daniel, neat!
  790. jonasw so if I want an uncompressed avatar, I just make one pixel with alpha=254 :)
  791. daniel It will resize it of course. But yes
  792. daniel Or use a different avatar
  793. daniel Client
  794. jonasw sure
  795. daniel To upload it
  796. zinid daniel, muc vcard avatars are left!
  797. stefandxm has left
  798. zinid daniel, movim did it already 🙂
  799. zinid ejabberd supports them since stone age
  800. daniel zinid: is there a xep?
  801. zinid well, I asked XSF back in the time, they said no xep is needed for this
  802. zinid the only problem is how to update the avatar, since a conference doesn't generate presences
  803. zinid I mean how to propagate updates
  804. daniel 'the only problem'
  805. zinid 😀
  806. jonasw MIX will fix that ;-)
  807. jonasw we should get stickers with that
  808. zinid well, I'd really love to see conference avatar in my conversations list instead of a square with 4 squares inside
  809. daniel So what does movim do? Just query it opportunisticly on every join?
  810. zinid daniel, no, every couple of hours or so 😀
  811. zinid what if a presence comes from bare conference jid?
  812. zinid would clients get crazy because of this?
  813. jonasw I think we should definitely write down a XEP about how to deal with the bare MUC JID
  814. daniel Conversations would just ignore it I guess
  815. jonasw services are already making use of the bare MUC JID for sending service messages, and having that written down somewhere would be good
  816. jonasw I have no idea what aioxmpp would do on a presence from the bare MUC JID.
  817. zinid daniel, so we probably can utilize it for avatars dissemination
  818. daniel Probably... We can try to implement it next year as a PoC
  819. zinid PoC?
  820. daniel Proof of concept
  821. daniel Proof that it works in quick demo
  822. zinid and we prove it to ... ?
  823. zinid XSF? 🙂
  824. daniel I never personally had the desire for muc avatars but it's easy enough to implement I guess so I'm not opposed
  825. daniel Nah the world
  826. daniel Or to ourselves
  827. jonasw do MUCs have to implement PubSub then, too?
  828. daniel I think we are talking about vCard avatars
  829. jonasw for now :)
  830. zinid and if mucs implement pubsub, why would we need mix? 🙂
  831. zinid I'm actually agreed already to implement pubsub on mucs, just not to implement this dredful MIX
  832. daniel Well we are now slowly getting to point where we fixed most of the muc bugs so it's about time to replace it with something else
  833. ralphm has joined
  834. zinid daniel, another way is to utilize something like if-modified-since in join presence, and later a muc will send presence updates to those clients only
  835. waqas has joined
  836. uc has left
  837. zinid has left
  838. Zash has left
  839. jcbrand has left
  840. Holger Sorry I'm late to the party; regarding overriding the avatar hash: If you think users might not want to publish the avatar to MUCs, then auto-publishing the PEP avatar as vCard is a problem, no? I mean there's no way to stop the server from injecting the hash after the client published the avatar via PEP, no?
  841. daniel yes it doesn't do anything security wise
  842. daniel it might stop certain clients from discovering that you have a client
  843. daniel but thats not even security by obscurity
  844. daniel *that you have an avatar
  845. tim@boese-ban.de has left
  846. tim@boese-ban.de has left
  847. tim@boese-ban.de has joined
  848. Alex has left
  849. ralphm has joined
  850. waqas has left
  851. zinid Holger, but in theory you can restrict your access to vcards via privacy rules (e.g. subscription=none => deny)
  852. daniel zinid, but then it doesn't matter what hash you annouce
  853. zinid well, you can be identified by the hash 😛
  854. remko has joined
  855. zinid I don't know how the brain of crypto maniacs work, so I just guessing 🙂
  856. tux has left
  857. tux has joined
  858. lovetox has left
  859. SamWhited has joined
  860. remko has left
  861. daniel has left
  862. SamWhited has joined
  863. SamWhited has joined
  864. Tobias has joined
  865. Tobias has joined
  866. stefandxm has joined
  867. daniel https://gultsch.de/files/pep-vcard-conversion.html updated. i included a note that the server should not touch empty photo elemets but override photo with wrong hashes
  868. ralphm has joined
  869. zinid fine by me 🙂
  870. zinid thx
  871. zinid when approved, I'll fix that in ejabberd
  872. @Alacer has left
  873. @Alacer has left
  874. waqas has joined
  875. waqas has left
  876. daniel and prosody needs to do the x_update thing. maybe i'll code that myself at some point
  877. moparisthebest has joined
  878. SamWhited has joined
  879. zinid I'm drunk, but I don't find this text clear: > Empty x elements qualified by the 'vcard-temp:x:update' namespace (those without a photo element as child), as well as photo elements with a wrong hash MUST be overwritten.
  880. SamWhited has joined
  881. zinid what is the 'wrong hash'? Is empty hash ('') wrong?
  882. zinid the example is clear, though
  883. daniel do you have a suggestion on how to make this more clear?
  884. daniel (even though you are drunk?)
  885. stefandxm has left
  886. daniel …as well as photo elements with a non-empty content MUST be overwritten?
  887. zinid I would suggest to split the sentence in two short parts, which are clear, like 'A server MUST NOT override presences with empty <photo> element. A server MAY override all other presences', something like that
  888. moparisthebest has joined
  889. daniel fair enough
  890. zinid not sure whey we want to override presences without <photo/> element though 🙂
  891. zinid I just read the XEP-0153 and didn't get what means "a client is not yet ready to advertise an image"
  892. daniel sending presence before receiving the iq response for the avatar
  893. zinid ah
  894. zinid good point
  895. zinid then it makes sense, yes
  896. daniel > To avoid this, services MUST include the hash on behalf of their users in every available presence that does not contain an empty photo element wrapped in an x element qualified by the 'vcard-temp:x:update' namespace. Empty x elements qualified by the 'vcard-temp:x:update' namespace (those without a photo element as child) MUST be overwritten. Presences where the content of the photo element is not empty and not equal to the hash calculated by the service MAY be overwritten.
  897. zinid yes, much more clear
  898. ralphm has joined
  899. waqas has joined
  900. sonny has joined
  901. sonny has joined
  902. sonny has left
  903. sonny has joined
  904. Tobias has joined
  905. edhelas has left
  906. edhelas has joined
  907. Kev has joined
  908. Tobias has joined
  909. uc has joined
  910. Syndace has left
  911. Syndace has joined
  912. sonny has left
  913. sonny has joined
  914. sonny has left
  915. sonny has joined
  916. daniel has left
  917. sonny has left
  918. sonny has joined
  919. sonny has left
  920. sonny has joined
  921. sonny has left
  922. sonny has joined
  923. sonny has left
  924. sonny has joined
  925. sonny has left
  926. sonny has joined
  927. sonny has left
  928. sonny has joined
  929. zinid has left
  930. jjrh has left
  931. Holger has left
  932. valo has left
  933. tux has left
  934. stefandxm has joined
  935. jjrh has left
  936. mimi89999 has joined
  937. stefandxm has left
  938. jjrh has left
  939. jjrh has left
  940. jjrh has left
  941. nyco has left