XSF Discussion - 2019-10-23

  1. adiaholic has joined

  2. Shell has left

  3. Shell has joined

  4. Shell has left

  5. Shell has joined

  6. neshtaxmpp has left

  7. neshtaxmpp has joined

  8. Daniel has joined

  9. aj has joined

  10. mukt2 has joined

  11. Kev has joined

  12. Kev has left

  13. Kev has joined

  14. Daniel has left

  15. mukt2 has left

  16. Daniel has joined

  17. pdurbin has joined

  18. pdurbin has left

  19. Kev has left

  20. arc has joined

  21. Kev has joined

  22. Kev has left

  23. Kev has joined

  24. mukt2 has joined

  25. Kev has left

  26. Kev has joined

  27. mukt2 has left

  28. lskdjf has left

  29. neshtaxmpp has left

  30. neshtaxmpp has joined

  31. waqas has left

  32. Shell has left

  33. Wojtek has left

  34. waqas has joined

  35. Kev has left

  36. Kev has joined

  37. Kev has left

  38. Kev has joined

  39. arc has left

  40. arc has joined

  41. arc has left

  42. arc has joined

  43. mimi89999 has left

  44. arc has left

  45. arc has joined

  46. Kev has left

  47. mimi89999 has joined

  48. Kev has joined

  49. arc has left

  50. pdurbin has joined

  51. arc has joined

  52. Kev has left

  53. Yagiza has joined

  54. Kev has joined

  55. mimi89999 has left

  56. mimi89999 has joined

  57. Kev has left

  58. mukt2 has joined

  59. andy has joined

  60. arc has left

  61. arc has joined

  62. mukt2 has left

  63. pdurbin has left

  64. waqas has left

  65. waqas has joined

  66. Kev has joined

  67. j.r has left

  68. arc has left

  69. arc has joined

  70. Kev has left

  71. Kev has joined

  72. jubalh has joined

  73. Tobias has joined

  74. j.r has joined

  75. xalek has left

  76. Nekit has joined

  77. j.r has left

  78. Kev has left

  79. j.r has joined

  80. mathijs has left

  81. mathijs has joined

  82. LNJ has joined

  83. karoshi has joined

  84. waqas has left

  85. Kev has joined

  86. waqas has joined

  87. emus has joined

  88. Kev has left

  89. Yagiza has left

  90. waqas has left

  91. Yagiza has joined

  92. mukt2 has joined

  93. Kev has joined

  94. pdurbin has joined

  95. mukt2 has left

  96. wurstsalat has joined

  97. Kev has left

  98. Kev has joined

  99. pdurbin has left

  100. pdurbin has joined

  101. Kev has left

  102. Kev has joined

  103. Mikaela has joined

  104. Kev has left

  105. jmpman has joined

  106. mimi89999 has left

  107. Steve Kille has left

  108. debacle has joined

  109. Steve Kille has joined

  110. pdurbin has left

  111. jmpman has left

  112. mukt2 has joined

  113. pdurbin has joined

  114. mukt2 has left

  115. mimi89999 has joined

  116. intosi has left

  117. larma has left

  118. goffi has joined

  119. mr.fister has left

  120. larma has joined

  121. adiaholic has left

  122. adiaholic has joined

  123. Alex has left

  124. Kev has joined

  125. Alex has joined

  126. karoshi has left

  127. karoshi has joined

  128. Guus

    xep-0313 question: what is the best way for a client to 'sync up' with the server-sided message archive? The protocol allows to be synced up based on timestamps, but also notes that those might not be unique. It states that the client MUST NOT depend on the presence of XEP-0359 IDs. I'm thinking that RSM's 'before' and 'after' identifiers are supposed to be opaque, so clients can't depend on that to be a XEP-0359 IDs either?

  129. jonas’

    Guus, yet everyone does

  130. Guus

    Which one?

  131. jonas’

    Guus, assume that they’re '0359 IDs.

  132. jonas’

    nevermind that it’s then undefined how that even works with RSM, but that’s a topic for a different, long-winded argument which I have on my to-do list

  133. mukt2 has joined

  134. Holger


  135. Guus

    'they' being the supposedly-opaque RSM before and after values?

  136. Holger

    > When a message is archived, the server MUST add an <stanza-id/> element as defined in Unique and Stable Stanza IDs (XEP-0359) [2] to the message

  137. jonas’

    Guus, yes

  138. Guus

    jonas’ thanks

  139. Holger

    > which informs the recipient of where and under what ID the message is stored.

  140. Holger

    So those are clearly the before/after IDs, no?

  141. Daniel

    Yes the RSM situation is a bit weird right now. Matt is working on a fix

  142. Daniel

    But it works OK with rsm after for now

  143. jonas’

    my last info was that Matt is disagreeing that there’s a problem.

  144. jonas’

    and is waiting for a proper argument to show what’s even kaputt

  145. Holger

    What's the weirdness?

  146. pep.

    There was a discussion not so long ago on this channel

  147. Guus

    Holger : RSM says: > The responding entity may generate these UIDs in any way, as long as the UIDs are unique in the context of all possible members of the full result set. Each UID MAY be based on part of the content of its associated item, as shown below, or on an internal table index. Another possible method is to serialize the XML of the item and then hash it to generate the UID. Note: The requesting entity MUST treat all UIDs as opaque.

  148. Daniel

    I've seen a draft where query itself has a after-id value

  149. Guus

    note that I don't mind using XEP-0359 IDs in RSM - but it might avoid confusion to explicitly state that.

  150. Daniel

    And Matt explained the problem to me which I didn't saw myself before that

  151. Daniel

    So I'd say he is aware

  152. jonas’

    Holger, that things get weird when you want to request stuff between two IDs from MAM

  153. jonas’

    Daniel, oh, nice

  154. jonas’

    so that’s getting fixed

  155. Holger

    Guus: You mean the very last sentence?

  156. Guus

    Holger yes.

  157. Holger

    jonas': So that's about the question whether before/after can be combined?

  158. pep.


  159. pep.

    jonas’, Daniel ^

  160. pep.

    In this room

  161. Guus

    But note that today, I'm looking for implementation guidelines, not to address potential improvements to the protocol.

  162. Daniel

    > But note that today, I'm looking for implementation guidelines, not to address potential improvements to the protocol. For normal catchup just do rsm with the last stanza id

  163. Guus

    everyone uses XEP-0359 IDs in MAM2 RSM? Good enough for me.

  164. Daniel

    And empty query

  165. chronosx88 has joined

  166. Holger

    jonas': Isn't that unrelated to Guus' question about stanza IDs being MAM IDs? Which I think 0313 is totally clear about, which solves any opaqueness doubts I would've thought?

  167. Daniel

    And when parsing the message make sure you validate the stanza id feature on the archiving entity

  168. Holger

    Guus: Yes, and as I said I'd argue that's not just common practice but clearly guaranteed by 0313.

  169. Guus

    Daniel "and empty query" ?

  170. Daniel

    Yes don't limit the query with a time stamp or something

  171. Holger

    Or the mam:2 feature, as that depends on stanza-ID.

  172. Daniel

    *if* you have a stanza id

  173. Guus

    Holger I'd say that it could be stated more explicitly in 313 - It wasn't obvious to me, so it won't be obvious to at least other people as bad in reading XEPs as me. 🙂

  174. Guus

    Daniel understood, thanks.

  175. Holger

    I would've thought my above quote makes this very explicit but whatever.

  176. Guus

    Holger I'm one of those people that labels his label printer with "label printer" 😉

  177. Holger


  178. Holger

    There's also this note: > Previous versions of this protocol did not specify any interaction with stanza-id, and clients MUST NOT interpret XEP-0359 IDs in messages as archive IDs unless the server advertises support for 'urn:xmpp:mam:2' specifically.

  179. Holger

    This this only implies the identity of 0359 and 0313 IDs by inversion of the statement.

  180. Holger

    *Admittedly this ...

  181. Guus

    Doesn't hurt to make it more explicit. 🙂

  182. Guus

    Thanks people!

  183. Daniel

    If I recall correctly the NS of mam wasn't bumped before stanza id mandated the cleaning

  184. Daniel

    So technically you could have a combination of mam2 and stanza id that doesn't do cleaning

  185. Daniel

    But whatever

  186. Holger

    Ah. That may well be true.

  187. mukt2 has left

  188. Holger

    Daniel: This would be addressed by checking for sid:0 in addition to mam:2, right?

  189. Daniel

    Holger: yes that's why I said look for the stanza id feature

  190. Holger

    Makes sense.

  191. Daniel

    But I don't think it's a problem in the wild. Prosody for example deliberately limited itself to mam1 before they had proper stanza id cleaning

  192. mimi89999 has left

  193. mimi89999 has joined

  194. flow

    "stanza id cleaning" being the requirement that entities check for stanza-id's with a 'by' value of the checking entity?

  195. Daniel


  196. Holger

    Daniel: Then again some MUC MAM module announced mam:2 without injecting stanza IDs at all, IIRC.

  197. Holger

    But that's been fixed and I'd just stick to the spec if I was a client author. And blame admins running outdated servers if things go wrong.

  198. flow

    Daniel, IIRC that requirement has always been tehre

  199. eevvoor has joined

  200. Holger

    flow: Daniel clarified the Business Rules in 0.5.0. I don't think they stated this (as clearly) before: "Stanza ID generating entities, which encounter a <stanza-id/> element where the 'by' attribute matches the 'by' attribute they would otherwise set, MUST delete that element even if they are not adding their own stanza ID."

  201. Holger

    flow: Also rule 7, i.e. the exact value of the 'by' attribute, wasn't as clear before, IIRC.

  202. Holger

    (Text was contradicting example or something, so some servers would do by=$service_jid.)

  203. debacle has left

  204. flow

    Holger, I think it was clear before, or I do not understand the issue the commit message tries to explain

  205. flow

    But yes, it wasn't clearly defined what the by value for MUCs is (MUC service domain vs MUC (bare) JID)

  206. pdurbin has left

  207. Daniel has left

  208. lskdjf has joined

  209. Daniel has joined

  210. Zash has left

  211. Zash has joined

  212. jubalh has left

  213. eevvoor has left

  214. Dele (Mobile) has joined

  215. jubalh has joined

  216. emus has left

  217. emus has joined

  218. adiaholic has left

  219. adiaholic has joined

  220. !XSF_Martin has left

  221. !XSF_Martin has joined

  222. aj has left

  223. mukt2 has joined

  224. Yagiza has left

  225. Yagiza has joined

  226. adiaholic has left

  227. adiaholic has joined

  228. dele has joined

  229. dele has left

  230. Kev has left

  231. pdurbin has joined

  232. winfried has left

  233. winfried has joined

  234. pdurbin has left

  235. Zash has left

  236. Zash has joined

  237. vanitasvitae has left

  238. vanitasvitae has joined

  239. COM8 has joined

  240. Shell has joined

  241. adiaholic has left

  242. Nekit has left

  243. led has left

  244. led has joined

  245. mukt2 has left

  246. Nekit has joined

  247. led has left

  248. led has joined

  249. Shell has left

  250. COM8 has left

  251. led has left

  252. winfried has left

  253. winfried has joined

  254. COM8 has joined

  255. led has joined

  256. andrey.g has left

  257. mathijs has left

  258. mathijs has joined

  259. mathijs has left

  260. COM8 has left

  261. andrey.g has joined

  262. mathijs has joined

  263. jubalh has left

  264. waqas has joined

  265. waqas has left

  266. Kev has joined

  267. eevvoor has joined

  268. adiaholic has joined

  269. adiaholic has left

  270. adiaholic has joined

  271. jubalh has joined

  272. adiaholic has left

  273. adiaholic has joined

  274. adiaholic has left

  275. adiaholic has joined

  276. Kev has left

  277. pdurbin has joined

  278. pdurbin has left

  279. goffi has left

  280. mukt2 has joined

  281. winfried has left

  282. winfried has joined

  283. Nekit has left

  284. Nekit has joined

  285. Mikaela has left

  286. Mikaela has joined

  287. Nekit has left

  288. Nekit has joined

  289. jubalh has left

  290. mathijs has left

  291. mathijs has joined

  292. Kev has joined

  293. jubalh has joined

  294. winfried has left

  295. winfried has joined

  296. j.r has left

  297. eevvoor has left

  298. adiaholic has left

  299. adiaholic has joined

  300. aj has joined

  301. mukt2 has left

  302. mukt2 has joined

  303. adiaholic has left

  304. adiaholic has joined

  305. waqas has joined

  306. adiaholic has left

  307. adiaholic has joined

  308. adiaholic has left

  309. Kev has left

  310. Kev has joined

  311. jubalh has left

  312. waqas has left

  313. winfried has left

  314. winfried has joined

  315. pdurbin has joined

  316. Kev has left

  317. Wojtek has joined

  318. j.r has joined

  319. mathijs has left

  320. mathijs has joined

  321. stpeter has joined

  322. mathijs has left

  323. pdurbin has left

  324. mathijs has joined

  325. Yagiza has left

  326. Yagiza has joined

  327. arc has left

  328. arc has joined

  329. rion

    Do we have any XEP explaining what to do if for example I want to start a Jingle FT (requesting a file) in a MUC with a specific user connected to the MUC from two clients with the same nickname and only one of the clients has the file?

  330. MattJ


  331. rion

    then when MUC is going to be deprecated?

  332. jonas’

    in favour of what?

  333. rion


  334. jonas’

    this problem isn’t fully solved for MIX either.

  335. rion


  336. jonas’

    particularly in anonymous mixes

  337. Shell has joined

  338. winfried has left

  339. rion

    then we still probably need some unique identifier for each connection to the muc regardless of nickname.

  340. winfried has joined

  341. jonas’

    which is tricky

  342. jonas’

    there has been a long discussion on the list about this issue for MIX

  343. jonas’

    we need to stuff four identifiers (MIX domain, MIX channel, user identifier, client/connection identifier) in a thing which only has three fields (a JID)

  344. jonas’

    and each solution has its own drawbacks.

  345. rion

    channel@domain/user?uuid ?

  346. rion

    xmpp rfc has to be fixed :)

  347. jonas’

    problem with that is that bare JIDs are as it stands now very useful for asserting equal identities

  348. jonas’

    i.e. if a message comes from two different full JIDs but the same bare JID (and is not of type="groupchat"), you can be fairly certain that it’s from the same entity

  349. jonas’

    that would break with your proposed scheme

  350. jonas’

    the obvious other solution is user?channel@domain/uuid, but I don’t recall what problem folks had with that

  351. jonas’

    except that there’s no trivial way (you have to parse the localpart) to associate the user to a channel

  352. goffi has joined

  353. rion

    user?channel@domain/uuid lgtm

  354. mukt2 has left

  355. mukt2 has joined

  356. jonas’

    rion, thread(s) start here: https://mail.jabber.org/pipermail/standards/2018-May/035017.html

  357. jonas’

    there are about four or five threads about this topic, it was a real sprawl

  358. 404.city Support has joined

  359. 404.city Support has left

  360. 404.city Support has joined

  361. rion

    jonas’: the idea with <mix channel="some-channel"/> lgtm too. I haven't started implementing MIX yet. So whatever works best :)

  362. lovetox has joined

  363. j.r has left

  364. j.r has joined

  365. arc has left

  366. arc has joined

  367. mukt2 has left

  368. mukt2 has joined

  369. jabberjocke has left

  370. waqas has joined

  371. waqas has left

  372. waqas has joined

  373. 404.city Support has left

  374. waqas has left

  375. adiaholic has joined

  376. Steve Kille has left

  377. Mikaela has left

  378. jabberjocke has joined

  379. Mikaela has joined

  380. !XSF_Martin has left

  381. !XSF_Martin has joined

  382. Steve Kille has joined

  383. stpeter has left

  384. stpeter has joined

  385. jabberjocke has left

  386. jabberjocke has joined

  387. mukt2 has left

  388. mukt2 has joined

  389. Kev has joined

  390. mathijs has left

  391. mathijs has joined

  392. Mikaela has left

  393. Mikaela has joined

  394. pdurbin has joined

  395. j.r has left

  396. mukt2 has left

  397. jabberjocke has left

  398. pdurbin has left

  399. mukt2 has joined

  400. jabberjocke has joined

  401. Yagiza has left

  402. jabberjocke has left

  403. jabberjocke has joined

  404. jabberjocke has left

  405. jubalh has joined

  406. mathijs has left

  407. mathijs has joined

  408. aj has left

  409. debacle has joined

  410. jmpman has joined

  411. Nekit has left

  412. j.r has joined

  413. Kev has left

  414. !XSF_Martin has left

  415. !XSF_Martin has joined

  416. Guus

    Looking at the CS2020 last call, I was surprised to see XEP-0392: Consistent Color Generation in there. What's the rationale for including it?

  417. jonas’

    Guus, discuss! :)

  418. Guus

    Aren't I doing that? 🙂

  419. jonas’

    Guus, on list is probably a better way to do that

  420. Ge0rG

    Guus: it was added before all the nifty styling requriements were removed from 0392.

  421. Guus

    Ge0rG I noticed that XEP-0385 is mentioned both in section 1.1 "Changes since 2019", but also in section 3 "Future Development". Is that an error, or intended?

  422. Ge0rG

    Guus: it's optional in §2.3 as well.

  423. Ge0rG

    Guus: the issue I have is that you can't really have optional things in the compliance tables.

  424. Ge0rG

    so I'm a bit torn on where to have it and where not to.

  425. Ge0rG

    But the triple-listing is probably a bit too much

  426. Ge0rG

    Still, I'd appreciate a list discussion

  427. Guus

    I'd argue that if you're including it, then there's no point of adding it also as a 'keep an eye on this one for the future'

  428. Ge0rG


  429. Zash

    Meta: The LC template seems weird for compliance suites.

  430. Guus

    I've not followed it.

  431. Guus

    sue me.

  432. Guus

    I'm happy to see this take off before Christmas, though 🙂

  433. Guus

    thanks for that

  434. Chobbes has joined

  435. jubalh has left

  436. Chobbes has left

  437. jmpman has left

  438. rion has left

  439. adiaholic has left

  440. mukt2 has left

  441. jubalh has joined

  442. mukt2 has joined

  443. xalek has joined

  444. rion has joined

  445. mukt2 has left

  446. mukt2 has joined

  447. debacle has left

  448. mathijs has left

  449. mathijs has joined

  450. lovetox has left

  451. stpeter has left

  452. jabberjocke has joined

  453. j.r has left

  454. pdurbin has joined

  455. DebXWoody has left

  456. Nekit has joined

  457. lovetox has joined

  458. mukt2 has left

  459. DebXWoody has joined

  460. debacle has joined

  461. pdurbin has left

  462. jonas’

    Zash, true, saw that too right after I confirmed

  463. mukt2 has joined

  464. andy has left

  465. stpeter has joined

  466. mukt2 has left

  467. jtyntv has joined

  468. goffi has left

  469. jtyntv

    yoo is there any were on here or icq i can get free ccs

  470. eevvoor has joined

  471. mukt2 has joined

  472. Zash has left

  473. Zash has joined

  474. jtyntv has left

  475. stpeter


  476. mukt2 has left

  477. chronosx88 has left

  478. moparisthebest

    jtyntv, here you go: https://www.creditcardvalidator.org/generator

  479. goffi has joined

  480. mukt2 has joined

  481. lskdjf

    credit cards? 😮 I'm sure they merely wanted to exchange with others about planting trees to achieve Carbon Capture and Storage (CCS). But you judgemental people and your prejudice ruin everything!!

  482. chronosx88 has joined

  483. led has left

  484. Daniel has left

  485. Daniel has joined

  486. Nekit has left

  487. eevvoor has left

  488. Chobbes has joined

  489. rion has left

  490. jubalh has left

  491. Vaulor has left

  492. Seve has left

  493. rion has joined

  494. jubalh has joined

  495. arc has left

  496. mukt2 has left

  497. arc has joined

  498. jubalh has left

  499. mukt2 has joined

  500. LNJ has left

  501. Daniel has left

  502. Daniel has joined

  503. jubalh has joined

  504. jubalh has left

  505. Kev has joined

  506. jubalh has joined

  507. jubalh has left

  508. stpeter has left

  509. mukt2 has left

  510. goffi has left

  511. chronosx88 has left

  512. Vaulor has joined

  513. Tobias has left

  514. mukt2 has joined

  515. Seve has joined

  516. pdurbin has joined

  517. pdurbin has left

  518. lovetox has left

  519. mukt2 has left

  520. Mikaela has left

  521. mukt2 has joined

  522. Chobbes has left

  523. moparisthebest has left

  524. moparisthebest has joined

  525. karoshi has left

  526. emus has left

  527. emus has joined

  528. neshtaxmpp has left

  529. mukt2 has left

  530. mukt2 has joined

  531. mukt2 has left

  532. mukt2 has joined

  533. pdurbin has joined

  534. matlag has left

  535. mukt2 has left

  536. stpeter has joined

  537. pdurbin has left

  538. mukt2 has joined

  539. typikol has joined

  540. typikol has left

  541. matlag has joined

  542. neshtaxmpp has joined

  543. mukt2 has left

  544. debacle has left

  545. mukt2 has joined

  546. mukt2 has left

  547. mukt2 has joined

  548. moparisthebest has left

  549. moparisthebest has joined

  550. mukt2 has left

  551. mukt2 has joined