XSF Discussion - 2020-04-28


  1. larma

    XEP-0308 allows to edit the last message of each full jid by the bare jid in direct messages. Which means I could technically edit another resources message. But when I do, I run into a race condition as that other resource could send another message shortly before my correction thus effectively making my correction "out of scope" of XEP-0308.

  2. larma

    Also, when I send each message with a new resource, I could technically use XEP-0308 standards compliant to correct any message, not only the latest

  3. larma

    The issue with race condition also applies to editing in MUCs, due to multi session nicks

  4. Ge0rG

    larma: the scoping doesn't make much sense. I'd suggest you roll a D20 to determine how many recent messages you accept edits for, and only count those based on the sender's bare JID / identity

  5. Ge0rG

    larma: also you could hope that a user won't send a message from device A and *at the same time* edit an old message from device B

  6. Zash

    Aren't edits by id too?

  7. larma

    Ge0rG, question is not only for incoming but also outgoing. And "at the same time" could be caused by a mobile device coming back online and having that message still in its offline queue.

  8. larma

    Zash, yes, we do have the ID, but 0308 has some obscure rules beside ID (which seems to be so that legacy fallback can easier spot that it's a correction)

  9. Ge0rG

    larma: yaxim is limiting editing to the last 10 messages from the same sender

  10. Ge0rG

    larma: the XEP author said "editing other than the last message is out of scope of the XEP"

  11. Ge0rG

    and don't even get me started on which ID to edit in multi-edits.

  12. larma

    so yaxim allows incoming and outcoming edits that are not specified in any standard?

  13. Ge0rG

    yes.

  14. Ge0rG

    and it's even worse than that.

  15. larma

    And then other clients don't support those edits incoming I guess? So UX is crap

  16. Ge0rG

    yaxim allows edits in semi-anon MUCs originating from the same nickname, even if somebody stole the nickname

  17. Ge0rG

    larma: 🤷

  18. larma

    re nick stealing: 0421 to the rescue?

  19. Ge0rG

    larma: 0421 has interesting issues of its own. But yes, it's on my long-term todo list

  20. Ge0rG

    which is probably just an elaborate way of saying: I don't care

  21. Ge0rG

    if you want to attach identity to nicknames in semi-anon MUCs, then register the nicknames or don't use semi-anon

  22. larma

    also, which clients will allow this correction-10-messages-ago incoming? And why 10? And is that the last 10 by bare jid, so if I write 1 message X with resource A and then >10 message with resource B, you don't allow correction of message X anymore (even though you should under XEP-0308)?

  23. Ge0rG

    larma: 1. yaxim, I don't care about the others. 2. It seemed like a good trade-off, given nobody else cared about it. 3. Yes, by bare JID (or by nickname in MUCs)

  24. larma

    Great, so we probably have a mix of incompatible rules for last message correction in various clients and even the spec is broken by design

  25. Ge0rG

    larma: indeed

  26. larma

    So, how do we fix this mess?

  27. Ge0rG

    larma: write a new XEP that extends 0308 to the last N messages.

  28. Ge0rG

    larma: Daniel suggested YMC, "YOLO Message Correction", allowing to edit any messages regardless of age and sender.

  29. Ge0rG

    I can't find any relevant mail from me to standards, so it probably was buried in a Council meeting

  30. larma

    But when we do "any message correction", fallback body becomes pretty useless, no?

  31. Ge0rG

    fallback body of what?

  32. larma

    well fallback body of correction

  33. Ge0rG

    why should there be a *fallback* body?

  34. larma

    for clients not supporting it?

  35. Zash

    fallback body should be "I mean $message *"

  36. Ge0rG

    larma: there is no fallback body in 0308

  37. larma

    Ge0rG, well the body is the fallback

  38. Ge0rG

    larma: the body is the newbody.

  39. larma

    Well, it happens to have two usecases at the same time

  40. larma

    because legacy clients will display it as a normal message

  41. larma

    which is ok, if it really is the last message

  42. larma

    which is ok, if it really is the last message, see?

  43. Ge0rG

    larma: so your point is: correcting an older message will lead to confusion in non-0308 client users?

  44. larma

    with 0308 we don't really have that problem due to its restriction to the last message.

  45. larma

    if we allow edits of older messages though, we get into trouble

  46. Ge0rG

    let me make a controversial proposal: editing of older messages should be restricted by their age, not by their amount.

  47. larma

    still the same issue, no?

  48. Zash

    Why not both‽

  49. Ge0rG

    it's happened to me many times that I sent a message, then another one, then realized I had a typo in the first one.

  50. Ge0rG

    larma: actually it's a much worse issue: time is relative

  51. Zash

    Sneak-edit of a message that has scrolled out of view seems about as bad as a sneak-edit of a 7 hour old message.

  52. larma

    "sneak-edit"?

  53. Zash

    Snake edit?

  54. Zash

    Snape edit!

  55. Zash

    I mean an edit that you're unlikely to notice

  56. Zash

    Ie because it scrolled out of view.

  57. larma

    I don't consider those an issue really

  58. Ge0rG

    Zash: but how large is the view?

  59. Zash

    Either because time passed or because discussio

  60. Zash

    Ge0rG, three fiddy

  61. Ge0rG

    in yaxim, a view is roughly ten messages. See, I found a reason for the arbitrary number

  62. Zash

    Dice roll

  63. larma

    If I edit an old message that is probably scrolled out of view at the recipient, I must expect the edit not to be recognized by them

  64. larma

    that's ok

  65. Ge0rG

    larma: "But you said yes to my contract proposal, it's binding now!"

  66. Ge0rG

    the older a message, the lower the probability that you actually *need* to edit it.

  67. larma

    Ge0rG, "My client says 'Yes (edited)', and you changed to from 'No'"

  68. larma

    Ge0rG, "My client says 'Yes (edited)', and you changed it from 'No'"

  69. larma

    Also, this seems to be a social issue, not a protocol issue.

  70. Ge0rG

    of course it is

  71. larma

    I can also edit paper contracts after you signed them, even without you noticing.

  72. larma

    I don't think we need to do better than reality here.

  73. Ge0rG

    larma: what limits do you consider sensible?

  74. larma

    No limit?

  75. Ge0rG

    edit everything?

  76. larma

    Yes, but I don't see the solution for the "not sure which message was edited" in the fallback case

  77. larma

    except not showing edits to legacy clients at all.

  78. Ge0rG

    larma: stop caring too much about legacy clients.

  79. Ge0rG

    if you edit the 11th-last message, yaxim will not merge the edit into the original, but will display this as a new message with an "edited" tag

  80. larma

    Ge0rG, legacy client = literally every client right now

  81. Ge0rG

    0308 is part of Advanced IM 2020

  82. larma

    Yes, but only the "version" accepting an edit of the last message of each full jid by the corresponding bare jid, which I bet nobody implements.

  83. pep.

    fwiw I was also considering with poezio taking into account more than the latest, in a proper way. poezio already does AMC in reading

  84. pep.

    (maybe unintentionally, dunno, it was the case when I joined)

  85. pep.

    and it's possible to send AMC with /rawxml (great UX!)

  86. Ge0rG

    larma: 0308 was adopted in 2013, that was long before my activity started.

  87. Ge0rG

    larma: I could theoretically imagine Council relaxing the "last message only" rule, but I wouldn't bet on it

  88. larma

    Ge0rG, well my point is: If I fix a typo 10 messages ago, I don't want any client to display that typo-fixing as a new message, as it would just cause confusion. But I still want to be able to do those fixes.

  89. Ge0rG

    larma: I agree.

  90. larma

    So just changing XEP-0308 to allow AMC doesn't solve the issue

  91. Ge0rG

    larma: nothing will solve the issue right now.

  92. Ge0rG

    not even creating a new XEP that defines AMC on top of 0308.

  93. pep.

    larma, maybe using <body> for this is just wrong :P

  94. Ge0rG

    except maybe creating that new XEP and putting it into CS2021 and then waiting.

  95. Ge0rG

    pep.: please no!

  96. pep.

    <replace @id>correction</replace>

  97. larma

    creating a new XEP that defines AMC *outside* of 0308 so that legacy clients / 0308-clients do not display the correction at all would solve the issue.

  98. larma

    but that implies not using <body>

  99. larma

    Or precisely not using <body> in <message>

  100. pep.

    And then people want you to take into consideration non-implementing clients and you're back to square one

  101. Ge0rG

    pep.: easy: just add a legacy body into AMC!

  102. larma

    could still be <message><edit xmlns="urn:xmpp:edit:0"><body xmlns="jabber:client">Correction</body></edit></message>

  103. Ge0rG

    larma: that would make some sense indeed.

  104. Ge0rG

    would allow differentiating the *edited* part from the edit metadata part.

  105. pep.

    larma, I'm not sure I understand the intent

  106. pep.

    non-implementing clients won't understand this

  107. larma

    <message><body>/me edits "Corection" in message from 01:02:03 to "Correction"</body><edit xmlns="urn:xmpp:edit:0"><body xmlns="jabber:client">Correction</body></edit></message>

  108. Ge0rG

    Yeah.

  109. pep.

    ugh

  110. larma

    Fallback body *only* if I want legacy clients to display something of course

  111. larma

    (not in the case of fixing that one type)

  112. pep.

    Seeing the wire format of /me hurts every single time

  113. pep.

    larma, still not sure I understand the point of <body/> in <edit/>

  114. pep.

    Also in your fallback you included localtime

  115. pep.

    Or UTC, or ?

  116. pep.

    Which one is it

  117. larma

    Well the <body> in <message> is only for those clients that don't understand the <edit>. The client supporting <edit> will just edit the old message and not display the fallback at all.

  118. pep.

    I did say the <body> in <edit>

  119. larma

    yes, that's whay is used as a replacement for the body when the client supports <edit>

  120. larma

    because I might want to edit other elements than edit

  121. pep.

    Why do you need an extra child

  122. pep.

    ah ok

  123. larma

    because I might want to edit other elements than body

  124. pep.

    That's the info I was missing

  125. larma

    And it also seems consistent to have the displayed body in the <body> element

  126. pep.

    If you could only edit <body>, I don't think so

  127. pep.

    I think it's being frowned upon anyway to edit anything else than <body/>, iiuc

  128. larma

    Well, if I upload a file, why not edit the description of the file (assuming a SIMS-alike file sending)

  129. pep.

    I'm personally fine with this

  130. Ge0rG

    why not replace the file with another one?

  131. larma

    or that

  132. Ge0rG

    I accidentally a dickpic.

  133. larma

    or if the file is a text file and has a typo in it

  134. pep.

    Ge0rG, the internet will have to live with it forever

  135. larma

    OK, solution was found, now just need someone to write the XEP 😀

  136. larma

    And then a council to accept it even if it's not making use of fastenings 😕

  137. Ge0rG

    larma: but it should make use of fastenings! You fasten the correction to the original message!

  138. larma

    Ge0rG, my message is end-to-end-encrypted with forward secrecy, I am not fastening anything because fastening is crap when having forward secrecy

  139. larma

    newsflash: OMEMO uses forward secrecy and is literally what made XMPP popular again

  140. larma

    but it's probably a sidecase we don't want to care about 😕

  141. Blue

    Can somebody smart explain me something about stanza id xep?

  142. Ge0rG

    Blue: if you find somebody smart...

  143. pep.

    larma: everyone has a different opinion on what makes XMPP (not) popular :p

  144. Blue

    I'm pretty sure most of you here are smart on my terms =)

  145. Ge0rG

    Blue: then maybe ask the question :)

  146. larma

    pep., yeah, I just needed my daily criticism of the reactions decision, didn't want to actually make a point here 😉

  147. pep.

    hehe

  148. Zash

    What if we lock all stakeholders in a room until the whole reactions thing is resolved?

  149. pep.

    that is, everybody kills each other?

  150. flow

    larma> Fallback body *only* if I want legacy clients to display something of course that's also the approach which I would be pursuing

  151. Blue

    So, there is nice and cool "id" attribute for the message. You can edit retract confirm delivery with that and so much more. Basically - da heck is stansa id? How to behave with it?

  152. flow

    larma> Well, if I upload a file, why not edit the description of the file (assuming a SIMS-alike file sending) that a nice idea, but I fear it is far easier to implement just re-issuing the SIMS

  153. pep.

    flow, then a client displays two "media" thing?

  154. pep.

    For ""the same"" file

  155. flow

    pep., maybe, or it does only display the corrected SIMS, while still allowing data fetches of the old SIMS

  156. larma

    Blue, id attribute and <origin-id> id attribute should be the same. <stanza-id> is important for MUCs and MAM.

  157. Ge0rG

    Blue: old clients don't generate a unique id attribute.

  158. pep.

    Ah, fight on 0359, that's also something I was curious about

  159. Ge0rG

    and <stanza-id> is added by somebody else than the sender, typically an archive

  160. flow

    Blue, if something doesn't explicitly talk about xep359 IDs then use the RFC 6120 IDs

  161. MattJ

    Blue, the 'id' attribute is optional, and set by the first entity to generate the stanza. It may not be present, and it may not be unique. The stanza-id element allows other entities (such as a client's server) to inject their own ids.

  162. MattJ

    The id attribute is useful for short-term error tracking, stanza-id is useful for an entity to assign a more permanent unique id to a stanza (and it's not limited to just one)

  163. MattJ

    and origin-id is mostly a hack that we've discussed potentially removing in the past (though it has a couple of useful properties)

  164. Ge0rG

    I'm interested in those useful properties, beyond virtue signaling of "proper" ID generation

  165. Blue

    I just don't get how to treat them. You see, I have sort of message order in my lil app. I ordered them using ID attribute. Do i need the same order of stansaIds pointing to the same messages? Or do I just replace my pointing to the message id with newly discovered stansa id? Then how do I discover the stansa id server assigned to my outgoing message? There are attachements to the messages described in some xep, they go to stansa id, but i just checked message corrections - they go only to origin ids.... I'm a bit lost and confused =)

  166. MattJ

    None of the ids are guaranteed to be sortable

  167. MattJ

    So you can't use them for order

  168. MattJ

    There is currently no (sensible) way to discover the stanza-id assigned by the server to an outgoing stanza, that's something that will hopefully be fixed at some point

  169. Blue

    but that doesn't make sence... There is sorted by time stream of messages...

  170. MattJ

    Sure, I'm not saying messages don't have an order. I'm saying that ids are not used to convey the order.

  171. Blue

    but... how to query the history then?

  172. MattJ

    You can still query from the last incoming message

  173. Blue

    but I cant relay on time either - it's also optional (stamp if I'm not mistaken) and a little to approximate, isn't it?

  174. MattJ

    Yes, don't use time

  175. Zash

    Time where?

  176. MattJ

    Anywhere

  177. Zash

    I do have this "origin-time" draft...

  178. zzzed

    Hello, when i try to start private convesation (otr) and to generate fingerprints app instant close

  179. zzzed

    any help?

  180. Blue

    so... for that reason I build an order of messages, but seems like I have miscalculated about the id's I use in that order

  181. zzzed

    anyone to help me out?

  182. zzzed

    Kev MattJ ralphm

  183. zzzed

    am

  184. zzzed

    intosi

  185. zzzed

    admin

  186. MattJ

    zzzed, you're asking the wrong people in the wrong channel

  187. MattJ

    Stop highlighting people for no reason please

  188. zzzed

    aha , where should i finde help then?

  189. MattJ

    What app are you using?

  190. zzzed

    you dont need to be rude at all , you can say on nice way

  191. zzzed

    PSI

  192. MattJ

    https://search.jabber.network/search?q=psi

  193. zzzed

    thanks

  194. zzzed

    have a nice day

  195. MattJ

    You too

  196. jonas’

    does anyone have a clue about those ref files we generate for XEPs?

  197. jonas’

    https://github.com/xsf/xeps/pull/938

  198. jonas’

    I’d love to get a review on that one before hiting the green button

  199. flow

    jonas’, lgtm

  200. jonas’

    flow, can you add a review on github please?

  201. flow

    those are mostly used by https://xml2rfc.tools.ietf.org/

  202. flow

    and as you can see, e.g. https://xmpp.org/extensions/refs/reference.XSF.XEP-0435.xml has no target

  203. flow

    int the root note

  204. flow

    in the root node

  205. flow

    wheras https://xml2rfc.tools.ietf.org/public/rfc/bibxml2/reference.NIST.SP.800-185.xml has

  206. jonas’

    flow, good, can you add that as a review on github?

  207. jonas’

    thx

  208. Zash

    What are this?

  209. flow

    Zash, "this"?

  210. Zash

    These refs things

  211. flow

    those ref entries are consumed by xml2rfc and can be used as references in I-Ds and RFCs

  212. flow

    think of biblatex entries for RFCs

  213. Zash

    Oh-kay