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