-
lovetox
What limits on message corrections do clients enforce?
-
lovetox
Gaim accepts corrections for all messages if they are within 300 seconds
-
lovetox
just want to get a feel what other clients do
-
MattJ
I don
-
MattJ
I don't know of any enforcing a time limit, but I think it's the right approach
-
MattJ
Most allow only the most recent message (per the XEP)
-
jonas’
though 300s is not a good number IMO
-
MattJ
I think one non-XMPP system I looked at was 2 hours
-
jonas’
that sounds more reasonable
-
lovetox
the most recent message is a kind of limit
-
lovetox
and do you think its good to have a different limit for the last message, than for older ones?
-
lovetox
i mostly am a bit scared because to make it nice for the user this little feature entails much GUI work
-
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
-
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
-
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
-
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
-
lovetox
i think most users dont need to correct old messages
-
lovetox
maybe the last message should have a high limit in the range of multiple hours
-
lovetox
but older messages not?
-
lovetox
but such a rule feels weird
-
jonas’
I often notice that there's some annoying typo in a message after I already sent a follow-up
-
jonas’
(most of the times, that follow up is "ugh")
-
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
-
MSavoritias (fae,ve)
(Not saying it should be allowed to edit any message)
-
MSavoritias (fae,ve)
Just that social problems should be necesserily taken into account heer✎ -
MSavoritias (fae,ve)
Just that social problems should be necesserily taken into account here ✏
-
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"
-
lovetox
MSavoritias (fae,ve), your comparison is bad in my opinion, its not a social problem at all
-
lovetox
you see this like you are some guy who stands on the sideline looking at it
-
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
-
lovetox
what is the "current"
-
pep.
Whatever the spec is
-
pep.
Last message only
-
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
-
lovetox
it is not fyi
-
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
-
pep.
pulkomandy, yeah I mentioned that
-
lovetox
but its not, i bet no client lets you search for the "previous" content of an edited message
-
pep.
So..?
-
qy
i render corrections as new messages that are diffs
-
lovetox
you assume clients have facilities to inform the user about every corrected message in a way they are notified
-
qy
i think i am alone in this
-
pep.
lovetox, no, you're putting words in my mouth
-
lovetox
you assume data is not destroyed because clients keep it in a way users can still read it
-
pep.
again
-
lovetox
and if all your assumptions would be true, i would agree, its not a serious issue
-
pep.
This is not an assumption I make
-
lovetox
just so you know, there are 4+ people in this conversation
-
lovetox
when i said "you" i didnt neccarily mean you pep.
-
pep.
Ok
-
pep.
It could have been slightly clearer :/
-
pep.
Anyway I personally don't assume that and I still think it's fine
-
lovetox
just see this from a client perspective, where the user is not notified about corrections, and corrected data can not be retrieved
-
pep.
I mean deception isn't something that happens only with people editing messages. One only needs to send a single message for this..
-
lovetox
is it still a social problem? Or would you say the software developer needs to act
-
pep.
Maybe we should get rid of messages (jk)
-
pep.
Devs can make this comfortable, but I think ultimately it is a social problem
-
pep.
If somebody is here to deceive you, maybe there's a bigger issue at play than message edits
-
lovetox
this is not philosophical
-
pep.
It is entirely
-
lovetox
this is a developer chat for xmpp clients
-
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?
-
lovetox
and a developer asks you if he needs to act
-
pep.
Yes
-
lovetox
is it a Yes you need to do something, or No you dont need to care, its the users problem
-
qy
i mean, it will need attention, but shouldnt be hard
-
pep.
Yes it is a develop chat for xmpp clients :)✎ -
pep.
Yes it is a developer chat for xmpp clients :) ✏
-
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
-
pep.
Ok good for them?
-
lovetox
so seems a few other developers dont treat this as "just a social problem"
-
pep.
Exactly this is what I said: "Devs can make this comfortable, but I think ultimately it is a social problem"
-
lovetox
people doing bad things is a social problem, thanks for the enlightenment
-
lovetox
i dont know how this influences my development decisions
-
pep.
Maybe that's a point that needed reminding :)
-
pep.
Well it does. It may help you have a feel for when to stop locking features for one
-
pep.
(you, people*)
-
pep.
(devs)
-
lovetox
or it justifies laziness
-
pep.
There's a balance to find
-
lovetox
no shit, and thats what the discussion started, is 300 seconds long enough
-
lovetox
the intent was to find the balance
-
pep.
I doubt that's only what balance is about
-
lovetox
but thanks, i know now there is also the other extrem, that i just lay back and do simply nothing
-
lovetox
because all is just a social problem
-
pep.
lol
-
pep.
Communication is hard.. but it's not for lack of trying
-
lovetox
maybe something else comes now in, and tells us message correction should be forbidden, then we have the other extrem also heard
-
pep.
I'm sorry we don't manage to talk together
-
pep.
And I'm out now
-
qy
tħis discussion has lost all productivity
-
qy
ok
-
Zash
What if instead of having hard limits, make it increasingly annoying to do edits the further in the past the original message was.
-
Zash
Like BLINKING and forcibly scrolling all the way back there.
-
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
-
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
-
pep.
And I also wouldn't prevent any edits from being sent
-
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
-
pep.
Yeah that's why I think basing all of this on time is not the answer
-
pep.
(though I still think it's fine to allow edits in the chess case :x)
-
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'
-
qy
in my case i did do the diff thing due to weechat's limitations, but it works out quite nicely
-
qy
i appreciate the layout
-
pep.
Can you share a screenshot maybe?✎ -
pep.
Can you share a screenshot maybe, plz? ✏
-
qy
...i had to do this while my desktop is running freebsd
-
qy
bear with me
-
pep.
I doubt diffs will please every kind of public though
-
pep.
(Even though there isn't a single solution to be adopted here anyway, it's UI/UX after all)
-
qy
https://upload.xa0.uk:5281/upload/ms28ec6yAAShYIGbnHc1trxr/20230106_23h12m23s_grim.png
-
qy
pep.; ^
-
pep.
hmm, I'm skeptical. Plus this doesn't combine well with other colors
-
qy
again, limitations of weechat there :p
-
pep.
Yeah
-
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?
-
Zash
The _example_ ?
-
Zash
The one that uses something that doesn't exist?
-
nicoco
🤐️
-
Zash
ExAmPles aReNT NoRMAtiVe!!11!!11elevnty :)
-
nicoco
what's the plan where the example is all there is? ;)
-
pep.
Propose an edit for the spec :x
-
pep.
Last Spec Edition✎ -
pep.
Last Spec Correction ✏
-
Zash
https://xmpp.org/extensions/inbox/compatibility-fallback.html ?
-
Zash
Wasn't accepted and IIRC the plan was to merge it with https://xmpp.org/extensions/xep-0428.html