XSF Discussion - 2019-10-05

  1. zach has left
  2. zach has joined
  3. pdurbin has joined
  4. zach has left
  5. zach has joined
  6. goffi has left
  7. andrey.g has left
  8. pdurbin has left
  9. Douglas Terabyte has left
  10. zach has left
  11. zach has joined
  12. xalek has joined
  13. Zash has left
  14. Zash has joined
  15. zach has left
  16. zach has joined
  17. andrey.g has joined
  18. kokonoe has left
  19. pdurbin has joined
  20. kokonoe has joined
  21. marc_ has left
  22. pdurbin has left
  23. lskdjf has left
  24. zach has left
  25. zach has joined
  26. j.r has left
  27. j.r has joined
  28. j.r has left
  29. j.r has joined
  30. zach has left
  31. zach has joined
  32. waqas has left
  33. waqas has joined
  34. waqas has left
  35. zach has left
  36. zach has joined
  37. j.r has left
  38. j.r has joined
  39. pdurbin has joined
  40. Yagiza has joined
  41. adiaholic has joined
  42. pdurbin has left
  43. mukt2 has joined
  44. zach has left
  45. zach has joined
  46. mukt2 has left
  47. DebXWoody has left
  48. adiaholic has left
  49. adiaholic has joined
  50. zach has left
  51. zach has joined
  52. DebXWoody has joined
  53. pdurbin has joined
  54. pdurbin has left
  55. karoshi has joined
  56. mimi89999 has left
  57. mimi89999 has joined
  58. mukt2 has joined
  59. xalek has left
  60. mukt2 has left
  61. zach has left
  62. zach has joined
  63. mukt2 has joined
  64. waqas has joined
  65. Nekit has joined
  66. waqas has left
  67. j.r has left
  68. j.r has joined
  69. adiaholic has left
  70. chronosx88 has joined
  71. adiaholic has joined
  72. mukt2 has left
  73. mukt2 has joined
  74. Tobias has joined
  75. zach has left
  76. zach has joined
  77. pdurbin has joined
  78. pdurbin has left
  79. j.r has left
  80. zach has left
  81. zach has joined
  82. j.r has joined
  83. pep. Ge0rG: ah ok, I didn't remember the outcome but I remembered there was something about it
  84. winfried has left
  85. winfried has joined
  86. Alex has left
  87. adiaholic has left
  88. mukt2 has left
  89. zach has left
  90. zach has joined
  91. Alex has joined
  92. lovetox_ has joined
  93. Nekit has left
  94. zach has left
  95. zach has joined
  96. Mikaela has joined
  97. chronosx88 has left
  98. chronosx88 has joined
  99. LNJ has left
  100. aj has left
  101. Seve has joined
  102. Vaulor has joined
  103. adiaholic has joined
  104. wurstsalat has joined
  105. adiaholic has left
  106. adiaholic has joined
  107. adiaholic has left
  108. adiaholic has joined
  109. j.r has left
  110. zach has left
  111. zach has joined
  112. j.r has joined
  113. lovetox_ lately i ran into following problem with the MUC protocol
  114. lovetox_ send a presence to a MUC
  115. lovetox_ Muc does not answer for 20 seconds
  116. lovetox_ i give the user a option to abort this join (close the window or whatever)
  117. lovetox_ only this does not reflect the truth, i have not really a possibility to abort the join
  118. lovetox_ so user presses abort, and naturally tries again to join the room
  119. lovetox_ another presence is sent out, now suddenly server responds to the first presence, sends stuff, then does the same for the second presence
  120. lovetox_ i have no possibility to know what happend because of first presence, and what happens because of last presence
  121. lovetox_ now i could send a presence unavailable on first abort
  122. lovetox_ this brings me into even more trouble, now the server sends all presences, then disconnects me from the muc, then starts again to send stuff
  123. lovetox_ all in all nothing i want to really deal with
  124. lovetox_ maybe i should remove the abort button
  125. lovetox_ there is no aborting a muc join
  126. Ge0rG lovetox_: modern MUCs will treat a join presence (with an x element) as a request for a full sync.
  127. Ge0rG And yes, there is no way to abort anything in xmpp land.
  128. Ge0rG Which is why it's silly to have things end in a hard timeout.
  129. goffi has joined
  130. lovetox_ then this muc join is in limbo and if a user complains i just tell him server should answer eventually
  131. Ge0rG OTOH some network conditions may well lead to a request getting black holed.
  132. Ge0rG So that the MUC doesn't even know that you tried joining.
  133. mukt2 has joined
  134. Ge0rG This can be solved with s2s 0198, which nobody has ever tested.
  135. larma has left
  136. Ge0rG Because you know, TCP is a reliable protocol
  137. jonas’ lovetox_, the second presence with <x/> should not screw up anything in the scenario you described
  138. jonas’ in fact, I think it should be safe to re-send join presences with exponential back off similar to how TCP sends SYNs
  139. larma has joined
  140. mukt2 has left
  141. j.r has left
  142. zach has left
  143. zach has joined
  144. kokonoe has left
  145. jonas’ Kev, pinging you again regarding the hub.docker.com stuff. You seem to be the only one active who has the permissions.
  146. adiaholic has left
  147. Ge0rG jonas’: but one needs to know where the old join ends and the new one starts.
  148. adiaholic has joined
  149. Ge0rG Maybe we need a unique ID on the join stanza, and the server ignoring duplicates?
  150. j.r has joined
  151. emus has joined
  152. jubalh has joined
  153. sonny has left
  154. flow > Ge0rG> jonas’: but one needs to know where the old join ends and the new one starts. do you?
  155. jonas’ Ge0rG, that’d be great
  156. zach has left
  157. zach has joined
  158. jonas’ Ge0rG, flow, not in the scenario lovetox_ described, I think. You’d get (a) a full initial set of presence, (b) all presence hcanges between a and c, and (c) another full set of initial presence
  159. jonas’ there’s quite a bit of redundancy, but the state should be correct and complete
  160. jonas’ although, it will be confusing if you requested MUC history
  161. Mikaela has left
  162. Mikaela has joined
  163. COM8 has joined
  164. flow jonas’, i'd guessed and hoped that something like that happens, but of course this could be MUC service (and client) implementation dependent. But nevertheless joining and (potentially other MUC actions) could and should get improved, and we should consider those things in groupchat-ng protocols
  165. jcbrand has joined
  166. kokonoe has joined
  167. Daniel has left
  168. COM8 has left
  169. lskdjf has joined
  170. Daniel has joined
  171. jubalh has left
  172. pdurbin has joined
  173. jcbrand has left
  174. emus has left
  175. jubalh has joined
  176. Ge0rG If only somebody thought that through for MIX
  177. Shell has left
  178. zach has left
  179. zach has joined
  180. jonas’ mix is at least a step forward in that regard
  181. jonas’ that we don’t have a proper solution for s2s failures yet is a problem, indeed
  182. jonas’ but that’s not a problem unique to mix or muc actually
  183. Daniel has left
  184. Ge0rG We also need something for mobile clients that are killed after 10s in the background. A solution that doesn't involve persisting all runtime state, MUCs, and contact presence to disk
  185. Daniel has joined
  186. Zash Can you really fix that with protocol design?
  187. jonas’ "WhatsApp works"
  188. Ge0rG Zash: yes
  189. andy has joined
  190. Ge0rG With roster versioning, no presence broadcast and MAM we already have a moderately expensive solution. We now only need to replace presence with a PEP based status thing, as suggested by Kev.
  191. Douglas Terabyte has joined
  192. Ge0rG BTW, what are the rules for delivering subscription requests to clients that don't send presence?
  193. jonas’ "don’t"?
  194. Ge0rG Oh, and the above thing doesn't include MUC. We don't have a solution for that yet
  195. jonas’ Instead, if a subscription request requires approval then the contact's server MUST deliver that request to the contact's available resource(s) for approval or denial by the contact.
  196. jonas’ RFC 6121
  197. jonas’ RFC 6121, 3.1.3. https://tools.ietf.org/html/rfc6121#section-3.1.3
  198. jonas’ 4. Otherwise, if the contact has no available resources when the subscription request is received by the contact's server, then the contact's server MUST keep a record of the complete presence stanza comprising the subscription request, including any extended content contained therein (see Section 8.4 of [XMPP-CORE]), and then deliver the request when the contact next has an available resource.
  199. jubalh has left
  200. eevvoor has joined
  201. Zash It's XMPP, not XMP
  202. jonas’ Ge0rG, MIX would help in that regard, because it’s the user’s server which fully manages the joins
  203. jonas’ and those will be in a PEP node in the future so that you’re kept up-to-date to some extent.
  204. rion SIMS xep says "The file element is the same as from Jingle File Transfer (XEP-0234) [2]. It MUST specify media-type, size, description, and one or multiple hash elements" Is "description" element really MUST?
  205. Ge0rG jonas’: yes, it's an improvement indeed. But will you get differential updates on the member list?
  206. Zash PEP without presence doesn't work either
  207. zach has left
  208. zach has joined
  209. jonas’ Ge0rG, member list is a PEP node
  210. jonas’ Ge0rG, member list is a PubSub node
  211. Ge0rG jonas’: that's not an answer
  212. jonas’ and supposedly there’s a way to MAM-query PubSub nodes, although I never understood how
  213. jonas’ supposedly the MAM archive of a PubSub node would be the history of messages it sent
  214. jonas’ supposedly the MAM archive of a PubSub node would be the history of notification messages it sent
  215. jonas’ in which case, yes.
  216. Ge0rG Is it a one item node like old bookmarks?
  217. jonas’ I don’t think so
  218. jonas’ > Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node.
  219. Ge0rG Zash: I'm sure we can figure out a way
  220. flow rion, appears so
  221. mr.fister has left
  222. Ge0rG I don't think it makes much sense, though
  223. flow rion, although that appears to be not in line with xep234
  224. flow or, at least, I would expect that SIMS would require at least media-type, size and name (not description)
  225. rion Agreed
  226. pdurbin has left
  227. Ge0rG In JFT, the <description> is the required container element, and the description text is in the optional <desc> element
  228. Ge0rG So what are we talking about?
  229. rion <desc>
  230. flow which we may should rename to something like <description-text/>
  231. j.r has left
  232. sonny has joined
  233. sonny has left
  234. sonny has joined
  235. mukt2 has joined
  236. zach has left
  237. zach has joined
  238. marc_ has joined
  239. mukt2 has left
  240. Yagiza has left
  241. lovetox_ jonas, the problem is the UI with my scenario
  242. lovetox_ of course a library in itself would have the correct state after 2 joins
  243. COM8 has joined
  244. j.r has joined
  245. lovetox_ but having the UI display the correct state is the challenge
  246. COM8 has left
  247. lovetox_ and yes it would be very helpful if we could add a unique join id to the presence, which is replicated on while joining on all the presences
  248. lovetox_ i dont see a problem with subject and messages, you got to have message deduplication anyway
  249. goffi has left
  250. goffi has joined
  251. lovetox_ hm presences should also not be a problem, i could just update the ones i have already in my roster
  252. lovetox_ the real problem for me is that i dont know when the MUC join is finished
  253. lovetox_ normally i display a "joining.." label
  254. jonas’ lovetox_, you know it’s finished when you get the <subject/>
  255. lovetox_ now i abort my first join, open the window again in haft of the first join, now i have half of all presences, then this join completes, i show the UI
  256. lovetox_ but then the second join starts
  257. jonas’ the second join is fully deduplicated, isn’t it?
  258. lovetox_ yes .. still my plan was to *not* show the groupchat UI *while* joining
  259. adiaholic has left
  260. adiaholic has joined
  261. LNJ has joined
  262. lovetox_ so the first join signals my UI join completed, i show the UI with probably half of the users
  263. lovetox_ then second join starts
  264. Daniel has left
  265. lovetox_ but yeah think these are edge cases
  266. lovetox_ still a simple IQ flow would be much better
  267. lovetox_ where i get at the end a IQ join=complete
  268. lovetox_ like with mam
  269. Daniel has joined
  270. Zash How is that different from subject?
  271. lovetox_ because the subject only tells you *a* join completed
  272. lovetox_ not which one
  273. lovetox_ of the 3 you send, while the server didnt answer
  274. Zash right
  275. Zash It should still be idempotent tho?
  276. lovetox_ idempotent?
  277. Zash If you get a second join result it should just set everything to the existing values
  278. emus has joined
  279. Zash But wouldn't you be able to identify which join is which by looking at your own presence?
  280. goffi has left
  281. lovetox_ would i?
  282. lovetox_ does the self presence has the same id as the join presence?
  283. lovetox_ as we determined before, state should be correct even on 2 joins
  284. lovetox_ the problem that i have is the first join signals my UI im finished, when i reality the second is still in progress
  285. lovetox_ i think this is only solveable if we would have some identifier in the join presence, which is at some point returned
  286. lovetox_ i think how muc join was made is a anti-pattern, much better to make things clear with IQs
  287. Zash I tend to agree
  288. goffi has joined
  289. Ge0rG It's significantly improved over GC1.0 still
  290. Zash Yes
  291. zach has left
  292. j.r has left
  293. zach has joined
  294. jonas’ ITYM Xabber Group Chat
  295. debacle has joined
  296. winfried has left
  297. winfried has joined
  298. j.r has joined
  299. j.r has left
  300. zach has left
  301. zach has joined
  302. winfried has left
  303. winfried has joined
  304. j.r has joined
  305. adiaholic has left
  306. gav has left
  307. winfried has left
  308. winfried has joined
  309. winfried has left
  310. winfried has joined
  311. zach has left
  312. zach has joined
  313. pdurbin has joined
  314. winfried has left
  315. winfried has joined
  316. gav has joined
  317. adiaholic has joined
  318. gav has left
  319. pdurbin has left
  320. sonny has left
  321. sonny has joined
  322. mukt2 has joined
  323. kokonoe has left
  324. kokonoe has joined
  325. zach has left
  326. zach has joined
  327. mukt2 has left
  328. Chobbes has joined
  329. j.r has left
  330. adiaholic has left
  331. adiaholic has joined
  332. zach has left
  333. zach has joined
  334. adiaholic has left
  335. adiaholic has joined
  336. j.r has joined
  337. Chobbes has left
  338. gav has joined
  339. j.r has left
  340. zach has left
  341. zach has joined
  342. Daniel has left
  343. COM8 has joined
  344. Daniel has joined
  345. mimi89999 has left
  346. j.r has joined
  347. COM8 has left
  348. COM8 has joined
  349. winfried has left
  350. COM8 has left
  351. winfried has joined
  352. karoshi has left
  353. karoshi has joined
  354. adiaholic has left
  355. zach has left
  356. zach has joined
  357. adiaholic has joined
  358. Mikaela has left
  359. Mikaela has joined
  360. Shell has joined
  361. j.r has left
  362. adiaholic has left
  363. zach has left
  364. zach has joined
  365. kokonoe has left
  366. jubalh has joined
  367. Daniel has left
  368. jubalh has left
  369. Daniel has joined
  370. j.r has joined
  371. !XSF_Martin has left
  372. adiaholic has joined
  373. debacle has left
  374. !XSF_Martin has joined
  375. pdurbin has joined
  376. adiaholic has left
  377. zach has left
  378. zach has joined
  379. david has left
  380. j.r has left
  381. Nekit has joined
  382. j.r has joined
  383. Tobias has left
  384. Tobias has joined
  385. kokonoe has joined
  386. adiaholic has joined
  387. jmpman has joined
  388. jubalh has joined
  389. pdurbin has left
  390. zach has left
  391. zach has joined
  392. Syndace has left
  393. mukt2 has joined
  394. Zash Does anything use the 'continue' error type?
  395. Zash looks at https://xmpp.org/extensions/xep-0310.html#mucoccupant
  396. adiaholic has left
  397. Syndace has joined
  398. Zash Might be nice to send some "keep calm and wait while we establish s2s"
  399. jubalh has left
  400. mukt2 has left
  401. jubalh has joined
  402. Tobias has left
  403. Tobias has joined
  404. adiaholic has joined
  405. zach has left
  406. zach has joined
  407. kokonoe has left
  408. adiaholic has left
  409. Nekit has left
  410. jubalh has left
  411. mukt2 has joined
  412. jubalh has joined
  413. david has joined
  414. zach has left
  415. zach has joined
  416. adiaholic has joined
  417. xalek has joined
  418. zach has left
  419. zach has joined
  420. jubalh has left
  421. adiaholic has left
  422. adiaholic has joined
  423. chronosx88 has left
  424. chronosx88 has joined
  425. kokonoe has joined
  426. waqas has joined
  427. kokonoe has left
  428. mimi89999 has joined
  429. kokonoe has joined
  430. zach has left
  431. zach has joined
  432. jubalh has joined
  433. andy has left
  434. mukt2 has left
  435. kokonoe has left
  436. mukt2 has joined
  437. jubalh has left
  438. rion has left
  439. rion has joined
  440. andy has joined
  441. mukt2 has left
  442. andy has left
  443. zach has left
  444. zach has joined
  445. mukt2 has joined
  446. andy has joined
  447. kokonoe has joined
  448. jmpman has left
  449. adiaholic has left
  450. adiaholic has joined
  451. mukt2 has left
  452. adiaholic has left
  453. jubalh has joined
  454. adiaholic has joined
  455. mukt2 has joined
  456. adiaholic has left
  457. mukt2 has left
  458. jubalh has left
  459. adiaholic has joined
  460. adiaholic has left
  461. chronosx88 has left
  462. adiaholic has joined
  463. kokonoe has left
  464. kokonoe has joined
  465. larma Anyone had a chance to check my last weeks mail https://mail.jabber.org/pipermail/standards/2019-September/036495.html ?
  466. !XSF_Martin has left
  467. derdaniel has joined
  468. chronosx88 has joined
  469. adiaholic has left
  470. kokonoe has left
  471. !XSF_Martin has joined
  472. adiaholic has joined
  473. pdurbin has joined
  474. mukt2 has joined
  475. jubalh has joined
  476. kokonoe has joined
  477. pdurbin has left
  478. lovetox_ yeah also thought this would get at least one response :/
  479. Zash Multi-session-nick is fairly underspecified
  480. Zash larma, vcards have been public, so I'd say "no" to that part
  481. andrey.g has left
  482. zach has left
  483. zach has joined
  484. mukt2 has left
  485. jonas’ has left
  486. jonas’ has joined
  487. jubalh has left
  488. lovetox_ Zash i think it would be nice if prosody adds a "Dont route IQs to other participants" room config option
  489. lovetox_ ejabberd has this
  490. Zash File an issue. I also want to be able to disable PMs.
  491. lovetox_ yes
  492. mukt2 has joined
  493. Zash Would that be full JID routing or also break all vcards?
  494. lovetox_ of course it would break vcard, and thats actually exactly the use case
  495. lovetox_ :)
  496. lovetox_ 1. routing just is doesnt work good or is underspecified for the multi session nick thing
  497. lovetox_ 2. its a privacy issue
  498. eevvoor has left
  499. kokonoe has left
  500. lovetox_ even more so now that prosody even routes it to the pubsub component
  501. jonas’ prosody just routes (some IQs) to the bare JID
  502. lovetox_ or rather the pubsub component answers for the user
  503. jonas’ you mean PEP?
  504. lovetox_ yes
  505. Zash No, it routes to the bare JID
  506. jonas’ I wouldn’t call that "pubsub component" to avoid confusion
  507. Zash It was ejabberd that answers vCard requests to full JIDs
  508. Zash iric
  509. Zash iirc*
  510. lovetox_ which is correct if you go by the XEP isnt it?
  511. Zash wat
  512. lovetox_ the vcard xep says server should answer it for the user
  513. Zash wat
  514. lovetox_ otherwise how would you request a vcard of an offline user?
  515. jonas’ lovetox_, ask the bare JID?
  516. Zash wat
  517. lovetox_ look either we want vcard in muc to work nicely, than a server should answer any vcard request for the user bare or full jid
  518. lovetox_ or we dont want it in a muc (anon maybe), then the muc should not even start to route IQs
  519. Zash If the XEP says that the server should respond to requests to full JIDs then the XEP is wrong and diverges from how everything else in XMPP works.
  520. lovetox_ no it says to respond to bare jid
  521. lovetox_ and how is this ever going to work in MUC?
  522. lovetox_ how can i address your bare jid in a anon room?
  523. Zash You can't.
  524. Zash Server can forward the request to your bare JID, like Prosody does
  525. lovetox_ and you do this now for any IQ request
  526. Zash No, only for a small set of known namespaces, namely vcard-temp, pubsub and vcard4.
  527. lovetox_ yeah and you dont see this as a problem?
  528. Zash No
  529. lovetox_ this is nowhere specificed, its a hack
  530. lovetox_ and one that is a privacy issue on top
  531. Zash As was the vcard-temp routing thing.
  532. Zash However that's considered public data
  533. lovetox_ i consider it public data to people who know my adress
  534. Zash Don't put it in your globally public vcard then
  535. Zash What is the point of the JABBERID field?
  536. mukt2 has left
  537. lovetox_ As i said its fine for people who know my adress, if i join a anon room, the point of the room is exactly to prevent people getting my real adress, but now it seems they dont even need it, because the server is happily routing to the bare jid and giving me the answer
  538. lovetox_ im not saying we should prevent routing IQs, it just should be revisited for public anon rooms
  539. lovetox_ and for non-anon rooms you dont have to route IQs at all
  540. lovetox_ clients should just request the real bare jid
  541. lovetox_ so who needs these public anon rooms that compromise the privacy of their participants? What use case do they fullfill exactly
  542. lovetox_ You want Avatars, public omemo keys, other *private* data, then make your room non-anon and every user that joins knows what he gets into
  543. lovetox_ this idea, i make my room anon, but still keep all features of non-anon rooms, is a bad solution
  544. lovetox_ and i would argue its to the disadvantage of all users that join
  545. Zash I think you exaggerate the privacy impact somewhat.
  546. Zash I also never said I was against having this as a setting.
  547. pep. I don't think saying "public vcard is a privacy issue" is an eggageration :x
  548. Zash Don't put stuff there if you don't want it public for everyone everywhere, which is how vcard-temp works.
  549. kokonoe has joined
  550. jonas’ to be fair, I was also surprised that my avatar is exposed in anon MUCs
  551. Zash We got tons of complaints IIRC when we made vcards (via the PEP-conversion stuff) respect the privacy settings of the corresponding PEP nodes.
  552. Zash So, people have varying expectations.
  553. pep. Ah that reminds me I need to open an issue about that
  554. lovetox_ yes Zash, thats because we did water down anon rooms, so people dont even know anymore what they are there for
  555. Zash Now Prosody makes those public by default, but still respects it if you change their settings.
  556. pep. Prosody still broadcasts my avatar hash in the presence even though I have access_model of vcard4 set to presence
  557. pep. in MUCs*
  558. Zash avatar and vcard4s are separate nodes tho
  559. pep. k
  560. Zash And you can have separate permissions. I do, in fact.
  561. pep. I also do have that node set to presence I think
  562. Zash If you query my vcard through here you only get the avatrarwavatar
  563. lovetox_ And Zash, im not arguing against prosody here, this issue was raised by larma on the last sprint, and we discussed it, and now try to raise awareness in the community
  564. lovetox_ so even if the discussion started with me, asking you for these settings, its more of a general discussion
  565. Zash Some of the problem is that there are two separate issues
  566. lovetox_ in my opinion we should make the consequences clear what anon means, and follow through with it
  567. Zash Or more?
  568. lovetox_ not try and find ways how we can water down anon
  569. lovetox_ how we can bring features to anon that can not work with anon
  570. mimi89999 has left
  571. Zash You mean semi-anon? True anon rooms is dead afaik.
  572. kokonoe has left
  573. lovetox_ yeah of course
  574. lovetox_ i would not go that route arguing true anon is not possible so also fuck semi-anon
  575. Zash I feel like this is a topic for a summit, rather than late saturday. :)
  576. lovetox_ there is a good usecase for semi-anon
  577. lovetox_ but just to be clear, there is no XEP or RFC that tells a muc to route IQs to the bare jid is it?
  578. mimi89999 has joined
  579. pep. lovetox_, what larma quoted in his mail no?
  580. Zash https://xmpp.org/extensions/xep-0045.html#bizrules-iq ?
  581. pep. That doesn't specify bare or full though
  582. lovetox_ ah its not specified
  583. lovetox_ lol
  584. lovetox_ yeah thats a real fail here
  585. Zash Nor which one if there's MSN involved.
  586. Zash I believe prosody picks one (probably the first) as the "primary" session and sends to that.
  587. lovetox_ i mean it would be fine if you route to full jid
  588. lovetox_ then the client can decide itself if he wants to reveal his data or not
  589. jonas’ although larma argued that even that isn’t good enough from a privacy perspective.
  590. Zash That lets yo do timeing things.
  591. jonas’ and you wouldn’t want to DoS a client which joins a busy semi-anon MUC and then has to upload its avatar a gazillion times.
  592. jonas’ (see also https://lab.louiz.org/poezio/poezio/issues/3419 )
  593. lovetox_ jonas its already ddosed with disco info requests :D
  594. jonas’ avatars are an order of magnitude worse though
  595. jonas’ or a few orders actually
  596. Zash disco#info could be cached
  597. lovetox_ if you want to do it real good, you would have to activate on your server to answer vcard requests to full jids for you
  598. lovetox_ Zash avatars are also cached
  599. jonas’ lovetox_, guess what, that exists already
  600. adiaholic has left
  601. jonas’ that’s why vcard is handled by the bare JID ;)
  602. lovetox_ i mean a user configurable setting
  603. lovetox_ not a server admin setting
  604. jonas’ that exists, it’s the visibility of the avatar pubsub node nowadays
  605. jonas’ at least for some implementations, and that’s even specified
  606. jonas’ https://xmpp.org/extensions/xep-0398.html#security
  607. lovetox_ hm yes this could work
  608. Zash As I mentioned, you can fiddle with access control on the avatar and vcard4 nodes to do nice things.
  609. lovetox_ so if i set it to presence, then my avatar is hidden
  610. pep. Maybe we need to add something like "also adjust presence broadcast if a user decides to use something else than open
  611. jonas’ I always forget whether directed presence counts for `presence` or not
  612. Zash jonas’: not
  613. jonas’ k
  614. lovetox_ yeah fine workaround, im of the opinion we should deactivate IQ routing in anon rooms by default
  615. jonas’ lovetox_, I tend to agree with that
  616. Zash "presence" is an awkward name for it since it's based on roster (presence) subscriptions
  617. larma The whole privacy model of vcard and public pep is based on the idea that a person still needs to know your real jid to access them. With semi-anon MUCs that's not the case anymore. Especially in prosodys now also routing pubsub IQs such that they can actually be replied by the server means that I only have two options: Not use OMEMO with non-roster contacts *or* reveal my identity in every semi-anon MUC
  618. larma (I would probably opt for the first, if not every client would now by default make OMEMO pep nodes public)
  619. lovetox_ Zash, whats the motiviation behind not allowing PMs?
  620. zach has left
  621. zach has joined
  622. Zash lovetox_, ever had people join your support room and then PM you support questions?
  623. Zash IIRC it's also been requested by others. Don't remember their motivation. I'm sure there's use for it.
  624. Daniel has left
  625. Daniel has joined
  626. jonas’ I would like to turn off PMs as a user right now.
  627. larma My problem is that I can not rely in any way on IQ routing in semi-anon MUCs, because behavior is diverting between servers. That's why we should at least define the correct behavior. And IMO correct behavior is not to randomly send some IQs to bare and some to full JID
  628. Daniel has left
  629. wurstsalat has left
  630. Daniel has joined
  631. jonas’ larma, I agree on the first part, but I’m not sure on the second part
  632. jonas’ although if we had to pin it down one way, I’d say "route to bare JID"
  633. Daniel has left
  634. Daniel has joined
  635. wurstsalat has joined
  636. larma Well, if we say some IQs are routed to bare and some to full, we would need servers to somehow indicate what they are doing, because it might update...
  637. jonas’ similar to how we version carbon rules at the moment, indeed
  638. lovetox_ larma, server should add a config options to muc, default to not route IQs, and advertise the setting in disco info
  639. lovetox_ then the client can warn its users before joining such a anon but still routing IQs MUC
  640. chronosx88 Hey, guys. Does MAM support for chat room state changes? (E.g. chat room name or subject)
  641. larma lovetox_, yes that would work
  642. jonas’ chronosx88, subject yes, name not
  643. Zash Does it?
  644. chronosx88 And how offline user will know, that room name is changed?
  645. lovetox_ jonas, i dont think subject changes are in MAM
  646. jonas’ lovetox_, oh
  647. derdaniel has left
  648. jonas’ chronosx88, I guess you’d query that when you rejoin the room
  649. chronosx88 Ehm...
  650. lovetox_ chronosx88, you do a disco info to the muc before you join
  651. lovetox_ and if the room name changes, the muc has to issue a status code for changed configuration
  652. lovetox_ which should trigger your client to do again a disco info to get the new name
  653. chronosx88 I just comparing XMPP and Matrix by technical abilities and simplicity
  654. debacle has joined
  655. lovetox_ MAM is a message archive, it does not hold any configuration infos of MUCs
  656. lovetox_ all configuration info is available via disco info to the muc jid
  657. lovetox_ and all changes to the configuration are announced via message to joined and even not joined participants
  658. lovetox_ (if they are in the member list of a muc=)
  659. chronosx88 And... How it can synchronized when user didn't open client?
  660. lovetox_ and you should disco info a muc before you join if you certain configuration fields like muc name are important to you
  661. chronosx88 > And... How it can synchronized when user didn't open client? Or really is offline.
  662. lovetox_ im not sure what you mean, if you are offline per definition nothing can be synced
  663. lovetox_ because you are offline
  664. chronosx88 Yeah
  665. lovetox_ if you start your client, and join the rooms the user was in last time
  666. lovetox_ before you join, the client sends a disco info to the muc, to get the current configuration
  667. pdurbin has joined
  668. lovetox_ you could call that the "sync"
  669. chronosx88 Ok
  670. lovetox_ from that point on if you are joined, and configuration changes while you are online and joined
  671. lovetox_ the muc informs you about it
  672. Nekit has joined
  673. chronosx88 Another question: how I can sync unread messages count between clients?
  674. lovetox_ your best bet is XEP-0333 chat markers
  675. Daniel has left
  676. chronosx88 And point in chat room, when I last time stopped reading
  677. Daniel has joined
  678. chronosx88 > your best bet is XEP-0333 chat markers Hm... Ok, will read it
  679. lovetox_ where you stopped reading is a client UX problem, with chat markers, you can mark the messages you read on a client
  680. lovetox_ and sync this info to your other clients, which can act accordingly
  681. Zash Did anyone have plans to make a PEP based unread message tracking thing?
  682. Daniel has left
  683. Daniel has joined
  684. larma Zash, why?
  685. APach has left
  686. Zash IIRC there was talk about something like that, or at least changing 333.
  687. Daniel has left
  688. Daniel has joined
  689. pep. Zash, on, I'd like that
  690. pep. To sync reading state between clients
  691. larma but you can already do that using MAM, no?
  692. pep. Can you?
  693. Zash How?
  694. larma well if a 333 marker is send as a message, MAM should store it
  695. larma > Clients SHOULD use Message Archiving (XEP-0136) [7] or Message Archive Management (XEP-0313) [8] to support offline updating of Chat Markers. Chat Markers SHOULD be archived, so they can be fetched and set regardless of whether the other users in a chat are online. from 333
  696. pep. Sending only 333 to myself then?
  697. Zash Never seen that before.
  698. pep. I don't especially want others to know
  699. Daniel has left
  700. Daniel has joined
  701. lovetox_ pep., i think this would be possible
  702. lovetox_ you could send chatmarkers to yourself
  703. lovetox_ its very ugly because you get a hell of duplicated messages
  704. pep. yeah
  705. lovetox_ but i think this would work
  706. larma Ah right, If you don't want the other end to know, 333 is probably not best suited
  707. lovetox_ BUT only if you use unique stanza ids in every conversation
  708. pdurbin has left
  709. lovetox_ otherwise you lose the context
  710. larma Yeah, makes sense, if you don't want to send to other end, PEP is better than MAM
  711. Shell has left
  712. Shell has joined
  713. chronosx88 has left
  714. Nekit has left
  715. chronosx88 has joined
  716. Mikaela has left
  717. Mikaela has joined
  718. lovetox_ you could do this analog to bookmarks 2
  719. lovetox_ one node, with X items, and item-id = jid of contact
  720. lovetox_ then add the current stanza id that you read
  721. karoshi has left
  722. chronosx88 has left
  723. karoshi has joined
  724. chronosx88 has joined
  725. waqas has left
  726. kokonoe has joined
  727. andrey.g has joined
  728. chronosx88 has left
  729. mukt2 has joined
  730. mukt2 has left
  731. kokonoe has left
  732. matkor has left
  733. matkor has joined
  734. Daniel has left
  735. Daniel has joined
  736. !XSF_Martin has left
  737. !XSF_Martin has joined
  738. mukt2 has joined
  739. jason has joined
  740. mukt2 has left
  741. mukt2 has joined
  742. zach has left
  743. zach has joined
  744. karoshi has left
  745. mimi89999 has left
  746. mimi89999 has joined
  747. Daniel has left
  748. pdurbin has joined
  749. pdurbin has left
  750. kokonoe has joined
  751. lovetox_ has left
  752. jason has left
  753. kokonoe has left
  754. goffi has left
  755. Daniel has joined
  756. APach has joined
  757. mukt2 has left
  758. Daniel has left
  759. LNJ has left
  760. Mikaela has left
  761. Douglas Terabyte has left
  762. Douglas Terabyte has joined
  763. zach has left
  764. zach has joined
  765. Daniel has joined
  766. LNJ has joined
  767. kokonoe has joined
  768. Daniel has left
  769. zach has left
  770. zach has joined
  771. Daniel has joined