XSF Discussion - 2018-11-17

  1. lovetox_ has left

  2. Zash has left

  3. Zash has left

  4. UsL has left

  5. UsL has joined

  6. SamWhited has left

  7. lnj has left

  8. lskdjf has joined

  9. SamWhited has left

  10. vanitasvitae has left

  11. l has joined

  12. vanitasvitae has joined

  13. lskdjf has joined

  14. matlag has left

  15. lnj has left

  16. j.r has left

  17. j.r has joined

  18. waqas has joined

  19. waqas has left

  20. lskdjf has joined

  21. lovetox has left

  22. ta has left

  23. lnj has left

  24. l has joined

  25. l has left

  26. l has left

  27. l has left

  28. matlag has left

  29. lumi has left

  30. matlag has left

  31. j.r has left

  32. j.r has joined

  33. lskdjf has left

  34. lskdjf has left

  35. l has left

  36. j.r has left

  37. j.r has joined

  38. lskdjf has left

  39. j.r has left

  40. matlag has left

  41. j.r has joined

  42. SamWhited has left

  43. UsL has left

  44. UsL has joined

  45. jjrh has left

  46. alacer has joined

  47. jjrh has left

  48. mimi89999 has left

  49. Ge0rG has left

  50. pep. has left

  51. ThibG has joined

  52. j.r has joined

  53. j.r has joined

  54. Ge0rG has left

  55. alacer has left

  56. alacer has joined

  57. valo has left

  58. valo has joined

  59. jjrh has left

  60. jjrh has left

  61. alacer has left

  62. alacer has joined

  63. Yagiza has joined

  64. alacer has left

  65. alacer has joined

  66. lorddavidiii has joined

  67. alacer has left

  68. Yagiza has left

  69. Yagiza has joined

  70. jjrh has left

  71. jjrh has left

  72. ThibG has joined

  73. ta has joined

  74. jjrh has left

  75. alacer has joined

  76. waqas has joined

  77. jjrh has left

  78. jjrh has left

  79. alacer has left

  80. guusdk has left

  81. j.r has left

  82. guusdk has left

  83. guusdk has joined

  84. j.r has joined

  85. guusdk has left

  86. guusdk has joined

  87. guusdk has left

  88. guusdk has joined

  89. guusdk has left

  90. Neustradamus has left

  91. mimi89999 has joined

  92. guusdk has left

  93. guusdk has joined

  94. lovetox has joined

  95. MattJ has joined

  96. Yagiza has left

  97. blabla has joined

  98. rion has left

  99. Neustradamus has left

  100. rion has left

  101. rion has left

  102. rion has left

  103. Holger has left

  104. Nekit has joined

  105. guusdk has left

  106. guusdk has joined

  107. rion has left

  108. Yagiza has joined

  109. rion has left

  110. blabla has joined

  111. rion has left

  112. Neustradamus has left

  113. rion has left

  114. blabla has joined

  115. marc has joined

  116. lorddavidiii has left

  117. labdsf has left

  118. sonny has joined

  119. rion has left

  120. alacer has joined

  121. labdsf has joined

  122. rion has left

  123. alacer has left

  124. alacer has joined

  125. waqas has left

  126. waqas has joined

  127. Alex has joined

  128. waqas has left

  129. rion has left

  130. daniel has left

  131. lnj has joined

  132. daniel has left

  133. daniel has left

  134. alacer has left

  135. blabla has joined

  136. ThibG has joined

  137. daniel has left

  138. daniel has left

  139. goffi has joined

  140. daniel has left

  141. APach has left

  142. ThibG has joined

  143. APach has joined

  144. genofire has left

  145. Alex has left

  146. Maranda has joined

  147. daniel has left

  148. Maranda has joined

  149. blabla has joined

  150. daniel has left

  151. winfried has left

  152. winfried has joined

  153. Syndace has joined

  154. j.r has joined

  155. j.r has joined

  156. guusdk has left

  157. guusdk has joined

  158. lumi has joined

  159. vanitasvitae has left

  160. vanitasvitae has joined

  161. daniel has left

  162. Syndace has joined

  163. guusdk has left

  164. sonny has joined

  165. l has left

  166. l has joined

  167. Alex has joined

  168. guusdk has left

  169. rion has left

  170. guusdk has left

  171. guusdk has left

  172. guusdk has joined

  173. 404.city has joined

  174. 404.city has left

  175. jonas’ has left

  176. jonas’ has joined

  177. jonas’ has joined

  178. Maranda has joined

  179. Maranda has joined

  180. l has joined

  181. Maranda has left

  182. Maranda has joined

  183. tux has joined

  184. Holger has left

  185. Kev has left

  186. Alex has left

  187. mimi89999 has joined

  188. 404.city has joined

  189. alacer has joined

  190. ThibG has joined

  191. ThibG has joined

  192. marc has left

  193. marc has joined

  194. alacer has left

  195. lnj has left

  196. 404.city has left

  197. Syndace has joined

  198. 404.city has joined

  199. Zash has left

  200. rion has left

  201. Zash has left

  202. flow has left

  203. lnj has left

  204. vanitasvitae has left

  205. Ge0rG

    When doing multiple follow-up LMCs, do I reference the original message id or the follow-up message id?

  206. vanitasvitae has left

  207. Ge0rG

    > A single message may be corrected multiple times by subsequent edits. The XEP doesn't quite tackle that explicitly

  208. jonas’

    Ge0rG, the original

  209. Ge0rG

    Aslo should a client allow both?

  210. jonas’

    IMO, no

  211. Ge0rG

    I think yaxim will overwrite the stanza ID with the correction's ID.

  212. Ge0rG

    I mean a _receiving_ client

  213. Link Mauve

    poezio does the same.

  214. Ge0rG

    so poezio will correct the last correction and not the original message?

  215. Ge0rG

    So it means I need to support both?

  216. Link Mauve

    The semantics are defined as replacing the message.

  217. Link Mauve

    This includes the id.

  218. Ge0rG

    Who promoted that shit to Draft?

  219. jonas’

    Link Mauve, only payloads though

  220. Link Mauve

    We have a linked list of older versions in the case the user wants to see a previous version, but we don’t recognise the old id as part of the discussion anymore.

  221. jonas’

    > It is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.

  222. jonas’

    > for all the payloads

  223. jonas’

    the @id is arguably not payload

  224. Link Mauve

    Ugh, I guess I missed that.

  225. pep.

    Would it be possible to get stuff, fliers/stickers/stuff to put on the table to say "Here is the XMPP assembly" (that I can maybe build with stickers myself)

  226. pep.

    for the CCC

  227. Ge0rG

    pep.: SCAM team?

  228. pep.

    scam@ ?

  229. pep.

    https://signup.c3assemblies.de/assembly/982f5ea6-fcea-4c1e-965d-8ef478149ac0 ! (wondering if others can see that)

  230. rion has left

  231. rion has left

  232. rion has left

  233. rion has left

  234. rion has left

  235. lnj has left

  236. alacer has joined

  237. alacer has left

  238. alacer has joined

  239. guusdk has left

  240. guusdk has left

  241. guusdk has joined

  242. rion has left

  243. guusdk has left

  244. guusdk has joined

  245. alacer has left

  246. daniel has left

  247. guusdk has left

  248. guusdk has joined

  249. rion has left

  250. rion has left

  251. guusdk has left

  252. guusdk has joined

  253. lumi has left

  254. lskdjf has left

  255. l has left

  256. l has joined

  257. l has joined

  258. lskdjf has joined

  259. j.r has joined

  260. 404.city has left

  261. blabla has left

  262. Alex has joined

  263. Holger has left

  264. vanitasvitae has left

  265. vanitasvitae has joined

  266. Zash has left

  267. 404.city has joined

  268. j.r has joined

  269. Zash has left

  270. Zash has joined

  271. Zash has left

  272. Zash has joined

  273. Zash has left

  274. Zash has joined

  275. moparisthebest has joined

  276. Ge0rG

    jonas’: how does JabberCat handle that correction-of-correction?

  277. jonas’

    it doesn’t implement LMC yet

  278. jonas’

    but in my mental model I was expecting to see the original ID

  279. Ge0rG

    lovetox: which message ID does Gajim referene on a correction of a correction?

  280. Ge0rG

    Conversations also corrects the last ID and not the original one

  281. jonas’


  282. jonas’

    then we’re doomed

  283. guusdk has left

  284. guusdk has left

  285. guusdk has joined

  286. Zash


  287. flow

    or we could make a list of the pros and cons of the different approaches and after careful evaluation aggree on exactly one

  288. jonas’

    flow, that sounds good

  289. jonas’

    Ge0rG, would you care to take it to the list?

  290. Ge0rG

    jonas’: you are lagging

  291. jonas’

    sorry :)

  292. rion has left

  293. Ge0rG

    I should keep a list somewhere of my questions to standards@ that never got answered

  294. jonas’

    Ge0rG, you got an answer!

  295. jonas’

    (but the list is probably still processing it)

  296. rion has left

  297. rion has left

  298. flow

    he said blockchain!

  299. jonas’


  300. rion has left

  301. MattJ

    I'm surprised it got through the spam filters

  302. jonas’


  303. l has joined

  304. matlag has left

  305. rion has left

  306. moparisthebest has joined

  307. rion has left

  308. Ge0rG

    > he said blockchain! ITYM Smart Contracts

  309. rion has left

  310. lskdjf has left

  311. moparisthebest has left

  312. lskdjf has left

  313. moparisthebest has joined

  314. lskdjf has joined

  315. waqas has joined

  316. rion has left

  317. Alex has left

  318. !xsf_martin has joined

  319. Alex has joined

  320. lovetox

    Gajim corrects the last message

  321. lovetox

    i always thought its pretty clear what that means

  322. lovetox

    protocol wise the last message that was sent out by the client

  323. lovetox

    not what the user may think was the last message or what the UI shows him as last message

  324. jonas’

    that’s also a nice rationale

  325. lovetox

    this all does not change though that the XEP allows to correct every message

  326. lovetox

    not only the last

  327. lovetox

    its just a recommendation

  328. jonas’

    requiring to correct the original @id and forgetting about the correction @id makes not-last message correction consistent though

  329. Maranda has joined

  330. jonas’

    otherwise you can make a tree of corrections :)

  331. jonas’

    (well, you could also specify to forget the original @id and only keep the corrected one to fix that tree)

  332. lovetox

    i always thought this works good, you basically make a linked list of messages, every message references the one before with a correction

  333. daniel

    I forget the old one

  334. jonas’

    also, lovetox, daniel, to standards@ please

  335. jonas’

    otherwise Ge0rG is sad that he doesn’t get on-list replies ;-)

  336. daniel

    lovetox: so just to be clear about. When you correct for the second time you correct the id of the previous connection not the original one?

  337. lovetox


  338. daniel

    *Previous correction

  339. Maranda has joined

  340. lovetox

    the last message protocol wise

  341. Ge0rG

    daniel: you are still listening, right?

  342. lovetox

    the last message i sent out

  343. daniel

    Then four clients independently made the same decision

  344. daniel

    That seems pretty clear to me

  345. daniel

    I mean we can clear up the xep

  346. jonas’

    yes please

  347. Ge0rG


  348. jonas’

    I would’ve implemented it differently

  349. Ge0rG

    but jonas’ is right, this implies a tree and not a list

  350. daniel

    Not if you forget the old one

  351. daniel

    Which lovetox and I are doing

  352. Ge0rG

    but if we always reference the original, this is a star topology

  353. jonas’

    flattened by timestamps

  354. Ge0rG

    daniel: "forgetting" is an important point BTW, what if you only have the last N messages, and the original is N+1

  355. Ge0rG

    and are you keeping the timestamp?

  356. daniel

    Not sure about timestamps

  357. jonas’

    Ge0rG, then you already know which IDs you can ignore :)

  358. daniel

    I think I might use the new timestamp

  359. daniel

    But I can check later

  360. Ge0rG

    in yaxim, the correction timestamp overrides the original one, moving the LMC to the bottom of the chat

  361. lovetox

    Ge0rG, you cant know what message i want to correct

  362. lovetox

    i send you a message with a reference to an id

  363. lovetox

    and you correct that

  364. lovetox

    you have to pre prepared to get a message referencing the last message you received

  365. daniel

    Can I propose YMC again

  366. jonas’


  367. daniel

    Yolo message correction

  368. daniel

    Anyone can correct any message

  369. jonas’

    oh dear

  370. Ge0rG

    lovetox: I lost you.

  371. lovetox

    i dont know why you care what message i correct

  372. lovetox

    "the original" or some other message

  373. lovetox

    when implementing that i didnt spend one thought about what messge another clients wants to correct and if its a original or not

  374. jonas’

    lovetox, the question is then how you decide what is displayed, maybe?

  375. jonas’

    I don’t konw, I can’t follow

  376. lovetox

    message comes in -> has id ref -> look is that id the last message for that client -> yes -> overwrite that message in gui

  377. jonas’

    which would break if your interpretation of what constitutes the "last message" diverged from everyone elses (which it doesn’t)

  378. Maranda has joined

  379. jonas’

    i.e. if everyone (except you) agreed that replacement does not create a new "last mesasge" and thus would be using @id of the original message, you wouldn’t be able to handle re-corrections at all (because your flow would discard it because it’s not hte "last message")

  380. jonas’

    and this is why it’s sensible to think about this

  381. lovetox


  382. jonas’

    you just got lucky that your intuition matched that of others :)

  383. jonas’

    (mine didn’t)

  384. lovetox

    in my opinion this is a easy to follow rule that every client can check

  385. lovetox

    the last message i received over the wire

  386. lovetox

    every other definition depends on what you do with your UI

  387. lovetox

    what you show the user

  388. lovetox

    what you do in your db

  389. jonas’

    not really

  390. jonas’


  391. jonas’

    by that argument

  392. marc has left

  393. jonas’

    do you allow corrections after you have seen Chat STate Notifications from a client?

  394. marc has joined

  395. jonas’

    or Chat Markers

  396. jonas’

    which are also messages

  397. lovetox

    thats not what i meant

  398. jonas’

    but it’s the same thing :)

  399. lovetox

    obviously we talking about stuff that has a body

  400. jonas’

    not that obvious

  401. lovetox

    my point is

  402. jonas’

    you could treat corrections as meta-message just like CSN or Markers, apply its effect (replace previous messages payload) and not include it in the "messages" array.

  403. jonas’

    it is not that obvious, is all I’m saying

  404. lovetox

    how should i know that if i reference a id that is 3 messages back, is till the last message for your client?

  405. jonas’


  406. jonas’

    because you don’t include the corrections in your list of "messages"

  407. rion has left

  408. rion has left

  409. 404.city has left

  410. guusdk has left

  411. lovetox

    > A single message may be corrected multiple times by subsequent edits.

  412. lovetox

    for me this is just stating that this is possible

  413. Ge0rG

    lovetox: your ML message is as ambiguous as what you write in here. I can't follow you

  414. lovetox

    what is ambiguous?

  415. Ge0rG

    lovetox: in terms of the two examples you provided to Андрей, which one is Gajim sending out, and which one of those it understands when receiving?

  416. lovetox

    that post was a question to the list

  417. lovetox

    and not to answer your question

  418. lovetox

    see my other ML reply to answer your question

  419. Ge0rG

    lovetox: but your answer to my question also didn't answer my question

  420. lovetox

    whats not clear about it?

  421. lovetox

    how can the "last message that is sent over the wire" be ambiguous

  422. lovetox


  423. Ge0rG

    lovetox: so you reference the id of the last correction?

  424. Ge0rG

    or rather, previous correction

  425. lovetox


  426. lovetox

    i dont see the value in the other approach, instead of just checking the last message, you would have to check all messages between the original and the last correction

  427. Zash has left

  428. lovetox

    you must check that all these messages are corrections of the original, otherwise you would have to deny the correction

  429. Ge0rG

    how will Gajim handle a received message correcting the original ID?

  430. lovetox

    it denys all messages that dont reference the last message that was received

  431. lovetox

    deny meaning its displayed not as correction

  432. Ge0rG


  433. lovetox

    thats my idea of it, i never put it to a test in gajim though ^^

  434. lovetox

    my idea how the code should work, and what it actually does are sometimes not the same thing

  435. !xsf_martin has left

  436. goffi

    Hello. In XEP-0198 what happen if client specify a prefered maximum resumption time ("max" attribute) and server specify an other one? I don't see the point of having 2 different values (except if the server has a default value and overwritte it by client prefered value, but nothing like that is specified).

  437. sonny has joined

  438. guusdk has left

  439. Holger

    goffi: The client can specify a desired value, but the server decides.

  440. goffi

    Holger: OK thanks, in this case the formulation in the XEP is bad, it states "he <enabled/> element MAY include a 'max' attribute to specify the server's preferred maximum resumption time.", it's not preferred value, it's authority value: the one which will be used.

  441. Maranda has joined

  442. Andrew Nenakhov has joined

  443. Holger

    goffi: Revision 0.7 had this: > the <sm/> element MUST include a 'max' attribute that specifies the longest allowable time period for session resumption (in seconds). https://xmpp.org/extensions/attic/xep-0198-0.7.html

  444. Holger

    I guess in the end it's not really interesting for clients. I guess they'll usually just try to resume as fast as possible, and they must be prepared to handle a <failed/> resumption no matter whether they're within the 'max' time period or not.

  445. lovetox

    yeah, i dont see how this is useful for the client

  446. moparisthebest has joined

  447. moparisthebest has joined

  448. Andrew Nenakhov has left

  449. Andrew Nenakhov has joined

  450. blabla has left

  451. lumi has joined

  452. rion has left

  453. labdsf has left

  454. Link Mauve has left

  455. krauq has joined

  456. krauq has joined

  457. Link Mauve has joined

  458. daniel has left

  459. SamWhited has left

  460. Andrew Nenakhov has left

  461. labdsf has joined

  462. daniel has left

  463. daniel has left

  464. daniel has left

  465. goffi

    Holger: it's interesting for client to know when the session can be deleted.

  466. goffi

    I don't think it's really interesting to specify, as the server have authority anyway, but knowing when the session ends is useful, and it should be a "MUST" and not a "MAY" in my opinion (in <enabled/>).

  467. Andrew Nenakhov has joined

  468. Maranda has left

  469. daniel has left

  470. Holger

    goffi: At least with ejabberd, the timeout for a given session can change after <enabled/>, so I'm not sure ejabberd could adhere to such a MUST clause.

  471. goffi

    Holger: how does it changes ?

  472. Holger

    The server can be configured in a way that enabling of push notifications increases the timeout drastically. And then when an actual push notification is generated, the original timeout is restored. Stuff like that.

  473. efrit has joined

  474. matlag has left

  475. efrit has left

  476. efrit has joined

  477. Syndace has joined

  478. blabla has left

  479. vanitasvitae has left

  480. Syndace has joined

  481. Zash has left

  482. Zash has left

  483. Zash has joined

  484. Andrew Nenakhov has left

  485. Zash has left

  486. Zash has joined

  487. Andrew Nenakhov has joined

  488. Zash has left

  489. Zash has joined

  490. tux has joined

  491. lorddavidiii has joined

  492. marc has left

  493. marc has joined

  494. Syndace has joined

  495. vanitasvitae has left

  496. labdsf has left

  497. labdsf has joined

  498. Syndace has joined

  499. lskdjf has left

  500. labdsf has left

  501. vaulor has left

  502. Yagiza has left

  503. APach has left

  504. Alex has left

  505. matlag has left

  506. labdsf has joined

  507. matlag has left

  508. matlag has left

  509. Andrew Nenakhov has left

  510. Andrew Nenakhov has joined

  511. Alex has joined

  512. Andrew Nenakhov has joined

  513. Zash has left

  514. APach has joined

  515. sonny has joined

  516. pep. has left

  517. SamWhited has left

  518. moparisthebest has joined

  519. moparisthebest has joined

  520. blabla has joined

  521. lovetox_ has joined

  522. j.r has left

  523. marc has left

  524. j.r has joined

  525. SamWhited has left

  526. SamWhited has joined

  527. lovetox_ has left

  528. lovetox_ has joined

  529. lovetox_ has left

  530. lovetox_ has joined

  531. lovetox_ has left

  532. lovetox_ has joined

  533. lovetox_ has left

  534. marc has joined

  535. sonny has joined

  536. j.r has left

  537. j.r has joined

  538. lorddavidiii has left

  539. lorddavidiii has joined

  540. lovetox has left

  541. marc has left

  542. lnj has left

  543. j.r has left

  544. j.r has joined

  545. vaulor has joined

  546. ta has joined

  547. j.r has left

  548. j.r has joined

  549. lorddavidiii has left

  550. marc has joined

  551. SamWhited has left

  552. lnj has left

  553. Zash has left

  554. thorsten has left

  555. Nekit has joined

  556. thorsten has joined

  557. SamWhited has joined

  558. thorsten has left

  559. j.r has left

  560. Zash has left

  561. j.r has left

  562. vaulor has left

  563. vaulor has joined

  564. j.r has joined

  565. Zash has left

  566. Zash has left

  567. Zash has left

  568. j.r has left

  569. j.r has joined

  570. thorsten has joined

  571. jjrh has left