XSF Discussion - 2018-02-28


  1. Guus has left

  2. dwd has left

  3. jubalh has left

  4. Neustradamus has left

  5. Dave Cridland has left

  6. Guus has left

  7. Guus has left

  8. dwd has left

  9. Neustradamus has joined

  10. ralphm has left

  11. moparisthebest has joined

  12. ralphm has joined

  13. efrit has left

  14. Dave Cridland has left

  15. dwd has left

  16. Guus has left

  17. la|r|ma has joined

  18. Dave Cridland has left

  19. Guus has left

  20. Dave Cridland has left

  21. jjrh has left

  22. Guus has left

  23. ralphm has left

  24. vanitasvitae has left

  25. ralphm has joined

  26. dwd has left

  27. stefandxm has joined

  28. jjrh has left

  29. Guus has left

  30. jjrh has left

  31. Guus has left

  32. jjrh has left

  33. jjrh has left

  34. Guus has left

  35. Guus has left

  36. la|r|ma has joined

  37. lskdjf has joined

  38. jjrh has left

  39. ralphm has left

  40. jjrh has left

  41. Guus has left

  42. ralphm has joined

  43. Guus has left

  44. ovo has left

  45. Guus has left

  46. Guus has left

  47. Guus has left

  48. SamWhited has left

  49. Guus has left

  50. Guus has left

  51. Dave Cridland has left

  52. ralphm has left

  53. dwd has left

  54. ralphm has joined

  55. Maranda has left

  56. Maranda has joined

  57. Guus has left

  58. Guus has left

  59. Guus has left

  60. Guus has left

  61. ralphm has left

  62. ralphm has joined

  63. Dave Cridland has left

  64. Dave Cridland has left

  65. Dave Cridland has left

  66. jere has joined

  67. Maranda has left

  68. Maranda has joined

  69. ralphm has joined

  70. Guus has left

  71. Dave Cridland has left

  72. Maranda has left

  73. Maranda has left

  74. jere has left

  75. jere has joined

  76. Guus has left

  77. Dave Cridland has left

  78. dwd has left

  79. Dave Cridland has left

  80. Dave Cridland has left

  81. Maranda has left

  82. Guus has left

  83. Guus has left

  84. ralphm has joined

  85. Guus has left

  86. dwd has left

  87. Guus has left

  88. Guus has left

  89. Guus has left

  90. SamWhited has left

  91. moparisthebest has joined

  92. vanitasvitae has left

  93. Dave Cridland has left

  94. moparisthebest has left

  95. Dave Cridland has left

  96. Yagiza has joined

  97. andy has joined

  98. Guus has left

  99. Guus has left

  100. Guus has left

  101. jjrh has left

  102. tux has left

  103. tux has joined

  104. rion has joined

  105. Guus has left

  106. jjrh has left

  107. dwd has left

  108. Guus has left

  109. Guus has left

  110. dwd has left

  111. Guus has left

  112. rion has left

  113. rion has joined

  114. Guus has left

  115. Guus has left

  116. Guus has left

  117. Guus has left

  118. @Alacer has left

  119. @Alacer has joined

  120. andy has left

  121. Lance has left

  122. rion has left

  123. Guus has left

  124. andy has joined

  125. Guus has left

  126. ralphm has joined

  127. Guus has left

  128. Guus has left

  129. ludo has joined

  130. Guus has left

  131. Guus has left

  132. Nekit has left

  133. Dave Cridland has left

  134. dwd has left

  135. Dave Cridland has left

  136. Guus has left

  137. @Alacer has left

  138. mimi89999 has left

  139. mimi89999 has left

  140. j.r has left

  141. j.r has joined

  142. jere has joined

  143. dwd has left

  144. j.r has left

  145. j.r has joined

  146. tux has left

  147. tux has joined

  148. Guus has left

  149. Guus has left

  150. @Alacer has joined

  151. Guus has left

  152. ralphm has joined

  153. goffi has joined

  154. ralphm has joined

  155. Guus has left

  156. Guus has left

  157. andy has left

  158. andy has joined

  159. ralphm has left

  160. ralphm has joined

  161. moparisthebest has joined

  162. ludo has left

  163. ludo has joined

  164. @Alacer has left

  165. Dave Cridland has left

  166. Dave Cridland has left

  167. Dave Cridland has left

  168. Dave Cridland has left

  169. lovetox has joined

  170. SaltyBones has left

  171. lovetox has left

  172. andy has left

  173. SamWhited has left

  174. Dave Cridland has left

  175. Dave Cridland has left

  176. edhelas

    We do indeed

  177. Dave Cridland has left

  178. Dave Cridland has left

  179. dwd has left

  180. Dave Cridland has left

  181. Guus has left

  182. goffi

    Hi, SàT support it too

  183. dwd has left

  184. @Alacer has joined

  185. Guus has left

  186. rtq3 has joined

  187. dwd has left

  188. rion has left

  189. rion has joined

  190. SaltyBones

    SaT?

  191. goffi

    SaltyBones: https://salut-a-toi.org

  192. Guus has left

  193. Guus has left

  194. andy has joined

  195. vanitasvitae

    Just read the XMPP Newsletter. Good work :)

  196. daniel

    Oh there is one already?

  197. daniel

    Is it available on a website? Or is it literally just a newsletter?

  198. vanitasvitae

    https://xmpp.org/2018/02/the-xmpp-newsletter-28-february-2018

  199. goffi

    neat :)

  200. vanitasvitae

    Basically it is a link list, but there were one or two articles that slipped my eyes

  201. rtq3 has left

  202. rtq3 has joined

  203. jubalh has joined

  204. Lance has joined

  205. Dave Cridland has left

  206. Dave Cridland has left

  207. xnyhps has joined

  208. tim@boese-ban.de has joined

  209. tim@boese-ban.de has joined

  210. tim@boese-ban.de has joined

  211. tim@boese-ban.de has joined

  212. tim@boese-ban.de has joined

  213. tim@boese-ban.de has joined

  214. tim@boese-ban.de has joined

  215. tim@boese-ban.de has joined

  216. tim@boese-ban.de has joined

  217. tim@boese-ban.de has joined

  218. tim@boese-ban.de has joined

  219. tim@boese-ban.de has joined

  220. tim@boese-ban.de has joined

  221. tim@boese-ban.de has joined

  222. tim@boese-ban.de has joined

  223. tim@boese-ban.de has joined

  224. tim@boese-ban.de has joined

  225. tim@boese-ban.de has joined

  226. tim@boese-ban.de has joined

  227. Dave Cridland has left

  228. tim@boese-ban.de has joined

  229. tim@boese-ban.de has joined

  230. tim@boese-ban.de has joined

  231. Dave Cridland has left

  232. tim@boese-ban.de has joined

  233. tim@boese-ban.de has joined

  234. tim@boese-ban.de has joined

  235. tim@boese-ban.de has joined

  236. dwd has left

  237. tim@boese-ban.de has joined

  238. tim@boese-ban.de has joined

  239. tim@boese-ban.de has joined

  240. tim@boese-ban.de has joined

  241. tim@boese-ban.de has joined

  242. tim@boese-ban.de has joined

  243. xnyhps has left

  244. tim@boese-ban.de has joined

  245. Dave Cridland has left

  246. tim@boese-ban.de has joined

  247. tim@boese-ban.de has joined

  248. tim@boese-ban.de has joined

  249. tim@boese-ban.de has joined

  250. tim@boese-ban.de has joined

  251. tim@boese-ban.de has joined

  252. tim@boese-ban.de has joined

  253. tim@boese-ban.de has joined

  254. tim@boese-ban.de has joined

  255. tim@boese-ban.de has joined

  256. tim@boese-ban.de has joined

  257. tim@boese-ban.de has joined

  258. tim@boese-ban.de has joined

  259. tim@boese-ban.de has joined

  260. tim@boese-ban.de has joined

  261. tim@boese-ban.de has joined

  262. tim@boese-ban.de has joined

  263. tim@boese-ban.de has joined

  264. tim@boese-ban.de has joined

  265. Dave Cridland has left

  266. xnyhps has joined

  267. andy has left

  268. Dave Cridland has left

  269. rion has left

  270. SaltyBones has left

  271. dwd has left

  272. Kev has joined

  273. dwd has left

  274. Guus has left

  275. ralphm has joined

  276. Maranda has joined

  277. @Alacer has left

  278. Dave Cridland has left

  279. rion has left

  280. pep. has joined

  281. j.r has left

  282. j.r has joined

  283. Dave Cridland has left

  284. Steve Kille has left

  285. Steve Kille has left

  286. Dave Cridland has left

  287. dwd has left

  288. remko has joined

  289. @Alacer has joined

  290. Dave Cridland has left

  291. Dave Cridland has left

  292. andy has joined

  293. matlag has joined

  294. Lance has left

  295. daniel has left

  296. dwd has left

  297. stefandxm has left

  298. andy has left

  299. Steve Kille has joined

  300. jubalh has joined

  301. Dave Cridland has left

  302. dwd has left

  303. vanitasvitae has left

  304. vanitasvitae has joined

  305. j.r has joined

  306. j.r has joined

  307. ralphm has left

  308. daniel has left

  309. Alex has joined

  310. @Alacer has left

  311. Lance has joined

  312. rtq3 has left

  313. Dave Cridland has left

  314. rtq3 has joined

  315. dwd has left

  316. tim@boese-ban.de has joined

  317. tim@boese-ban.de has joined

  318. tim@boese-ban.de has joined

  319. tim@boese-ban.de has joined

  320. tim@boese-ban.de has joined

  321. tim@boese-ban.de has joined

  322. tim@boese-ban.de has joined

  323. tim@boese-ban.de has joined

  324. Alex has left

  325. tim@boese-ban.de has joined

  326. tim@boese-ban.de has joined

  327. tim@boese-ban.de has joined

  328. tim@boese-ban.de has joined

  329. tim@boese-ban.de has joined

  330. tim@boese-ban.de has joined

  331. tim@boese-ban.de has joined

  332. tim@boese-ban.de has joined

  333. tim@boese-ban.de has joined

  334. tim@boese-ban.de has joined

  335. tim@boese-ban.de has joined

  336. tim@boese-ban.de has joined

  337. Dave Cridland has left

  338. tim@boese-ban.de has joined

  339. tim@boese-ban.de has joined

  340. dwd has left

  341. tim@boese-ban.de has joined

  342. @Alacer has joined

  343. SaltyBones has left

  344. rion has left

  345. @Alacer has left

  346. jubalh has joined

  347. jubalh has left

  348. lskdjf has joined

  349. la|r|ma has joined

  350. ralphm has left

  351. la|r|ma has joined

  352. la|r|ma has joined

  353. ludo has left

  354. ludo has joined

  355. Ge0rG

    I love it how xmpp.is say they won't support the spam fighting manifesto, and then describe how they essentially implement each of the stated requirements <https://xmpp.is/2018/02/21/the-jabber-spam-fighting-manifesto/>

  356. moparisthebest has joined

  357. rion has left

  358. jubalh has joined

  359. moparisthebest has joined

  360. Dave Cridland has left

  361. Maranda

    Ge0rG, infact xmpp.is is one of the servers I get spim hits from atm, *the hilarity ™️®️*

  362. ralphm has joined

  363. Maranda

    I wonder why

  364. ludo has joined

  365. Ge0rG

    Maranda: Contact addresses for xmpp.is are https://xmpp.is/contact/ (support, admin, feedback, abuse)

  366. Ge0rG

    please feel free to bother them.

  367. Maranda

    🤣

  368. Dave Cridland has left

  369. Dave Cridland has left

  370. Dave Cridland has left

  371. Ge0rG

    When looking for xmpp.is in my log I found this one instead: https://isopres.de/impressum/

  372. Alex has joined

  373. dwd has left

  374. Dave Cridland has left

  375. mathieui

    Thanks for the newsletter, by the way

  376. Ge0rG

    Yeah, it's awesome!

  377. Ge0rG

    I'd love to have the big ones (like EVE and Epic) mentioned on our twitter as well

  378. Dave Cridland has left

  379. lumi has joined

  380. Dave Cridland has left

  381. Dave Cridland has left

  382. Dave Cridland has left

  383. Dave Cridland has left

  384. Dave Cridland has left

  385. jonasw

    this ID mess is a mess

  386. Martin has joined

  387. jonasw

    Kev, there’s no reasonable way we can actually force clients to generate globally unique IDs though, is there?

  388. jonasw

    so I don’t think that there’s an actual solution to the "appears to be rewriting history" issue.

  389. Kev

    No, I think there's not (I keep saying that, I think) - I wasn't arguing we can solve it, I was arguing that "they've got lots of power anyway" isn't the reason to not care.

  390. Dave Cridland has left

  391. lskdjf has left

  392. jonasw

    oh, I must’ve misunderstood that

  393. jonasw

    how would we be caring then?

  394. Kev

    I felt that "they've got lots of power anyway" was a "we shouldn't care". We should care, we just probably can't avoid it, so we carefully document it in security considerations etc.

  395. Kev

    It sounded like Simon was saying that malicious clients/servers are a problem not worth thinking about. I might have misinterpreted his words.

  396. Dave Cridland has left

  397. lskdjf has left

  398. Dave Cridland has left

  399. @Alacer has joined

  400. Dave Cridland has left

  401. Dave Cridland has left

  402. andy has joined

  403. Dave Cridland has left

  404. SaltyBones

    Yeah, that's not what I was trying to say...

  405. blabla has left

  406. daniel has left

  407. Dave Cridland has left

  408. j.r has joined

  409. had-hoc has joined

  410. SaltyBones

    Hm...how to sum this up...1. A client and server can claim that a message-ID was A when it was B; that is almost unsolvable but the other recipients just won't believe it anyway. 2. There is usually no authentication in XMPP so the point seems a bit moot.

  411. jonasw

    the main issue is that an ID can be re-used

  412. jonasw

    as far as I understand it

  413. Martin has left

  414. jonasw

    and since we use IDs as identifiers in various protocols (LMC, but also References and stuff), that’s a problem

  415. SaltyBones

    Yeah, but there is a difference between assuming that it happens by accident and can be fixed and assuming that it is adversarial.

  416. jonasw

    I’m confused

  417. Dave Cridland has left

  418. Ge0rG

    The only way to properly solve this is to limit the validity domain of IDs to a single session.

  419. Kev

    SaltyBones: "no authentication"?

  420. Martin has joined

  421. Kev

    I think one can reasonably argue with that statement.

  422. jonasw

    Kev, I think they refer to "cryptographic authentication". A server can esaily forge a stanza for anyone to or from his domain.

  423. SaltyBones

    Yeah, sorry.

  424. SaltyBones

    Ge0rG, but then you could force the server to have some sort of UUID and a session counter and if you throw the three things together you get reasonable global IDs.

  425. Kev

    There's cryptographic authentication, even. It's just that it's applied to the domain, not beyond.

  426. goffi

    is there a licence for the Newsletter? Would be nice so it could be translated

  427. Dave Cridland has left

  428. jubalh has left

  429. SaltyBones

    goffi, has been discussed in the comm team channel

  430. Tobias

    isn't all website content on xmpp.org under a single license

  431. andy has left

  432. Kev

    Should be, but I think that notice was lost at some point.

  433. SaltyBones

    Kev, yes, but there is no message authentication so if you only store messages you cannot prove to anybody later that serverA sent you messageB with ID-C...

  434. valo has joined

  435. Kev

    That's somewhat different.

  436. valo has joined

  437. SaltyBones

    Yes, just pointing it out because you of your "somebody claims you liked a post about KKK" example

  438. SaltyBones

    Yes, just pointing it out because of your "somebody claims you liked a post about KKK" example

  439. Dave Cridland has left

  440. jonasw

    SaltyBones, the issue is that that scenario can be caused by a client alone.

  441. SaltyBones

    jonasw, the reason I ended up with this proposal is that it makes the situation better and it is very easy to implement.

  442. jonasw

    a mailicous server is really powerful, indeed, and we generally assume that each user can trust their own server, and that they have to some extent trust a MUC service if they’re using one

  443. Kev

    SaltyBones: I think my issue is that the core of your proposal (the hashing thing) doesn't make anything better :)

  444. Kev

    Or, I don't see how it does.

  445. SaltyBones

    Kev, that's a reasonable way to look at it. You could just as well not do the hashing and just use per-connectionserver-salt + connection-counter

  446. SaltyBones

    That was just a fix for the "oh but the connection counter leaks stuff" problem...

  447. Kev

    Oh, no, you couldn't do counters, because of the leaks.

  448. Kev

    But as telling the server what ID to use for MAM isn't sensible, AFAICS, I don't think the server being able to predict the client ID buys much at all.

  449. SaltyBones

    If the server can assure that the client ID is unique it can simply use that for MAM.

  450. SaltyBones

    That's the main point... :)

  451. jonasw

    SaltyBones, but that only solves the "client knows the eventual ID of the message"

  452. j.r has joined

  453. jonasw

    it doesn’t solve any of the malleability things cross-domain.

  454. jonasw

    that is only solved by your rewriting proposal, and I’m not confident that will work properly

  455. jonasw

    except with a lot of complexity on the server

  456. Dave Cridland has left

  457. SaltyBones

    jonasw, not sure what you mean

  458. SaltyBones

    jonasw, not sure what you mean with malleability cross-domain

  459. Kev

    SaltyBones: You're assuming that a server is happy to have arbitrary client-provided IDs as the primary query into the archive. I'm suggesting I don't think that's valid.

  460. Kev

    I think you have to let the server decide how it indexes its database.

  461. SaltyBones

    Kev, they are not arbitrary at all because the server can verify that the client generated them correctly. Essentially they are just forced to use the same generation algo....

  462. Dave Cridland has left

  463. SaltyBones

    Of course if there are servers that don't like this algorithm for some reason than we should look at what that reason is and how to fix it. :)

  464. jonasw

    SaltyBones, the reason for prosody/Zash is clear: their ID contains the date because that allows quick access to a bucket of MAM data

  465. goffi

    SaltyBones: and what was the conclusion of the discussion? Can we re-use? Tobias: I don't see any licence mention on the wesite, what is it?

  466. Tobias

    I'm sure you can translate it when referencing back and mention the original author

  467. Dave Cridland has left

  468. daniel has left

  469. mimi89999 has joined

  470. SaltyBones

    goffi, translations would be appreciated and then linked to from the main newsletter. Not a real legal discussion.

  471. daniel has left

  472. Dave Cridland has left

  473. daniel has left

  474. Dave Cridland has left

  475. moparisthebest has joined

  476. goffi

    Tobias: SaltyBones: I plan to translate in French to a popular website, but it require to specify licence, so I want to be sure I can set CC By-SA there. And yes I'll mention original post of course.

  477. Ge0rG has left

  478. Tobias

    what's the SA?

  479. goffi

    Share Alike

  480. SaltyBones

    goffi, join commteam@ and ask there.

  481. goffi

    SaltyBones: Tobias: asking there now, thanks

  482. SaltyBones

    jonasw, they could just include a timestamp for timestamp queries and use an increasing salt to have an increasing index...

  483. SaltyBones

    We can probably suss out all of these problems but I am not sure anybody but me is actually interested in doing that. xD

  484. Ge0rG

    > but I am not sure anybody but me is actually interested in doing that. I know that feeling. Too well.

  485. dwd has left

  486. Kev

    I'm glad to have this discussion. I'm not convinced that the proposal, and the complexity that goes with it, is solving any problems that a simpler solution doesn't.

  487. jonasw

    SaltyBones, but timestamps aren’t monotonic

  488. Kev

    That is, it seems to me that the problems solved by this solution are the same solved by just saying to clients 'be unique in origin-id', and updating other XEPs to say 'reply with the origin-id' (LMC, Receipts, etc.).

  489. jonasw

    yeah

  490. Ge0rG

    SaltyBones: sorry, I didn't even read through the message-IDs thread due to lack of time.

  491. SaltyBones

    Kev, and maybe adding a reply "this is your mam-ID" to client messages

  492. SaltyBones

    jonasw, they aren't? :)

  493. Kev

    Or ignoring origin-id, using the stanza ID the way we always have, and killing MUC with fire :)

  494. jonasw

    SaltyBones, clock corrections make it non-monotonic. and of course there’s the issue of clock sync between nodes

  495. Ge0rG

    Kev: or just finally mandating that MUC must keep message IDs.

  496. Kev

    Or that.

  497. Ge0rG

    And mandating that clients which want to employ LMC and other references must use sufficiently unique IDs

  498. SaltyBones

    jonasw, ah I was thinking about the lamport kind of timestamp

  499. jonasw

    that sounds complex

  500. Ge0rG

    Maybe somebody wants to resurrect the Jul 2014 thread on MUC message IDs.

  501. SaltyBones

    a little

  502. SaltyBones

    jonasw, anyway if you have server generated timestamps and a monotonic counter the mapping should be pretty easy although not a NOP :)

  503. Kev

    You need more than monotonic, don't you?

  504. Ge0rG

    SaltyBones: but clustering!

  505. Ge0rG

    no wait, that was Dave's text.

  506. Ge0rG

    but race conditions!1!

  507. SaltyBones

    If you want clustering and query by timestamp I suppose you need the opposite of monotonic.

  508. SaltyBones

    You want to merge archives by timestamp. Although that sounds dubious.

  509. vanitasvitae has left

  510. SaltyBones

    So, let's suppose that servers really want to generate their own ID for internal use. That seems fair but then why does the client need to know this ID for MAM? That's a bit fishy imho...

  511. jere has joined

  512. Kev

    Because it's that ID that is the index into the archive.

  513. Ge0rG

    I wonder if we can do XMPP over that link: http://www.vodafone.com/content/index/media/vodafone-group-releases/2018/vodafone-and-nokia-to-create-first-4g-network-on-moon.html

  514. SaltyBones

    but why does the client need to know that

  515. Kev

    Because it queries the archive.

  516. SaltyBones

    To do what?

  517. SaltyBones

    I mean, there are obvious solution here as well: 1. The client query the server by its own ID and the server can try to use that as an additional index or 2. The server could just reply to client messages with the new ID.

  518. SaltyBones

    But the whole situation is weird...what are the clients trying to achieve by querying the MAM?

  519. Kev

    There is some massive logical disconnect here.

  520. andy has joined

  521. Kev

    You're asking why a user would want to retrieve messages from their message archive.

  522. Kev

    What's the point of having the archive if you *can't* query it?

  523. Dave Cridland has left

  524. SaltyBones

    But why would you need to know what s in the archive to query it

  525. Kev

    Have you read the XEP? :)

  526. SaltyBones

    Well, I ve tried... :)

  527. Kev

    You say things like "Give me everything since message X", where X is the MAM ID.

  528. Dave Cridland has left

  529. Guus has left

  530. Guus has left

  531. SaltyBones

    Yes, but now we are asking the client to query by and ID which the server generated and didn't tell it about...

  532. SaltyBones

    Why not just query by the clients ID or timestamp?

  533. dwd has left

  534. Ge0rG

    timestamps are unreliable

  535. jonasw

    SaltyBones, because it is exact

  536. Kev

    Syncing on timestamp doesn't work, indeed.

  537. jonasw

    timestamps are not exact

  538. Kev

    And the client ID means you're storing the primary index provided by the client, which enforces implementation details on the server that I'm not convinced we want to.

  539. Kev

    And maybe it's something we can live with, but I don't currently see what it buys us.

  540. Maranda has joined

  541. jonasw

    I know at least one implementation which can’t live with that :)

  542. Holger

    The message in question might be an incoming message, an outgoing message sent by that client, or an outgoing message sent by another client. You'd use the client ID in some or all these cases?

  543. Kev

    jonasw: If you mean Prosody's timestamp one, I think additional stuff's going to end up needed there anyway, for all the other things we were discussing at the summit.

  544. Kev

    But yes.

  545. Kev

    Holger: Well, you obviously can't in all, for id clashing reasons. At least, not with this suggested scheme.

  546. Holger

    That's why I'm asking.

  547. Holger

    So basically the client ID is not an option.

  548. Holger

    If you don't want to introduce another great mess.

  549. Alex has left

  550. andy has left

  551. andy has joined

  552. dwd has left

  553. jonasw

    Holger, that’s a very good point, I like it :)

  554. Ge0rG

    another great mess! \o/

  555. Dave Cridland has left

  556. rtq3 has left

  557. rtq3 has joined

  558. andrey.g has joined

  559. marc has joined

  560. andy has left

  561. andrey.g has joined

  562. Neustradamus

    It is beautiful to see the first newsletter after XMPP Roundup and Jabber journal :)

  563. Neustradamus

    I see a new redirection problem: http://wiki.jabber.org/index.php/....

  564. andrey.g has joined

  565. andrey.g has joined

  566. Holger

    I'm confused. Say the client re-logs in after loosing the connection and knows the MAM ID not just of the last incoming but also of the last outgoing message because we solved that somehow. He then queries MAM with after=$ID. How does he decide whether to specify the $ID of the last outgoing or the last incoming message? The ordering of incoming vs. outgoing messages on the client side might be different from the server side, no? (Maybe *this* can only be solved properly by having the server reflect IDs?)

  567. jonasw

    yes, that can be solved by having the server reflect IDs

  568. Ge0rG

    Holger: that's an awesome point

  569. Dave Cridland has left

  570. Ge0rG writes it on the back of his "race conditions" card

  571. jonasw

    hah

  572. jonasw

    that’s why I think we just want self-carbons by now.

  573. Kev

    It's the same point I made on the list earlier this morning.

  574. jonasw

    yeah

  575. Kev

    But with more words ;)

  576. Holger

    Kev: Oh sorry, I didn't catch up yet.

  577. Kev

    The chat in here was triggered by me replying to the mailing list thread, I think.

  578. jonasw

    yeah

  579. Ge0rG

    Kev: except almost nobody read your mail, it seems

  580. SaltyBones

    The ordering or messages in MAM can be different from the client?

  581. Holger

    Can we maybe somehow merge reflection of IDs with 0198 ACKs?

  582. Ge0rG

    SaltyBones: yes

  583. Ge0rG

    Holger: this is something I proposed when MAM first appeared.

  584. Kev

    Holger: I'd rather not, that's somewhat breaking layering.

  585. Ge0rG

    Holger: 0198 and Carbons and MAM in a single unholy union.

  586. dwd has left

  587. SaltyBones

    Why can they be different and who is right? :)

  588. Holger

    Kev: Then the layers are wrong IMO.

  589. Kev

    Really?

  590. Holger

    Kev: I find it a bit embarrassing to define a protocol that has the server generate two responses to a single message.

  591. andrey.g has joined

  592. Kev

    198 is about the network layer and stuff getting through.

  593. Kev

    MAM is about the protocol layer.

  594. jonasw

    Holger, two responses?

  595. Zash

    198 isn't per message

  596. Dave Cridland has left

  597. jonasw

    not even per stanza, indeed

  598. Holger

    jonasw: (1) ACK I got message with ID $count, (2) ACK I got the message with MAM $ID.

  599. andrey.g has joined

  600. jonasw

    Holger, but the (1) ACK is explicitly requested by the client with an <{sm}r/>

  601. Holger

    Yes I'd usually request it per-stanza.

  602. jonasw

    hm, I don’

  603. jonasw

    *I don’t

  604. Kev

    So 198 could be bunching a load of stuff, for different stanzas (which may or may not be messages), and is generally going to happen once the server receives the stanzas, whereas 313 happens later, once it routes goes in the archive.

  605. Holger

    jonasw: If the client doesn't deem this necessary, why does it deem it necessary for MAM?

  606. Holger

    Ge0rG: Yay I'm good at re-inventing wheels.

  607. Ge0rG

    Kev: some servers will only emit the 0198 ack after fully processing the stanza

  608. jonasw

    Holger, because MAM contains things from other entities I suppose

  609. Ge0rG

    yaxim will emit an <r/> after each message because mobile is unreliable

  610. jonasw

    on the XEP-0198 stream, I know the order of the stanzas. In MAM, I don’t unless I get an in-order reflection of my own message.

  611. SaltyBones

    If a client queries the MAM by last ID but the order in the MAM might be different I don't understand how it works. :)

  612. Holger

    Ge0rG: And if it was reliable you wouldn't need 0198. I never got the idea of requesting an ACK only every now and then.

  613. lskdjf has joined

  614. Dave Cridland has left

  615. Holger

    Except for requesting it only once per bunch of stanzas you sent in one go, or so. In which case a single MAM ID response is fine as well.

  616. jonasw

    Holger, when sending a bunch of messages at once, it makes sense to request an ack only after the last message

  617. jonasw

    saves overhead

  618. jonasw

    yeah

  619. dwd has left

  620. jonasw

    (or rather, sending a bunch of stanzas in general)

  621. Holger

    Yes what I don't get is how the requirements differ from those for MAM ID reflections.

  622. andrey.g has joined

  623. jonasw

    Holger, hm, maybe that would work.

  624. jonasw

    still requires some kind of knowledge about the relative ordering of messages you sent vs. messages you received and other resources sent

  625. jonasw

    I don’t think we can get that without something on the stanza layer?

  626. Holger

    Why?

  627. jonasw

    to be able to query correctly

  628. andrey.g has joined

  629. Holger

    The ordering is now defined by the order or stanza IDs you got on your incoming stream.

  630. Holger

    *the order of stanza IDs

  631. jonasw

    how would I know when I send and receive a stanza at the same time and then my connection drops without stream management.

  632. moparisthebest has joined

  633. jonasw

    now I need to query the archive

  634. jonasw

    which of the two IDs do I use to get a complete, dupfree picture?

  635. Holger

    You ditch unacknowledged messages locally and query MAM with after=$ID, where ID is the last ID you got from the server, no?

  636. jonasw

    (I’m currently too hungry to think of a more sophisticated case where using the wrong ID would actually lead to *missed* messages, but there might be some)

  637. jonasw

    okay, I need some food first

  638. jonasw

    food for thought, if you will.

  639. Holger

    I'll try coffee.

  640. Holger

    And I'll read Kev's email :-)

  641. marmistrz has left

  642. dwd has left

  643. andrey.g has joined

  644. Ge0rG has left

  645. andrey.g has joined

  646. andrey.g has joined

  647. andrey.g has joined

  648. Dave Cridland has left

  649. Dave Cridland has left

  650. Guus has left

  651. flow

    MAM IDs in SM acks seems to be worth exploring

  652. andrey.g has joined

  653. andrey.g has joined

  654. dwd has left

  655. Dave Cridland has left

  656. MattJ

    Depends whether you want to communicate to the client "this was the last entry in MAM at this point in the stream", or whether you want the client to know the ID of every message in the archive

  657. Ge0rG

    Holger: except we need SM for IQs as well.

  658. flow

    MattJ, last entry in archive should be sufficient for most cases

  659. Ge0rG

    MattJ: what about giving back a list of message id / message ID pairs.

  660. dwd has left

  661. Holger

    Ge0rG: Those will obviously not carry a MAM ID?

  662. MattJ

    I'm guessing Ge0rG means a map of @id -> MAM-ID

  663. Ge0rG

    I just love our nomenclature

  664. Alex has joined

  665. dwd has left

  666. Dave Cridland has left

  667. MattJ

    What nomenclature?

  668. andrey.g has joined

  669. MattJ

    Nobody can agree on what to call anything :)

  670. Ge0rG

    Can't we just map jabber IDs to nonza IDs and be done?

  671. Holger

    :-)

  672. marmistrz has left

  673. Ge0rG

    This protocol is not for zimpies™

  674. andrey.g has joined

  675. Holger

    While at it, maybe just fix 0198 to return an ID for every stanza and ditch both <r/> and the counting which nobody gets right anyway :-P

  676. Ge0rG

    Holger: but layers!

  677. Dave Cridland has left

  678. Holger

    Ge0rG: The TCP layer is responsible for reliable message delivery.

  679. Ge0rG

    Holger: no, TCP is a byte stream, not a message stream.

  680. Guus has left

  681. MattJ

    I think 198 is fine as-is, and I'm not keen on extending it

  682. MattJ

    But yes, we do need to solve the MAM-ID-for-outgoing-messages problem

  683. Ge0rG

    MattJ: from a smart-server dumb-client point of view, having four different mechanisms to track messages sucks.

  684. Seve/SouL has joined

  685. Holger

    So then we need a separate acknowledgment for MAM.

  686. Ge0rG

    I'm talking of 0184, 0198, 0280 and 0313

  687. jubalh has joined

  688. MattJ

    Typically consensus has been about reflecting outgoing messages (in part, or in full), because this also has other benefits and we do it in Carbons anyway (just not for the originating resource)

  689. Ge0rG

    MattJ: yes.

  690. Ge0rG

    I wonder how that will play out with self-messages.

  691. MattJ

    Heh

  692. Holger

    I understand where you guys are coming from, I just think this adds a bit embarrasement when you show the procotol to a newcomer for the first time.

  693. MattJ

    Holger, and your preferred solution is?

  694. MattJ

    Oh sorry, you already said

  695. Holger

    MattJ: Merging 0198 ACKs with 0313 message reflections.

  696. Ge0rG

    Holger: XMPP is already mocked by HTTP developers. It can't get any worse.

  697. Dave Cridland has left

  698. Dave Cridland has left

  699. daniel has left

  700. SaltyBones has left

  701. Guus has left

  702. Alex has left

  703. Holger

    But I see how just adding a stanza-id attribute and otherwise keeping 0198 as-is has downsides. So yes just adding a 0313 mechanism is probably an easier way forward.

  704. jonasw

    FWIW, I think keeping 198 and MAM IDs separate is sane separation of concerns

  705. MattJ

    For the most case I don't think we should be introducing newcomers to the protocol

  706. Holger

    It's just like other things where the end result is more convoluted than it would be if we addressed all this sync foo in one go.

  707. MattJ

    It's a library problem, and the problem is most libraries just leave you with stanza building

  708. Ge0rG

    with 0313 reflections we probably don't need to <r/> each message any more

  709. Holger

    We need new libraries!

  710. Ge0rG

    We need more libraries!

  711. andrey.g has joined

  712. Ge0rG

    There are only three(?) for python!

  713. Dave Cridland has left

  714. jonasw

    i need to port poezio to aioxmpp, then there’ll be only one *evil laughter*

  715. Ge0rG

    jonasw: python-nbxmpp!

  716. jonasw

    that does barely count as library

  717. andrey.g has joined

  718. Ge0rG

    and sleekxmpp used to be a parent of slixmpp? There is also xmpppy

  719. Holger

    Ge0rG: Well what we really need is new library authors I guess, and at least those will have to be introduced to the protocol. In practice you'll have to understand most of that stuff as a serious client author as well, of course, even if your library is sane.

  720. Ge0rG

    So we have five.

  721. Ge0rG

    Holger: as it happens, the most active libraries are maintained by client devs.

  722. Holger

    See.

  723. Ge0rG

    We have much NIH here.

  724. jonasw

    I wonder why ;-)

  725. Holger

    So I'm not fully convinced that "but libraries!" is a good excuse for adding insanity to the protocol.

  726. jonasw

    I can at least argue that I didn’t NIH, there simply wasn’t anything for python3-asyncio when I started. And I even considered porting sleekxmpp to asyncio, but I thought this to be not reasonably possible.

  727. jonasw

    Holger, as both library and client author, I agree.

  728. jonasw

    but I think keeping SM and MAM separate is sane.

  729. Ge0rG

    jonasw: you are biased.

  730. jonasw

    Ge0rG, why?

  731. Ge0rG

    I also think that keeping SM and MAM separate is good.

  732. dwd has left

  733. Ge0rG

    And I argue in favor of a new type of session, which is MAM-Sub

  734. jonasw

    yeah

  735. jonasw

    that’d be great

  736. Ge0rG

    > Still, I like the idea of MAM subscriptions as a replacement or augmentation for carbons Saying that for three years now.

  737. jonasw

    Ge0rG, implement it pls

  738. jonasw

    although bind2 will probably do pretty much that?

  739. Ge0rG

    jonasw: bind2 is just a mechanism to carry things.

  740. jonasw

    bind2 would have the effect of MAM-Sub though?

  741. Ge0rG

    jonasw: nope

  742. jonasw

    by doing MAM sync and carbon enablement in a single atomic step?

  743. Ge0rG

    Let me make a strawman proposal of MAM-sub: - you initiate a bind2 session, supplying the last-known MAM-ID - the server doesn't deliver offline messages - the server delivers your pending MAM messages - the server auto-enables carbons and mam-reflections to you, starting to deliver everything after the MAM sync as "live"

  744. jonasw

    yeah

  745. Ge0rG

    so MAM-Sub is like Carbons but with mam-reflections

  746. jonasw

    alternatively, the server could just give you the current last MAM ID so that you can do the sync asynchronously

  747. Dave Cridland has left

  748. jonasw

    while already receiving live messages

  749. Ge0rG

    I'm sure I proposed that and a bunch of other nifty optimizations (0198 auto-resume/start in bind2) on the ML some time last year

  750. jonasw

    yo

  751. jonasw

    we just need implementations.

  752. Ge0rG

    jonasw: processing MAM after live will be a pita, but okay.

  753. jonasw

    depends on your client, I guess

  754. jonasw

    I’d be fine with that.

  755. Zash has left

  756. jonasw

    has a considerable latency advantage, especially if you’ve been out for more than just a few hours

  757. Dave Cridland has left

  758. flow

    Ge0rG, do mam-reflections solve the issue Holger described between incoming and outgoing messages?

  759. andrey.g has joined

  760. Ge0rG

    flow: yes.

  761. moparisthebest has joined

  762. Ge0rG

    flow: MAM reflections will be part of your MAM archive, right between incoming messages, properly ordered.

  763. jonasw

    we just need to make sure that MAM-Reflections don’t rewrite IDs. this time for real *scnr*

  764. jonasw

    Ge0rG, what, why?

  765. jonasw

    wouldn’t you just have your outgoing messages in the MAM archive?

  766. flow

    Ge0rG, so mam-reflections are done after the message has been added to your archive, both incoming and outgoing messages

  767. Ge0rG

    flow: yes

  768. Ge0rG

    jonasw: I'm not following

  769. flow

    sounds good

  770. flow

    you should write a XEP

  771. Dave Cridland has left

  772. flow

    or otherwhise the idea will possibly be burried in the standards@ archive

  773. jonasw

    Ge0rG, why would you have the MAM reflection thing (presumably <message from="mam" to="your client"><forwarded><inner message from="your client"/></forwarded><stanza-id…/></message>) in the archive instead of just <inner message/>?

  774. dwd has left

  775. Ge0rG

    jonasw: wait, what?

  776. jonasw

    what is a MAM reflection?

  777. flow

    jonasw, I don't think that is what Ge0rg wanted to say with "will be part of your archive"

  778. Ge0rG

    jonasw: whatever we make it to be

  779. jonasw

    Ge0rG, I am super confused now

  780. Ge0rG

    jonasw: could be a sent carbon of your outgoing message, or the outgoing message wrapped in MAM

  781. jonasw

    yeah

  782. jonasw

    okay

  783. jonasw

    but WHY would you put that wrapped message into MAM again?

  784. Ge0rG

    jonasw: or maybe just a small-ish ack with the MAM ID and your original @id

  785. Ge0rG

    jonasw: I wouldn't

  786. Dave Cridland has left

  787. jonasw

    I don’t understand: 12:14:59 Ge0rG> flow: MAM reflections will be part of your MAM archive, right between incoming messages, properly ordered. this then

  788. Ge0rG

    jonasw: I'd put the original message, obviously

  789. Ge0rG

    jonasw: ignore it please

  790. jonasw

    okay

  791. jonasw

    then I didn’t say a thing since 12:15:01Z

  792. Ge0rG

    jonasw: of course your *sent message* will be part of your MAM archive, plus the MAM-ID

  793. jonasw

    yeah, that’s a good thing :)

  794. Dave Cridland has left

  795. Alex has joined

  796. @Alacer has left

  797. andrey.g has joined

  798. Martin has left

  799. andrey.g has joined

  800. flow

    Ge0rG, once MAMSub is active, clients will only receive messages not stored into mam via the usual way, all other archived messages will be mam-reflected, correct?

  801. Dave Cridland has left

  802. Ge0rG

    flow: wait, what?

  803. Dave Cridland has left

  804. @Alacer has left

  805. Dave Cridland has left

  806. Yagiza has left

  807. flow

    Ge0rG, specific mam-reflections please

  808. SaltyBones

    I find our reasoning so far somewhat questionable. Because servers might want to use different IDs for messages these IDs should be reflected to the client so that it can make queries with that ID. Shouldn't a simply be able to respond to a clients query if the client uses its original ID? Maybe this is not really practically possible anymore now but it seems somehow more logical. :)

  809. Ge0rG

    flow: no, you will receive all messages as usual, with MAM-IDs injected

  810. SaltyBones

    I find our reasoning so far somewhat questionable. Because servers might want to use different IDs for messages these IDs should be reflected to the client so that it can make queries with that ID. Shouldn't a server simply be able to respond to a clients query if the client uses its original ID? Maybe this is not really practically possible anymore now but it seems somehow more logical. :)

  811. Dave Cridland has left

  812. flow

    Ge0rG, and carbons still using forwarded?

  813. Ge0rG

    flow: let me sort this out: you will receive all(*) incoming messages as regular messages, sent carbons from your other clients as sent carbons and MAM reflections of your outgoing messages as whatever works (e.g. forwarded)

  814. Ge0rG

    all(*) = remember what I proposed at the summit / XMPP2 / routing2 brainstorming

  815. Yagiza has joined

  816. Zash has left

  817. Ge0rG

    But maybe routing2 is still too controversial

  818. Zash has joined

  819. dwd has left

  820. flow

    What gives you the impression that it is too controversial?

  821. Ge0rG

    flow: it breaks existing XMPP routing

  822. @Alacer has left

  823. flow

    But it's opt-in. Do we have an example of a legacy protocol which breaks when another involved entity activated routing2?

  824. Ge0rG

    flow: not that I am aware of. But the proble is that it changes semantics of bare/full JID routing, which is guaranteed to leak outside the XMPP2 domain

  825. @Alacer has joined

  826. Dave Cridland has left

  827. flow

    I guess that is just a fancy expression for "something could rely on the semantics and would break if someone else is using routing2"

  828. MattJ

    The root problem is that an XMPP1 entity will happily send to the full JID of an XMPP2 entity and expect it to be treated in the XMPP1 way

  829. Yagiza has left

  830. @Alacer has left

  831. Kev

    Full-JID 'I'm xmpp2' annotation seems like it works though.

  832. @Alacer has joined

  833. Ge0rG

    Kev: maybe, yeah.

  834. Dave Cridland has left

  835. dwd has left

  836. Kev

    Or heuristically 'fixing' xmpp1 full JID based on DPI, but that seems unappealing and probably fragile.

  837. flow

    Kev, DPI?

  838. Kev

    Deep Packet Inspection.

  839. flow

    deep packet inspection?

  840. Kev

    Which I'm abusing as a term to mean 'look inside the payloads'.

  841. Lance has left

  842. Lance has joined

  843. Yagiza has joined

  844. blabla has left

  845. MattJ

    The problem with the annotation is that it feels like it's undermining the point of routing2 in the first place

  846. MattJ

    If we're going to annotate, let's just annotate and we don't need to make any other changes

  847. MattJ

    and that's basically hints, but with a stronger definition of how to process them

  848. Alex has left

  849. Kev

    MattJ: Maybe, perhaps.

  850. Kev

    What else would you annotate, though?

  851. MattJ

    Exactly - nothing

  852. MattJ

    So XMPP2 is XMPP1 with annotations on stuff you want to treat as ephemeral

  853. Kev

    And changed routing rules for anything that's not annotated?

  854. Kev

    And clients need to know to ignore anything in an annotated message, because it shouldn't be getting them.

  855. Kev

    I don't know, I'm kinda concerned that people are going to go down the "Oh, let's annotated such-and-such special casing" like we have with no-copy and no-store at the moment.

  856. Dave Cridland has left

  857. MattJ

    Indeed

  858. Kev

    In principle, it's technically equivalent.

  859. Kev

    I still feel we might want to start sending messages from the bare JID instead of the full JID.

  860. MattJ

    from or to?

  861. Kev

    From.

  862. MattJ

    I hadn't considered changing from

  863. Kev

    You certainly want to be sending to the bare JID.

  864. jubalh has left

  865. Kev

    Although if we're saying "treat all messages to a full JID as to a bare JID unless they have an ephemeral annotation", that may be reduced, I guess.

  866. bear has left

  867. Maranda

    Hmm conversations lost the message I sent here this morning from the backlog hm hm

  868. Kev

    I need to find time to write some specific words here, so we can bash them, I think.

  869. Ge0rG

    https://marc.info/?l=openbsd-misc&m=151974573718360&w=2 - Alright, I'm not complaining about XMPP protocol design any more

  870. Dave Cridland has left

  871. dwd has left

  872. jonasw

    Ge0rG, lol

  873. jubalh has joined

  874. dwd has left

  875. Guus has left

  876. Ge0rG

    Yup. OpenSSL. Still written by monkeys.

  877. tim@boese-ban.de has left

  878. Dave Cridland has left

  879. Alex has joined

  880. daniel has left

  881. @Alacer has left

  882. Guus has left

  883. dwd has left

  884. Dave Cridland has left

  885. moparisthebest has joined

  886. moparisthebest

    Random question without much thought, why can't the one true message id be implicit as the hash of the whole stanza?

  887. SaltyBones

    It's hard to define what should go into the hash and then some "things" change those things anyway so the ID would change...

  888. moparisthebest

    But isn't just hash the entire thing good enough?

  889. Guus has left

  890. Dave Cridland has left

  891. SaltyBones

    moparisthebest, yesterday I would have said yes but now it is clear that people don't just want unique IDs they want very specific IDs and pick them themselves.

  892. Guus has left

  893. moparisthebest

    They can still do that

  894. SaltyBones

    moparisthebest, just read the backlog from today :)

  895. moparisthebest

    The public one is the hash, they can use whatever as the private one

  896. moparisthebest

    Encoding implementation decisions into the protocol seems wrong

  897. tim@boese-ban.de has left

  898. moparisthebest

    Especially when it has loads of downsides

  899. MattJ

    moparisthebest, hashing XML is problematic, and in any case the same stanza may change en-route

  900. @Alacer has joined

  901. MattJ

    Unless you're saying it's just hashed after the first hop

  902. Martin has joined

  903. goffi

    I was thinking about hash too, but the issue with hash is that you have to find one without collision. If you change, you'll break all existing ecosystem.

  904. SaltyBones

    moparisthebest, the problem is that we leak the private one because it is required for MAM queries.

  905. SaltyBones

    see my 13:25 comment :)

  906. Guus has left

  907. Dave Cridland has left

  908. Kev

    moparisthebest: Stanzas might change at every hop. So you can't just hash the whole thing.

  909. Ge0rG

    moparisthebest [14:11]: > Encoding implementation decisions into the protocol seems wrong Hashing parts of a message into its id is just that

  910. Kev

    goffi: Hashes changing is a solved problem, at least, you just specify the hash used.

  911. Martin has left

  912. Ge0rG

    We could just replace messages with their cryptographic ids and become the next peer to peer distributed content storage network

  913. goffi

    Kev: yes, but what for already emitted IDs ?

  914. Kev

    goffi: They don't have an embedded scheme.

  915. Dave Cridland has left

  916. dwd has left

  917. Guus has left

  918. Guus has left

  919. Dave Cridland has left

  920. moparisthebest has left

  921. moparisthebest

    Ge0rG, I'm not saying hashing parts, that gets complicated, I'm saying hash the entire thing

  922. moparisthebest

    as to changing at server hops, doesn't the id only matter between client and their server?

  923. la|r|ma has joined

  924. la|r|ma has joined

  925. moparisthebest

    so my client sends a message which I know has id AAAA because that's the hash

  926. Dave Cridland has left

  927. moparisthebest

    my server can change it, if it does, it sends me back a message telling me AAAA is now BBBB

  928. moparisthebest

    does that not solve everything?

  929. Kev

    No the idea matters between endpoint entities.

  930. Kev

    No the id matters between endpoint entities.

  931. moparisthebest

    if any server can change the message, the id can only matter between a client and their server?

  932. Kev

    No, the id matters end to end.

  933. Kev

    But the content of a stanza might be changed at any hop.

  934. Kev

    So hashing to generate an id doesn't work.

  935. rion has left

  936. moparisthebest

    so now you might have an id that is the same and different contents?

  937. moparisthebest

    what's the point exactly?

  938. Kev

    See <delay/> for an obvious application.

  939. moparisthebest

    what's the point in a@a.com having the same id as b@b.com ?

  940. moparisthebest

    surely it only matters between a@a.com and a.com, and b@b.com and b.com ?

  941. Dave Cridland has left

  942. jere has left

  943. jere has joined

  944. @Alacer has left

  945. Kev

    Because otherwise you can't reply to previous messages, which you obviously need to be able to do.

  946. moparisthebest

    wait where is this concept of replying to a specific message?

  947. moparisthebest

    as far as I'm aware, there is just a guaranteed order and that's it

  948. Kev

    In assorted XEPs.

  949. Kev

    LMC, Receipts, ...

  950. Dave Cridland has left

  951. Ge0rG

    You'd have to track the message id associations for all eternity.

  952. moparisthebest

    it sounds flawed at a basic level, in a federated system, where a message can change at any server hop, how can you expect an id to refer to remotely the same thing on opposite servers?

  953. moparisthebest

    but really hashing would still work right? the server knows the incoming hash and the outgoing hash

  954. moparisthebest

    when it gets a read receipt etc etc, it just reverse maps it on the way out?

  955. SaltyBones

    Ge0rG, you need to track that anyway because read receipts, right?

  956. SaltyBones

    I mean the client has to do it not the server but still..

  957. Ge0rG

    SaltyBones: the client won't know the effective id between server a and server b

  958. moparisthebest

    and doesn't need to Ge0rG ?

  959. Ge0rG

    moparisthebest: yes, you need to reverse map, for the lifetime of the message. Which might be months.

  960. moparisthebest

    a@a.com can't talk directly to b.com

  961. moparisthebest

    sure

  962. Holger

    moparisthebest: Message contents aren't unique so you can't use a hash as an ID.

  963. daniel has left

  964. jonasw

    inb4 nonce

  965. moparisthebest

    Holger, I don't understand what you mean, I mean hash an entire stanza for an id

  966. jonasw

    moparisthebest, you can’t reasonably expect a re-writing server to map between IDs for all eternity, *plus* to know all protocols where message IDs may be referenced

  967. moparisthebest

    if you rewrite, you map, easy

  968. moparisthebest

    shouldn't need to know any specific protocols?

  969. Holger

    moparisthebest: Entire stanza contents aren't unique either.

  970. @Alacer has joined

  971. jonasw

    moparisthebest, a server would have to re-write a clients reference to another ID, e.g. for XEP-0184 (reciepts) or Last MEssage Correction.

  972. moparisthebest

    Holger, I don't understand, if 2 stanzas hash to the same id they are the same stanza

  973. Holger

    moparisthebest: But they are still two stanzas.

  974. jonasw

    moparisthebest, but maybe sent at a different time.

  975. moparisthebest

    no they are just 1 stanza

  976. jonasw

    like "that’s a good idea", I send that maybe ten times a week in here

  977. jonasw

    a stanza is always its context

  978. Holger

    moparisthebest: Hah what?!

  979. jonasw

    (aaand here we are at matrix’ DAG thing)

  980. Maranda

    Do I have to mention what kind of hard fail hashes are? Does DKIM ring a bell?

  981. moparisthebest

    storage-wise you store them once etc?

  982. jonasw

    Maranda, yeah, good point

  983. jonasw

    oh my god

  984. Holger

    moparisthebest: "etc" :-)

  985. Holger

    moparisthebest: What jonasw said.

  986. moparisthebest

    ah you are saying if you send the exact same stanza every day or something, got it

  987. Dave Cridland has left

  988. rtq3 has left

  989. moparisthebest

    but maybe the rest would work? if id's are only valid per-hop

  990. moparisthebest

    and anything rewriting the id keeps a map for as long as needed?

  991. jonasw

    moparisthebest, how long is "as needed"?

  992. jonasw

    eternity?

  993. moparisthebest

    well for a server it'd be as long as it had the message

  994. jonasw

    especially with non-IM use cases I can imagine "as long as needed" can be quite a while

  995. Holger

    moparisthebest: So you're hashing contents and keeping a map because the contents of a given stanza may change and ignoring the fact that different stanzas might have identical stanzas. But apart from that hashing contents sounds like a perfect solution yes.

  996. moparisthebest

    in mam/smacks/offline storage

  997. jonasw

    moparisthebest, what about references to that message?

  998. Holger

    *identical contents

  999. moparisthebest

    Holger, no I've scrapped hashing :P

  1000. Holger

    Ah.

  1001. moparisthebest

    jonasw, surely those are only good while there is something to reference?

  1002. intosi has joined

  1003. Zash has left

  1004. jonasw

    moparisthebest, another server might have a MAM for longer than you do

  1005. Maranda

    moparisthebest, good boy that's for the best 🤗

  1006. Maranda

    (scrapping hashes)

  1007. moparisthebest

    Maranda, to be fair that was my first question (if you want to uniquely identify a message why wouldn't hashing work?)

  1008. moparisthebest

    to which the answer was, we need to uniquely identify a message as well as it's position in the stream

  1009. Kev

    There were many answers, and I think that's one of the few things that wasn't an answer.

  1010. moparisthebest

    jonasw, in which case it has a map?

  1011. Maranda

    I guess that was plentily answered already by multiple sources about the "why"

  1012. moparisthebest

    the answers I saw about hashing were 'well you have to decide what to hash' which is different

  1013. Maranda

    Beside that attempting to reinvent "a DKIM version" for stanzas/xmpp is a horrifying thought 😘

  1014. jonasw

    Maranda, but SPIM!!kk

  1015. moparisthebest

    dkim is an entirely different solution for an entirely different problem

  1016. moparisthebest

    that xmpp already has solved from day 1

  1017. moparisthebest

    (that problem is, is server X allowed to send messages for domain Y)

  1018. Ge0rG

    Can't we just store the message content on the blockchain and only exchange message IDs?

  1019. moparisthebest

    so what's the problem with a simple solution like, client sets id, if any server changes it it keeps a map, the end?

  1020. rion has joined

  1021. moparisthebest

    servers don't *have* to change it, but if they do, they keep a map

  1022. Dave Cridland has left

  1023. Maranda

    moparisthebest, sorry to contradict but that's not what DKIM ultimately *does*, not that it's important though.

  1024. moparisthebest

    that's the goal isn't it Maranda ?

  1025. dwd has left

  1026. Maranda

    Nope DKIM is more about message authentication, contraffaction and tampering prevention.

  1027. moparisthebest

    I think it has that side-effect because of the hashing, but the goal was server-that-sent-this-was-authorized-by-domain

  1028. Maranda

    You're confusing with SPF me thinks.. And both are failing that's why they had to invent a third, DMARC that somehow fails too.

  1029. moparisthebest

    and there are 2 methods, SPF doesn't hash but is only useable at first hop, and DKIM hashes and is therefore useable through multiple hops (as long as no servers change the hashed part :))

  1030. Holger

    > DKIM provides a method for validating a domain name identity that is associated with a message through cryptographic authentication. http://dkim.org/

  1031. moparisthebest

    DMARC is not a 3rd, it's just enforcing/reporting on SPF and DKIM ?

  1032. Alex has left

  1033. moparisthebest

    still unsure why we are discussing this, XMPP already guarantees the sending server is authorized by the domain

  1034. Holger

    Someone mentioned DKIM out of the blue, someone else responded :-)

  1035. Holger

    I'd like to get back to FTP again!

  1036. Maranda

    DMARC, nope not just reporting, and I'd avoid reading just introductions. Saves headache laters.

  1037. intosi has left

  1038. moparisthebest

    I said it was enforcing and reporting

  1039. moparisthebest

    and that's all it is?

  1040. Maranda

    You did? Oh you did I'm blind apologies blame the cold exposure 😆

  1041. moparisthebest

    that's fully understandable, unfortunately :)

  1042. Maranda

    That was a grotesque example to explain how inadeguate I think hashes are in stanzas context, no big deal anyways. Brb.

  1043. Kev

    Holger: Servers change IDs per-hop based on a hash of the contents, store the mapping between IDs, entities fetch the mapping over FTP and do the lookups there. Address of the FTP server is stored in a blockchain.

  1044. Kev

    You're welcome.

  1045. moparisthebest

    I feel like you're missing an opportunity to use GOPHER in there someplace

  1046. Holger

    Kev: Perfect!

  1047. Dave Cridland

    Can we guarantee forward secrecy of ids?

  1048. Kev

    Yes, but not perfectly.

  1049. Dave Cridland has left

  1050. Dave Cridland

    Also, no need to use a hash. We could base64 the entire stanza into the id attribute.

  1051. Dave Cridland

    No collisions, and no need for hash agility then.

  1052. jonasw

    Dave Cridland, ELOOP

  1053. Holger

    We base64 the stanza including the original id attribute and then replace it with the result?

  1054. Dave Cridland

    Without the id attribute, obviously. It'll solve the c14n problem.

  1055. Kev

    Holger: No, you base64 it including the *new* id.

  1056. Holger

    Ah. Now it makes sense to me.

  1057. Kev

    Else the stanza's changing and you'd need a new id.

  1058. Dave Cridland

    Kev, I don't know why you're being silly. My suggestion was practical, and just as sensible as all the others.

  1059. jonasw

    Dave Cridland, it’s possible to do

  1060. Kev

    One of those two statements is true.

  1061. jonasw

    since there’s no length field, you can put the resul… nevermind

  1062. jonasw

    oh my god

  1063. jonasw

    I really should get to sleep

  1064. MattJ

    I just switched to this tab, I can't tell what's a joke and what's not any more

  1065. jonasw

    MattJ, assume everything is

  1066. Kev

    MattJ: That's the joke.

  1067. Tobias

    and don't forget, today is opposite day :)

  1068. Zash has joined

  1069. Dave Cridland

    Tobias, OR IS IT!!?!??!!

  1070. Dave Cridland has left

  1071. jubalh has left

  1072. andy has joined

  1073. blabla has left

  1074. Dave Cridland has left

  1075. Yagiza has left

  1076. Yagiza has joined

  1077. Dave Cridland has left

  1078. Dave Cridland has left

  1079. Dave Cridland has left

  1080. Dave Cridland has left

  1081. vanitasvitae has left

  1082. j.r has joined

  1083. j.r has joined

  1084. andy has left

  1085. Alex has joined

  1086. vanitasvitae has left

  1087. Dave Cridland has left

  1088. jjrh has left

  1089. SaltyBones

    So, to bring it back a bit. It seems this view is currently popular: The server needs to pick his own IDs, the client needs to use these IDs for MAM queries and we will add reflection so that using reflection and carbons a client gets copies of all its messages to have those IDs.

  1090. la|r|ma has left

  1091. moparisthebest

    why is it more important for the server to pick it's own IDs than the client?

  1092. Kev

    Concrete proposal: Set origin-ID uniquely on the client, add another id any time something archives it and wants it available, reflect that id back to the first client on first hop. Set the stanza id to the same as the origin-id, but generally ignore it and use the origin-id where available in things like LMC.

  1093. SaltyBones

    I don't think it is an issue of what is more important it's just that the server writers want to do that. I am not one so I cannot tell you why. :)

  1094. Dave Cridland has left

  1095. moparisthebest

    so I propose they can do whatever they want, they just need to keep a map?

  1096. Ge0rG

    moparisthebest: keeeping a map is a hard task.

  1097. Ge0rG

    moparisthebest: also actually replacing all references according to the map, because you don't know what's a reference and what's just random data.

  1098. moparisthebest

    I'm pretty sure it's one of the simplest tasks in computer science

  1099. SaltyBones

    Ge0rG, true but now we need the client to keep the map or to change the ID of old messages or something...it also seems hard :)

  1100. moparisthebest

    it's not naming, cache invalidation, or off-by-one errors :P

  1101. Kev

    No, it's two of those things in one :)

  1102. Ge0rG

    moparisthebest: actually it is a part of cache invalidation.

  1103. Zash

    Off by one naming of invalid caches

  1104. SaltyBones

    But the point stands, doesn't the work still have to be done but now it must be done by the client?

  1105. Kev

    No.

  1106. SaltyBones

    It needs the origin-ID for references and the stanza-ID for MAM queries....

  1107. Kev

    It doesn't need any mapping.

  1108. moparisthebest

    I thought the point was to hose all those and go to 1 id ?

  1109. Ge0rG

    and the message ID in case the origin-ID gets stripped

  1110. Kev

    Ge0rG: I suggest (and it's a novel suggestion, because I know no-one's suggested it before) setting the id to the same as the origin id.

  1111. Ge0rG

    Kev: you'll never get the author convinced to do that

  1112. moparisthebest has joined

  1113. moparisthebest has left

  1114. SaltyBones

    Kev, I'm not sure I agree that keeping two IDs for messages is very different from a mapping... :)

  1115. Ge0rG

    SaltyBones: the client needs to keep an index on the origin-ID, but probably not on the MAM ID

  1116. Ge0rG

    I need to look up messages by origin-ID for LMC and ACKs, but not when fetching an archive

  1117. SaltyBones

    Don't you have to merge the local and MAM archive somehow?

  1118. moparisthebest

    in fact I think keeping 2 id's and an index on one is the very definition of a map

  1119. jonasw

    Dave Cridland, I sent you an email with https://github.com/xsf/xeps/pull/593 for the council agenda :/

  1120. Ge0rG

    moparisthebest: the difference is that on the client, you store that as part of the message DB, and you can clean it up together with the messages

  1121. Dave Cridland has left

  1122. Dave Cridland has left

  1123. dwd has left

  1124. Kev

    SaltyBones: These are logically two different things. You need (temporarily) a way of correlating messages and their replies ,which is origin-id. For MAM sync you only need a single ID, which is the latest thing to go in the archive that you've seen (and, depending on your model, even that is optional).

  1125. Kev

    I don't see a situation in which you ever need to map between the two.

  1126. jubalh has joined

  1127. moparisthebest

    so what if the client sets an id, and if the server wants to change it, it just sends that info back to the client and doesn't keep a map?

  1128. moparisthebest

    what's the downside of a single id ?

  1129. Ge0rG

    moparisthebest: it won't work.

  1130. moparisthebest

    why not?

  1131. Ge0rG

    I'm sure this has been outlined in here multiple times today

  1132. moparisthebest

    client sends id=A, server sends back A is now B, client changes id=A to id=B, done?

  1133. Ge0rG

    moparisthebest: what if the client disconnects after sending A?

  1134. moparisthebest

    smacks/mam handles all that

  1135. Ge0rG

    moparisthebest: except when you don't know that A is B now and the smacks session expires

  1136. moparisthebest

    B still gets it with mam though

  1137. moparisthebest

    and C who knows nothing about id=A just ignores it

  1138. SaltyBones

    Kev, it seemed to be annoying for client devs to handle the different kinds of IDs and merge them and use the appropriate one everywhere but maybe I just misunderstood...

  1139. moparisthebest

    it seems to be annoying for both client and server devs

  1140. Kev

    SaltyBones: I don't think it's a significant problem, just that sometimes people aren't sure which id to use.

  1141. Kev

    (Because everything that talks about the id was written back when there was only the stanza id, and so didn't need to be explicit which one)

  1142. Ge0rG

    e) none of the above.

  1143. moparisthebest

    which turns out to be the significant problem

  1144. SaltyBones

    Yeah, maybe. From this far away I really can't tell how I would handle syncing local history with mam :)

  1145. MattJ

    There is only one id that MAM is concerned about, ignore everything else

  1146. SaltyBones

    Sure, so clients will store everything with origin-ID first, then add the stanza-ID when they receive the reflection and then just merge in other messages from MAM based on that, right?

  1147. dwd has left

  1148. andy has joined

  1149. moparisthebest

    I mean when everything gets this wrong you can pretend it's not a problem, just like everyone did for years with XHTML-IM, that doesn't make it not-a-problem though

  1150. MattJ

    SaltyBones, personally I don't really understand why origin-id exists

  1151. moparisthebest

    and to be clear I don't mean in the future things might get this wrong, I mean essentially any newly written thing gets this wrong now

  1152. Ge0rG

    MattJ: because of MUC reflections.

  1153. SaltyBones

    MattJ, I think most people agree that it is superfluous and should be the same as message-ID.

  1154. MattJ

    Ge0rG, and I think servers breaking MUC reflections are broken

  1155. Ge0rG

    and because back in 2014, somebody refused to mandate that MUCs shall retain the ID on reflection.

  1156. MattJ

    so lets do that now, because 99% of servers get this right

  1157. Ge0rG

    MattJ: OK. I'll revive the thread.

  1158. MattJ

    and stop making this id discussion so much more confusing

  1159. rion has left

  1160. MattJ

    As I recall the most vocal opponent to mandating id preservation since changed their mind

  1161. Ge0rG

    Okay, the other reason was that on origin-id you can assume client-enforced uniqueness, which you can't on @id

  1162. SaltyBones

    what?

  1163. MattJ

    So then we're back to stanza-id for tracking between you and your server, and @id for end-to-end tracking

  1164. SaltyBones

    why would a client be able to generate unique origin-ID but not unique message-ID?

  1165. Ge0rG

    SaltyBones: a client isn't *guaranteed* to generate a unique @id

  1166. MattJ

    Who cares?

  1167. Ge0rG

    I don't know.

  1168. Ge0rG

    maybe people doing references.

  1169. MattJ

    The only entity concerned with the uniqueness of @id are clients that generate them

  1170. Zash

    Reference them*

  1171. SaltyBones

    But if it *can* generate a unique origin-ID it can generate a unique message-ID, yes? :)

  1172. Ge0rG

    MattJ: clients that process incoming @id's too, for references and ACKs

  1173. MattJ

    so if you're doing receipts/LMC/etc. then just be sure you generate sensible ids

  1174. SaltyBones

    But if it *can* generate a unique origin-ID it can generate a unique message-ID, can't it? :)

  1175. jjrh has left

  1176. Ge0rG

    SaltyBones: yes. But with @id you don't know from the outside, with origin-id you do

  1177. jjrh has left

  1178. SaltyBones

    Ge0rG, you mean it's not mandated in the spec?

  1179. Ge0rG

    SaltyBones: no. @id is optional

  1180. MattJ

    SaltyBones, that's the whole root of this discussion

  1181. Ge0rG

    SaltyBones: you could send all your messages with id="badgerbadger"

  1182. SaltyBones

    MattJ, maybe, I'm haven't been around long enough to have seen the root of this discussion. ;)

  1183. Ge0rG

    SaltyBones: https://mail.jabber.org/pipermail/standards/2014-July/028988.html

  1184. jjrh has left

  1185. MattJ

    @id is optional and controlled entirely by the sending client, nobody except that client can use it for anything. If you generate an error reply, you reflect the id attribute, that's all

  1186. SaltyBones

    Ge0rG, ...I can't even imagine that "it seemed like a good idea at the time"

  1187. Ge0rG

    SaltyBones: MUC is full of such ideas.

  1188. MattJ

    Second problem is that some MUC server(s?) did not preserve the id attribute in MUC rooms, which broke some clients when they received their own messages back with a different id attribute

  1189. flow

    > Ge0rG> SaltyBones: you could send all your messages with id="badgerbadger"

  1190. flow

    I don't think this is true

  1191. flow

    at least for messages part of the same session

  1192. Ge0rG

    flow: > It is up to the originating entity whether the value of the 'id' attribute is unique only within its current stream or unique globally.

  1193. Ge0rG

    flow: now I could join this MUC with a multi-session nick, reset my session after each MUC message and you'd end up full of badgers.

  1194. Ge0rG

    or do the same to you via type=chat.

  1195. flow

    Right, but not within the same session/stream. I just wanted to clarify that

  1196. Ge0rG

    @id is an end-to-end property, so binding it to the session lifetime doesn't make any sense.

  1197. Ge0rG

    flow: technically you are correct.

  1198. flow

    just a matter of the definiton of end"

  1199. Ge0rG

    Winter's coming!

  1200. intosi has joined

  1201. Zash

    Nah, noh it ends

  1202. SaltyBones

    So, to sum up: Add reflection of messages to make it easier to figure out how to query MAM otherwise everything has to be the way it is...?

  1203. SaltyBones

    Maybe document better what every kind of ID is used for to make it easier for devs?

  1204. tim@boese-ban.de has left

  1205. daniel has left

  1206. MattJ

    As far as I'm concerned there is one id set by the client and one id set by the server

  1207. flow

    <origin-id/> was invented mostly a workaround for the MUC reflection issue

  1208. SaltyBones

    MattJ, ...and the client set one is origin-ID the server set one is stanza-ID.

  1209. MattJ

    I strongly feel that origin-id should go

  1210. MattJ

    and that any broken MUC services should be fixed

  1211. Ge0rG

    flow: except it doesn't actually solve it, as seen with biboumi.

  1212. SaltyBones

    Okay, so move origin-ID to message-ID and forbid rewriting.

  1213. flow

    Ge0rG, m0ar pls

  1214. Ge0rG

    I'll bring it up on council.

  1215. MattJ

    flow, summary is that transports can't always preserve it

  1216. flow

    SaltyBones, why move? just use rfc6120 IDs like before

  1217. daniel has left

  1218. SaltyBones

    I mean conceptually, move the responsibility...

  1219. MattJ

    which puts them in the "broken MUC server" category as far as I'm concerned

  1220. Kev

    FWIW, transports don't have to be written in such a way as they lose them.

  1221. SaltyBones

    Kev, what?

  1222. SaltyBones

    Kev, what? parse_error

  1223. xnyhps has joined

  1224. daniel has left

  1225. Steve Kille has left

  1226. Guus has left

  1227. intosi has left

  1228. Kev

    The ids

  1229. Steve Kille has left

  1230. rtq3 has joined

  1231. andy has left

  1232. andy has joined

  1233. daniel has left

  1234. Lance has left

  1235. lskdjf has joined

  1236. jjrh has left

  1237. jjrh has left

  1238. lskdjf has joined

  1239. j.r has joined

  1240. jjrh has left

  1241. jjrh has left

  1242. daniel has left

  1243. jjrh has left

  1244. daniel has left

  1245. jjrh has left

  1246. Lance has joined

  1247. Maranda

    Biboumi... 🤔

  1248. mimi89999 has left

  1249. Lance has left

  1250. Lance has joined

  1251. lovetox has joined

  1252. tux has left

  1253. jubalh has left

  1254. Tobias has joined

  1255. mimi89999 has left

  1256. mimi89999 has left

  1257. mimi89999 has joined

  1258. daniel has left

  1259. peter has joined

  1260. andy has left

  1261. andy has joined

  1262. marmistrz has left

  1263. SaltyBones has left

  1264. daniel has left

  1265. Guus has left

  1266. ralphm has left

  1267. daniel has left

  1268. Tobias has joined

  1269. daniel has left

  1270. daniel has left

  1271. Guus has left

  1272. rtq3 has left

  1273. rtq3 has joined

  1274. ralphm has joined

  1275. Guus has left

  1276. daniel has left

  1277. marmistrz has left

  1278. Yagiza has left

  1279. Yagiza has joined

  1280. daniel has left

  1281. la|r|ma has left

  1282. Lance has left

  1283. lskdjf has joined

  1284. Lance has joined

  1285. jubalh has joined

  1286. nyco has left

  1287. Lance has left

  1288. rtq3 has left

  1289. Lance has joined

  1290. suzyo has joined

  1291. Maranda has joined

  1292. daniel has left

  1293. rtq3 has joined

  1294. waqas has joined

  1295. ralphm has joined

  1296. suzyo has joined

  1297. tux has left

  1298. moparisthebest has joined

  1299. moparisthebest has joined

  1300. Steve Kille has left

  1301. moparisthebest has left

  1302. jubalh has left

  1303. Steve Kille has left

  1304. waqas has left

  1305. waqas has joined

  1306. waqas has left

  1307. waqas has joined

  1308. Dave Cridland has left

  1309. Dave Cridland has left

  1310. daniel has left

  1311. Ge0rG has left

  1312. daniel has left

  1313. lskdjf has joined

  1314. Guus has left

  1315. daniel has left

  1316. Ge0rG has left

  1317. rtq3 has left

  1318. rtq3 has joined

  1319. xnyhps has left

  1320. xnyhps has joined

  1321. marmistrz has left

  1322. marmistrz has left

  1323. waqas has left

  1324. Guus has left

  1325. Guus has left

  1326. Steve Kille has joined

  1327. marmistrz has left

  1328. lskdjf has left

  1329. ralphm has left

  1330. Yagiza has left

  1331. Guus has left

  1332. Kev has left

  1333. Guus has left

  1334. daniel has left

  1335. Kev has joined

  1336. rtq3 has left

  1337. rtq3 has joined

  1338. SamWhited has left

  1339. Guus has left

  1340. Guus has left

  1341. Steve Kille has left

  1342. lskdjf has joined

  1343. rtq3 has left

  1344. rtq3 has joined

  1345. Alex has left

  1346. Alex has joined

  1347. lskdjf has left

  1348. lskdjf has left

  1349. tux has joined

  1350. tux has joined

  1351. intosi has joined

  1352. efrit has joined

  1353. daniel has left

  1354. ralphm has joined

  1355. rtq3 has left

  1356. rtq3 has joined

  1357. marmistrz has left

  1358. lskdjf has left

  1359. intosi has left

  1360. Guus has left

  1361. intosi has joined

  1362. goffi has left

  1363. ralphm has joined

  1364. ralphm has left

  1365. waqas has joined

  1366. waqas has left

  1367. ralphm has joined

  1368. SaltyBones

    Kev, ah, you're saying that transports can always be written in such a way that they do not lose IDs?

  1369. moparisthebest

    not if it's impossible to keep a map of IDs >:)

  1370. Alex has left

  1371. andy has left

  1372. Alex has joined

  1373. Lance has left

  1374. Kev

    SaltyBones: At the cost of complexity.

  1375. SaltyBones

    Sure, sure

  1376. SaltyBones

    Yeah forbidding ID mangling seems like it would be a very same thing to do

  1377. SaltyBones

    Should standza-IDs be transmitted btw? Or is that between client and server only?

  1378. SaltyBones

    s/same/sane

  1379. rtq3 has left

  1380. Zash has left

  1381. nyco has left

  1382. marmistrz has left

  1383. Lance has joined

  1384. Maranda has joined

  1385. SaltyBones has left

  1386. daniel has left

  1387. Guus has left

  1388. daniel has left

  1389. rtq3 has joined

  1390. intosi has left

  1391. jubalh has joined

  1392. andy has joined

  1393. ralphm has joined

  1394. MattJ

    SaltyBones, the latter. It's stamped on incoming stanzas (to the user) by the server, to let the client know what id the server has assigned it (e.g. in the MAM archive)

  1395. MattJ

    and in some version of the future, it will also be stamped on reflected outgoing messages

  1396. Zash has left

  1397. andy has left

  1398. andy has joined

  1399. remko has left

  1400. Zash has joined

  1401. Lance has left

  1402. Lance has joined

  1403. andy has left

  1404. andy has joined

  1405. jubalh has left

  1406. moparisthebest has joined

  1407. Lance has left

  1408. waqas has joined

  1409. Nekit has left

  1410. lskdjf has left

  1411. SaltyBones

    And are stanza-IDs used anywhere else? They seem to be presented as this kind of general concept that can be used to add stable IDs for some sort of domain...

  1412. Kev

    They started off as just a part of MAM. They were extracted out (probably wrongly).

  1413. Kev

    Well, no, not quite wrongly.

  1414. Kev

    Because they're used beyond MAM, they're also going to be used for Unread sync, and injected into Carbons and stuff.

  1415. MattJ

    SaltyBones, originally MAM used to stamp <archived by="archive-jid" id="unique-id-for-mam-queries" />

  1416. ludo has joined

  1417. MattJ

    But the general feeling was that this unique id shouldn't be MAM-specific, but reusable

  1418. Zash has left

  1419. Zash has joined

  1420. SaltyBones

    Yeah, I'm just wondering if it has actually ever been used for anything and if tha anything is also between client and server or not.

  1421. Dave Cridland has left

  1422. Kev

    Yes, only between client and server (or client and client)

  1423. Kev

    Unread sync is the obvious one that it's needed.

  1424. marc has left

  1425. dwd has left

  1426. lskdjf has left

  1427. Alex has left

  1428. dwd has left

  1429. ralphm has joined

  1430. andy has left

  1431. Zash has left

  1432. Alex has joined

  1433. marmistrz has left

  1434. jubalh has joined

  1435. andy has joined

  1436. lskdjf has left

  1437. Neustradamus has left

  1438. Neustradamus has joined

  1439. la|r|ma has left

  1440. ludo has joined

  1441. rtq3 has left

  1442. jubalh has left

  1443. peter has left

  1444. Guus has left

  1445. Neustradamus has left

  1446. Neustradamus has joined

  1447. jubalh has left

  1448. daniel has left

  1449. Guus has left

  1450. Neustradamus has left

  1451. Neustradamus has joined

  1452. Guus has left

  1453. rtq3 has joined

  1454. jere has left

  1455. jere has joined

  1456. Neustradamus has left

  1457. Neustradamus has joined

  1458. Guus has left

  1459. Neustradamus has left

  1460. Neustradamus has joined

  1461. lovetox has left

  1462. jubalh has joined

  1463. jubalh has left

  1464. rtq3 has left

  1465. rtq3 has joined

  1466. Dave Cridland has left

  1467. andy has left

  1468. jubalh has joined

  1469. rtq3 has left

  1470. rtq3 has joined

  1471. Lance has joined

  1472. ralphm has joined

  1473. Neustradamus has left

  1474. Neustradamus has joined

  1475. Guus has left

  1476. andy has joined

  1477. ralphm has left

  1478. lumi has left

  1479. ralphm has joined

  1480. SamWhited has left

  1481. Guus has left

  1482. Syndace has left

  1483. Syndace has joined

  1484. Lance has left

  1485. Nekit has left

  1486. Alex has left

  1487. rtq3 has left

  1488. rtq3 has joined

  1489. ralphm has left

  1490. jubalh has left

  1491. SaltyBones has left

  1492. Guus has left

  1493. Guus has left

  1494. ralphm has joined

  1495. Neustradamus has left

  1496. Neustradamus has joined

  1497. jjrh has left

  1498. jjrh has left

  1499. jjrh has left

  1500. andy has left

  1501. Maranda has joined

  1502. Guus has left

  1503. jjrh has left

  1504. rtq3 has left

  1505. rtq3 has joined

  1506. jjrh has left

  1507. Syndace has left

  1508. Syndace has joined

  1509. Guus has left

  1510. ralphm has left

  1511. rtq3 has left

  1512. ralphm has joined

  1513. Guus has left

  1514. jjrh has left