Add ability to mark messages unread

[nunoperalta]

This is being discussed here for Riot:
vector-im/riot-web#4406

The only blocker at the moment for Riot is that synapse only ever let's the "unread" pointer move forward.

This needs an MSC so that it's in the spec and not specific to riot/synapse.

Slack, Facebook Messenger, WhatsApp, Skype, Linked In, Signal, and pretty much every other email/chat client I know, have Mark as Unread, and some of them (like Skype and Slack) allow to choose which message to move the unread pointer to.

Thank you.

[colans]

Just to correct the description above, Signal does not yet support this either.

[neilisfragile]

Agreed that the way to make progress here is to propose an MSC

[MurzNN]

Why this feature can't be implemented using current m.fully_read marker?

Matrix client will send read_markers event to room with event id, selected by user:

{
  "m.fully_read": "$needed_event_id:domain.com",
  "m.read": "$needed_event_id:domain.com"
}

and read marker will move back to needed position! Not?

[anoadragon453]

Why this feature can't be implemented using current m.fully_read marker?

Matrix client will send read_markers event to room with event id, selected by user:

{
  "m.fully_read": "$needed_event_id:domain.com",
  "m.read": "$needed_event_id:domain.com"
}

and read marker will move back to needed position! Not?

Tried testing this but my homeserver claimed my restclient closed the connection too quickly, whereas restclient got a 200. So... maybe?

[jryans]

At the moment, Synapse appears to only move the read marker forward. (It might return a 200 even if not updated, perhaps a bug...)

synapse/synapse/handlers/read_marker.py

Lines 51 to 55 in 97bf307

	if existing_read_marker:
	# Only update if the new marker is ahead in the stream
	should_update = yield self.store.is_event_after(
	event_id, existing_read_marker["event_id"]
	)

I can't find specific spec text that says that receipts and markers only move forward, but it seems somewhat implied by the current definition of a read marker.

Given all this, it does seem like an MSC would be best.

[anoadragon453]

Thanks for investigating @jryans. You're right in that the spec's definition is currently a little vague, and an MSC is a good place to both update and get feedback on whether it's the right direction to take.

Will make one and take the discussion there, thanks!

[MurzNN]

We can continue not allow m.read markers to jump backward, because, as I understand, they used for render public read markers in room, and allow to jump backward only m.fully_read marker, for use it only for personal needs?

[anoadragon453]

We can continue not allow m.read markers to jump backward, because, as I understand, they used for render public read markers in room, and allow to jump backward only m.fully_read marker, for use it only for personal needs?

Good point, we don't want to leak to people that we're marking messages as unread. I wonder how easy they are to uncouple...

[nunoperalta]

This is just my opinion, but honestly, I WISH other people could know when I mark their message unread, on Whatsapp and everywhere else.

The reason is that many times I see the message, but mark as unread so that I can come back to it later.
However, other people not seeing that I marked it as unread again will think I purely ignored them, when I'm actually NOT ignoring them and want to come back to them later - hence I marked as unread.

[anoadragon453]

Hrm, true. Perhaps then we can be generic enough such that clients can choose to move the public read marker or not.

[nunoperalta]

It could be a setting, I guess...

Or two buttons: "Mark as Unread (Private)" / "Mark as Unread (Disclose)"

[MurzNN]

Ideally will be good to see both info on sender side - when user receive message (act on notification and opens message), and fully read them (with ability to mark as unread on receiver side if he has no time to read now).

[brainscar]

At the moment, Synapse appears to only move the read marker forward. (It might return a 200 even if not updated, perhaps a bug...)

@jryans wow I literally came to this repo to report this exact bug. Do you know if there's a bug report for it yet? Basically it's exactly how you describe it. The marker doesn't update in riot but it's reported as 200.

[jryans]

@jryans wow I literally came to this repo to report this exact bug. Do you know if there's a bug report for it yet? Basically it's exactly how you describe it. The marker doesn't update in riot but it's reported as 200.

I am not aware of one so far... Please feel free to file one, I would assume here in the Synapse repo.

[anoadragon453]

We 200 the request as the state afterwards remains the same. The spec does not currently specify any required error codes other than 200/429: https://matrix.org/docs/spec/client_server/unstable#post-matrix-client-r0-rooms-roomid-read-markers

[nunoperalta]

Any update on this?

[anoadragon453]

Not for this problem particularly, but matrix-org/matrix-spec-proposals#2285 may allow a client to provide the desired behaviour.

[turt2live]

2285 is unrelated to this.

[nunoperalta]

Any update on this?
This has been asked already since 2017, in element-hq/element-meta#347 ...
This is one of the most basic features a Chat system like this needs to have.
Thank you.

[NoaJou]

As OP says, this is quite a basic feature which should be added. Would love to see if this can be implemented in future versions of the app.

[richvdh]

dup element-hq/element-web#2632

[colans]

@richvdh Hang on a second though. I agree that it makes sense to implement this on the server side, but the client still need to add some functionality in order to take advantage of it, specifically it has to allow the user to determine where to stick the marker.

So wouldn't it make sense to postpone this issue on the server one, and then unpostpone it when that one is complete? But let's keep it open as there's still work to do here (unless I'm missing something).

[richvdh]

I'm not following what you're saying, but on closer inspection, this is unrelated to element-hq/element-web#2632.