jdev - 2023-01-06


  1. lovetox

    What limits on message corrections do clients enforce?

  2. lovetox

    Gaim accepts corrections for all messages if they are within 300 seconds

  3. lovetox

    just want to get a feel what other clients do

  4. MattJ

    I don

  5. MattJ

    I don't know of any enforcing a time limit, but I think it's the right approach

  6. MattJ

    Most allow only the most recent message (per the XEP)

  7. jonas’

    though 300s is not a good number IMO

  8. MattJ

    I think one non-XMPP system I looked at was 2 hours

  9. jonas’

    that sounds more reasonable

  10. lovetox

    the most recent message is a kind of limit

  11. lovetox

    and do you think its good to have a different limit for the last message, than for older ones?

  12. lovetox

    i mostly am a bit scared because to make it nice for the user this little feature entails much GUI work

  13. lovetox

    if you allow to correct messages which are not in the "view" anymore, this means you need to have the capability to jump to various messages and highlight them as corrected

  14. lovetox

    further what if a user corrects multiple message which can not displayed in one page, now you need a mechanism that lets the user jump through multiple corrections

  15. lovetox

    so you see, while a correction is a relatively simple database call, to check and to execute, GUI wise its multiple days and weeks work

  16. lovetox

    and all this is just for users who abuse the feature and go back and correct 20 messages, maybe even with the goal to destroy data, or vandalize it

  17. lovetox

    i think most users dont need to correct old messages

  18. lovetox

    maybe the last message should have a high limit in the range of multiple hours

  19. lovetox

    but older messages not?

  20. lovetox

    but such a rule feels weird

  21. jonas’

    I often notice that there's some annoying typo in a message after I already sent a follow-up

  22. jonas’

    (most of the times, that follow up is "ugh")

  23. MSavoritias (fae,ve)

    > lovetox: > and all this is just for users who abuse the feature and go back and correct 20 messages, maybe even with the goal to destroy data, or vandalize it But this feels like trying to solve a social problem with tech. People are gonna abuse it no matter the precautions

  24. MSavoritias (fae,ve)

    (Not saying it should be allowed to edit any message)

  25. MSavoritias (fae,ve)

    Just that social problems should be necesserily taken into account heer

  26. MSavoritias (fae,ve)

    Just that social problems should be necesserily taken into account here

  27. qy

    i think a combination of time and messages since is the ideal here. Something like correctability is still allowed within an hour, or while there are still less than 5 messages after the target? That way slower mucs aren't totally shortchanged by time, but it's not as weird a rule as "last message"

  28. lovetox

    MSavoritias (fae,ve), your comparison is bad in my opinion, its not a social problem at all

  29. lovetox

    you see this like you are some guy who stands on the sideline looking at it

  30. pep.

    I also think it's a social problem fwiw. When somebody is having abusive behaviour you tell them about it and you prevent this behaviour from happening again in your community. Of course you can have some basic safeguards like keeping history displayed somewhere and that's good, but ultimately even the current LMC can be abused and it's fine

  31. lovetox

    what is the "current"

  32. pep.

    Whatever the spec is

  33. pep.

    Last message only

  34. pep.

    And even if it was limited to N minutes anyway it could be abused. I'm sure there are ways. The point is that they're not important because that's a problem to be solved with communication

  35. lovetox

    it is not fyi

  36. pulkomandy

    it depends how you render corrections. If the older content of the message is still available somewhere and it's clear the message has been edited, that limits the social part of the problem

  37. pep.

    pulkomandy, yeah I mentioned that

  38. lovetox

    but its not, i bet no client lets you search for the "previous" content of an edited message

  39. pep.

    So..?

  40. qy

    i render corrections as new messages that are diffs

  41. lovetox

    you assume clients have facilities to inform the user about every corrected message in a way they are notified

  42. qy

    i think i am alone in this

  43. pep.

    lovetox, no, you're putting words in my mouth

  44. lovetox

    you assume data is not destroyed because clients keep it in a way users can still read it

  45. pep.

    again

  46. lovetox

    and if all your assumptions would be true, i would agree, its not a serious issue

  47. pep.

    This is not an assumption I make

  48. lovetox

    just so you know, there are 4+ people in this conversation

  49. lovetox

    when i said "you" i didnt neccarily mean you pep.

  50. pep.

    Ok

  51. pep.

    It could have been slightly clearer :/

  52. pep.

    Anyway I personally don't assume that and I still think it's fine

  53. lovetox

    just see this from a client perspective, where the user is not notified about corrections, and corrected data can not be retrieved

  54. pep.

    I mean deception isn't something that happens only with people editing messages. One only needs to send a single message for this..

  55. lovetox

    is it still a social problem? Or would you say the software developer needs to act

  56. pep.

    Maybe we should get rid of messages (jk)

  57. pep.

    Devs can make this comfortable, but I think ultimately it is a social problem

  58. pep.

    If somebody is here to deceive you, maybe there's a bigger issue at play than message edits

  59. lovetox

    this is not philosophical

  60. pep.

    It is entirely

  61. lovetox

    this is a developer chat for xmpp clients

  62. qy

    > lovetox: > 2023-01-06 10:31 (GMT) > just see this from a client perspective, where the user is not notified about corrections, and corrected data can not be retrieved corrections are stored in MAM, no?

  63. lovetox

    and a developer asks you if he needs to act

  64. pep.

    Yes

  65. lovetox

    is it a Yes you need to do something, or No you dont need to care, its the users problem

  66. qy

    i mean, it will need attention, but shouldnt be hard

  67. pep.

    Yes it is a develop chat for xmpp clients :)

  68. pep.

    Yes it is a developer chat for xmpp clients :)

  69. lovetox

    and btw, on whatsapp i cant correct very old messages, on Conversations i cant correct older messages, on Matrix (Element Client) i cant correct older messages, thats what i found out in 5 minutes

  70. pep.

    Ok good for them?

  71. lovetox

    so seems a few other developers dont treat this as "just a social problem"

  72. pep.

    Exactly this is what I said: "Devs can make this comfortable, but I think ultimately it is a social problem"

  73. lovetox

    people doing bad things is a social problem, thanks for the enlightenment

  74. lovetox

    i dont know how this influences my development decisions

  75. pep.

    Maybe that's a point that needed reminding :)

  76. pep.

    Well it does. It may help you have a feel for when to stop locking features for one

  77. pep.

    (you, people*)

  78. pep.

    (devs)

  79. lovetox

    or it justifies laziness

  80. pep.

    There's a balance to find

  81. lovetox

    no shit, and thats what the discussion started, is 300 seconds long enough

  82. lovetox

    the intent was to find the balance

  83. pep.

    I doubt that's only what balance is about

  84. lovetox

    but thanks, i know now there is also the other extrem, that i just lay back and do simply nothing

  85. lovetox

    because all is just a social problem

  86. pep.

    lol

  87. pep.

    Communication is hard.. but it's not for lack of trying

  88. lovetox

    maybe something else comes now in, and tells us message correction should be forbidden, then we have the other extrem also heard

  89. pep.

    I'm sorry we don't manage to talk together

  90. pep.

    And I'm out now

  91. qy

    tħis discussion has lost all productivity

  92. qy

    ok

  93. Zash

    What if instead of having hard limits, make it increasingly annoying to do edits the further in the past the original message was.

  94. Zash

    Like BLINKING and forcibly scrolling all the way back there.

  95. pulkomandy

    It depends what you're trying to protect against. If you assume an evil sender with some tech skills, they can figure out some way to send an edit anyway. So, on the receiving side, how do you handle it? If you silently replace the previous message, probably you want to do that only for very recent ones. If your GUI allows to see the older version and when the message was edited, maybe you can be a bit more relaxed about it and allow it for older messages

  96. pep.

    I'd put messages that don't currently appear in the buffer back as a "new message", saying it's an edit, have the date made obvious or something

  97. pep.

    And I also wouldn't prevent any edits from being sent

  98. pulkomandy

    Is 300 seconds good? I have no idea. On a busy chat that receives hundreds of messages a minute, it may too long. On an idle channel where you play chess by mail with someone, probably editing only the last message should be allowed otherwise you can cheat at chess

  99. pep.

    Yeah that's why I think basing all of this on time is not the answer

  100. pep.

    (though I still think it's fine to allow edits in the chess case :x)

  101. qy

    honestly i do think my solution is the best one here, actually show the edit "event", even if it's just a 'user edited a message'

  102. qy

    in my case i did do the diff thing due to weechat's limitations, but it works out quite nicely

  103. qy

    i appreciate the layout

  104. pep.

    Can you share a screenshot maybe?

  105. pep.

    Can you share a screenshot maybe, plz?

  106. qy

    ...i had to do this while my desktop is running freebsd

  107. qy

    bear with me

  108. pep.

    I doubt diffs will please every kind of public though

  109. pep.

    (Even though there isn't a single solution to be adopted here anyway, it's UI/UX after all)

  110. qy

    https://upload.xa0.uk:5281/upload/ms28ec6yAAShYIGbnHc1trxr/20230106_23h12m23s_grim.png

  111. qy

    pep.; ^

  112. pep.

    hmm, I'm skeptical. Plus this doesn't combine well with other colors

  113. qy

    again, limitations of weechat there :p

  114. pep.

    Yeah

  115. nicoco

    dino and movim devs, I think we need to determine which namespace we use for the replies fallback. dino went with 'urn:xmpp:fallback:0', but edhelas (and me…) used 'urn:xmpp:feature-fallback:0', as per the example in the replies XEP. so… which one is it?

  116. Zash

    The _example_ ?

  117. Zash

    The one that uses something that doesn't exist?

  118. nicoco

    🤐️

  119. Zash

    ExAmPles aReNT NoRMAtiVe!!11!!11elevnty :)

  120. nicoco

    what's the plan where the example is all there is? ;)

  121. pep.

    Propose an edit for the spec :x

  122. pep.

    Last Spec Edition

  123. pep.

    Last Spec Correction

  124. Zash

    https://xmpp.org/extensions/inbox/compatibility-fallback.html ?

  125. Zash

    Wasn't accepted and IIRC the plan was to merge it with https://xmpp.org/extensions/xep-0428.html