MSC2867: Marking rooms as unread

[Bubu]

Rendered

Implementations:

• Famedly-SDK + FluffyChat
• SchildiChat-Android
• SchildiChat-Web/Desktop
• Element Web/Desktop
• Ruma (used by Element X iOS / Android)

FCP tickyboxes

[tulir]

This has been implemented in the Beeper app

[su-ex]

Next SchildiChat Web/Desktop release will have this too.

[dbkr]

More implementations:

• Element Web/Desktop: https://github.com/matrix-org/matrix-react-sdk/pull/12254
• Ruma (used by Element X iOS / Android): https://github.com/ruma/ruma/pull/1721

[turt2live]

@mscbot fcp merge

[mscbot]

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

• [x] @clokep
• [x] @dbkr
• [x] @uhoreg
• [x] @turt2live
• [x] @ara4n
• [x] @anoadragon453
• [x] @richvdh
• [x] @tulir
• [ ] @erikjohnston
• [x] @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[dbkr]

@Bubu are you still shepherding this MSC or would it be better if someone else took over?

[Bubu]

@Bubu are you still shepherding this MSC or would it be better if someone else took over?

@dbkr I can make the necessary (hopefully final :)) adjustments now that this is no longer lying dormant.

[Bubu]

I added the alternative suggestion from Travis as well as an explicit mention that threads are not supported in this MSC.

There's a bit of an open discussion point here still: https://github.com/matrix-org/matrix-spec-proposals/pull/2867#discussion_r1600811614 I think the current text should be clear enough but if anyone has a concrete suggestion to further clarify this, we can also still include that.

[alphapapa]

I realize that this is a few years old, but seeing it in the recent TWIM is the first I've noticed it.

I can't say I'm really in favor of this. As mentioned in the alternatives section, we already have unread markers in rooms. In Ement.el, we allow the user to move the unread marker to any position, which effectively marks the room unread at that position, allowing the user to return to that position later. Although we currently use the server's unread count to determine whether a room is "unread," in the past we also considered the position of the unread marker, and we could easily do so again, effectively implementing this feature without needing to add more room-data fields.

This proposal would seem to complicate the API for clients to determine whether a room is "unread". It would also seem to require the server to update that field accordingly (otherwise this field could conflict with other "unread status" data). And in that way, it would also seem to further complicate the algorithm for clients to implement to determine whether a room is "unread."

As I described, It seems that the tools for implementing this already exist in the spec: allow the user to set the read marker, and compare it to the last message event in a room (if it's after the last message event, the room is read; otherwise, it's unread). This would require no change to the spec nor servers, and minimal changes to clients.

Given that, this proposal seems like bloating the spec. Therefore, I respectfully oppose this proposal.

[Bubu]

@alphapapa please use the comment feature on the diff, so people can reply without adding more to-level comments.

we allow the user to move the unread marker to any position,

This is the m.fully_read marker mentioned in the alternatives? How does this translate into a simple "mark as unread button" for a room that many messengers have? Can you reply to the downsides mentioned for that approach there?

[alphapapa]

@alphapapa please use the comment feature on the diff, so people can reply without adding more to-level comments.

I'm afraid that I object to the proposal as a whole, not to some lines in the diff.

My chief objection, again, is that there are already multiple criteria to apply to determine whether a room is "unread," and this proposal would make that more complicated, making a new criteria which may appear to conflict with existing ones, and bloat the spec by adding new metadata to offer a feature which could be offered using existing metadata.

we allow the user to move the unread marker to any position,

This is the m.fully_read marker mentioned in the alternatives? How does this translate into a simple "mark as unread button" for a room that many messengers have? Can you reply to the downsides mentioned for that approach there?

I don't understand your question. I explained how it could work. Do you have a specific question about it?

Can you reply to the downsides mentioned for that approach there?

Sure:

When trying to work around this, by setting the marked at a special location like the room creation event then we completely lose the the user's actual read position in a room when using this feature.

I think the non-fully-read marker would still work. In my client, both markers work (not that it's an easy concept for the user to grok).

It makes it harder to distinguish between rooms which happen to have unread messages that you don't necessarily care about and rooms which were manually marked as such and thus should be shown much more prominently.

That seems true. However, I would argue that, for that purpose, this proposal conflates two things: "unread" and "need to deal with something here later." Other systems, such as Slack, offer "save for later" and "remind me later" features that don't conflate "unread" with "task" or "remember this." Instead, they are offered as distinct actions in menus and distinct statuses, as well as distinct lists of unread channels and saved-for-later events.

So I would suggest, for that purpose, that a new proposal be written to offer a way to mark certain event IDs as "saved for later," "bookmarked," "to-do," etc. without having anything to do with "unread" status. The marked-for-later events could be displayed by a client when the user views the room, regardless of what other events have arrived since then. They could also be displayed in a global saved-for-later list across rooms.

Since message events can already be linked to by URL, this should be a natural way to remind the user about certain events in a room that are significant to the user. Also, it would effectively mirror the relevant features of Slack, which seems like a good idea anyway, if Matrix is to compete with it.

In contrast with this proposal, this alternative would enable more powerful features that would be worth "bloating the spec" for. ;)

[richvdh]

I'm afraid that I object to the proposal as a whole, not to some lines in the diff.

Doesn't matter. Github lets you comment on a file as a whole. Or just comment on the title.

[mscbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[tulir]

Spec PR: https://github.com/matrix-org/matrix-spec/pull/1895

[turt2live]

Merged 🎉