Skip to content
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

Ability to mark messages as unread #612

Open
Half-Shot opened this issue Apr 20, 2020 · 5 comments
Open

Ability to mark messages as unread #612

Half-Shot opened this issue Apr 20, 2020 · 5 comments
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration

Comments

@Half-Shot
Copy link
Contributor

In a similar vein to email, it would be good to mark a message you plan to go back to as unread so you can focus on other things. Currently the way people work around this is read messages from their notifications and avoid clicking on the room to clear the unread marker. Obviously, this means the user cannot interact with the room in any way in the meantime, aside from it being intuitive.

The simple solution I would propose is a room-account-data item, which simply lists event_ids in an array. When marking a message as read, the eventID is entered into the array. Clients should take this into account and increase the rooms unread counter by this number, as well as highlighting the message in some way.

The eventID should be removed from the array once the user has indicated that the message has been read.

@turt2live
Copy link
Member

turt2live commented Apr 20, 2020

https://github.com/vector-im/riot-web/issues/4406 appears to be the canonical issue for discussing this, so preferably would want to keep the conversation there. There's also matrix-org/synapse#2632 matrix-org/synapse#5601 to track Synapse's implementation.

Will leave this open to track the spec side though. Definitely needs an MSC.

@turt2live turt2live added A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration labels Apr 20, 2020
@Half-Shot
Copy link
Contributor Author

ta for the links

@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
@srdjan-catalyst
Copy link

Would it be acceptable then to have an additional m.fully_read_force or similar for clients to send in case we deliberately want to push m.fully_read marker backwards? That way standard flow is not affected, but we can cater for a deliberate action?

@turt2live
Copy link
Member

The fully read marker doesn't affect unread status, unfortunately. The read receipt does, which cannot (and should not) be rolled backwards.

@srdjan-catalyst
Copy link

Thanks Travis, this really is a different issue. The idea here is to force fully read marker back, which would allow clients to jump back. I'll create a separate issue, unless you have another suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration
Projects
None yet
Development

No branches or pull requests

3 participants