Allow read markers to go backwards

[nunoperalta]

Allow read markers to go backwards

[turt2live]

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]

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.