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’


  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


  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


  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


  275. Zash

    It should still be idempotent tho?

  276. lovetox_


  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


  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_


  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_


  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


  509. Zash


  510. lovetox_

    which is correct if you go by the XEP isnt it?

  511. Zash


  512. lovetox_

    the vcard xep says server should answer it for the user

  513. Zash


  514. lovetox_

    otherwise how would you request a vcard of an offline user?

  515. jonas’

    lovetox_, ask the bare JID?

  516. Zash


  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


  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.


  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_


  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’


  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’


  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


  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


  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


  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


  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.


  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