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

Allow read markers to go backwards #1893

Open
nunoperalta opened this issue Jul 1, 2024 · 2 comments
Open

Allow read markers to go backwards #1893

nunoperalta opened this issue Jul 1, 2024 · 2 comments
Labels
A-Push improvement An idea/future MSC for the spec

Comments

@nunoperalta
Copy link

nunoperalta commented Jul 1, 2024

Suggestion
In order for front-ends to be able to implement "Mark as Unread from this message" (like it's possible in Skype), Matrix needs to allow the read marker to go backwards.

See issue in Element: element-hq/element-meta#347

See this comment (and the following one): element-hq/element-meta#347 (comment)

Issue raised for Element for this specific feature: element-hq/element-meta#2465

Thank you!

@turt2live
Copy link
Member

My current opinion is we should separate read receipts from notifications instead of allowing them go backwards. For reasons discussed on MSC2867, going backwards is way more complicated.

@alphapapa
Copy link

alphapapa commented Jul 10, 2024

FWIW, Ement.el allows the user to set the read markers in a room to any event (what the server or other clients do with that, notwithstanding).

IMHO, the ability to mark a room as "unread from here" is important functionality that is missing in Matrix (officially, anyway).

As well, while I understand the motivation for #1895 and why it has been moved forward, I'm concerned that it overlaps with this proposed functionality in a way that will ultimately make supporting this proposed functionality more complicated than necessary.

IOW, how would it make sense to both a) mark a room as unread, and b) mark a room as "unread from here"? ISTM that, rather than marking a room as simply "unread," such marking should include an optional event ID, so that a room could be marked as either "simply unread" (without regard to a specific event) or "unread from here" (with regard to a specific event).

But if these features are implemented separately, imagine how much more complicated the logic will have to be on clients: checking multiple per-room data structures, reconciling potentially conflicting values (e.g. a room marked as "unread from here" but not "unread"), or other combinations which could result from using clients with varying Matrix version support.

I encourage the Matrix developers to consolidate these ideas into a single spec proposal that will address them both in a unified, simple way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Push improvement An idea/future MSC for the spec
Projects
None yet
Development

No branches or pull requests

3 participants