XSF logo 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 Hm?
  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. https://matthewwild.co.uk/uploads/stdin-s2ilB8Kj
  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 Yes
  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 No
  331. rion then when MUC is going to be deprecated?
  332. jonas’ in favour of what?
  333. rion mix
  334. jonas’ this problem isn’t fully solved for MIX either.
  335. rion oh
  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 fair
  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 beautiful
  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