-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Old reactions should be hidden when a message is edited. #10136
Comments
I imagine eventually we want the server to do this ... ? Although we don't have a precedent really for the server to insert more events into the timeline upon somebody sending an event... This wouldn't work for e2e... or would it? redacts is in unsigned ... Doing it client-side seems suboptimal as well ... you could not be aware of all edits ... send could fail ... you could be using a client that doesn't do this. Does it make sense to spend time to do this client-side in riot in the short term, given the above? |
I don't know that we necessarily want to be throwing reactions away ever, otherwise somebody can say somethign obnoxious, receive a lot of negative feedback, then just edit their message (to something equally obnoxious if they like) and wipe the slate clean. How tractable is it to have reactions key off the edit rather than the original message? (Understanding this is probably an invasive change to spec etc.) |
The idea of clearing reactions after an edit was proposed for the opposite scenario, I believe: to create social pressure for edits to die down once the message looks good, so that you can then collect reactions and the reactions senders can be assured that the message hasn't changed since they interacted with it. |
It does sound complex, to be honest:
|
Okay - I think there might be utility in exploring this more further down the road, but for now let's just have edits dispose of associated reactions. |
We've had a slightly confused conversation about this; most of the confusion stemmed from whether 'cleared' meant delete from the database or not. We (@jryans and I) are now in agreement that the data would not be deleted - it would only be hidden in the UI. If were were to proceed with this hiding-outdated-reactions feature, we would need to think about:
This sounds like a reasonable chunk of work, that is desirable to make the edits/reactions features work together without exposing edge cases for potential abuse. But it is probably not necessary for phase:2 |
If we do this thing, it should probably be added to the spec, so that all clients that implement reactions react to that last edit. Otherwise you'd react in some client, and it wouldn't show up in others. |
Deploying this change should be (somewhat) aligned across mobile and web, as they would stop showing each other reactions once a message is edited. Deploying this without the required changes in server-side bundling probably also doesn't make sense, as it will just break the server-side aggregation we already use. You could also argue that the server should reject reactions on events that are not the last edit, to avoid clients posting reactions that won't be shown elsewhere. So marking this as blocked until there is backend bandwidth to work on this. |
My proposal would be greying out, or otherwise marking, any reactions prior to the last redaction. |
I feel we've made the implicit product/design decision on this having not actioned it. If people feel strongly otherwise, please open a new issue with fresh information for reconsideration. |
No description provided.
The text was updated successfully, but these errors were encountered: