XSF logo 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