jdev - 2023-01-06

What limits on message corrections do clients enforce?

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

just want to get a feel what other clients do

I don

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

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

though 300s is not a good number IMO

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

that sounds more reasonable

the most recent message is a kind of limit

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

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

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

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

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

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

i think most users dont need to correct old messages

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

but older messages not?

but such a rule feels weird

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

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

> 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

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

Just that social problems should be necesserily taken into account here ✏

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"

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

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

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

what is the "current"

Whatever the spec is

Last message only

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

it is not fyi

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

pulkomandy, yeah I mentioned that

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

So..?

i render corrections as new messages that are diffs

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

i think i am alone in this

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

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

again

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

This is not an assumption I make

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

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

Ok

It could have been slightly clearer :/

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

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

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

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

Maybe we should get rid of messages (jk)

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

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

this is not philosophical

It is entirely

this is a developer chat for xmpp clients

> 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?

and a developer asks you if he needs to act

Yes

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

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

Yes it is a developer chat for xmpp clients :) ✏

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

Ok good for them?

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

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

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

i dont know how this influences my development decisions

Maybe that's a point that needed reminding :)

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

(you, people*)

(devs)

or it justifies laziness

There's a balance to find

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

the intent was to find the balance

I doubt that's only what balance is about

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

because all is just a social problem

lol

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

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

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

And I'm out now

tħis discussion has lost all productivity

ok

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

Like BLINKING and forcibly scrolling all the way back there.

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

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

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

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

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

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

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'

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

i appreciate the layout

Can you share a screenshot maybe, plz? ✏

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

bear with me

I doubt diffs will please every kind of public though

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

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

pep.; ^

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

again, limitations of weechat there :p

Yeah

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?

The _example_ ?

The one that uses something that doesn't exist?

🤐️

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

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

Propose an edit for the spec :x

Last Spec Correction ✏

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

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