Self-read markers should be synchronised across clients

[ara4n]

Currently we calculate RMs locally by remembering the oldest place where there are unread messages from that client's perspective. We should persist this our per-room account_data so that we can synchronise it across multiple clients (and add it to ze spec).

[ara4n]

Okay, this has been blocked on a design for the behaviour and revisiting the UX.

I've just tried to do this in: https://docs.google.com/document/d/1f9UJdoB7EG7SaUTpumpqOyV6PvVlZnTi8mLGNkNp6n4/edit#

Thoughts welcome from @dbkr and all on which solution to adopt. @giomfo - this should unblock you on iOS hopefully once resolved.

[KitsuneRal]

As a prominent client application author :) I think I'll share my view on this.

I'd personally vote for option 1 because it's admittedly easy to incorporate in Quaternion (which doesn't handle account_data atm). Having said that, I understand that option 2 is probably more consistent from the API perspective: RRs are ephemeral by definition now, while RM is rather a part of my personal unshared state of the room. Option 4 the coolest: I suppose that RRs in Vector/Riot can stay as they are with this option, while providing additional info in the context menu or somewhere; but AFAIU, it requires more substantial changes to the API and to the semantics of RRs (de-ephemerisation?).

Finally, option 5 is, to my mind, orthogonal to RR/RM stuff, which is by definition more range-based. You won't make anyone individually mark a certain instant message as read, anyway; and any kind of automation implies grouping, unless we're talking about texting/SMS/email gateway and the respective kind of user interaction - and this case can be nicely covered by scaled-down option 4.

[richvdh]

If we're rewriting this stuff, I rather wonder if we should go the whole hog and have a per-message read flag, even if that is only shared to the clients in a limited fashion - ie option 5 from the google doc. It is obviously a lot more data to handle, but it seems to make a whole class of problems around how we handle the ranges go away.

[lukebarnard1]

These are some notes are just here for my own sanity:

@erikjohnston pointed out that currently, Riot will handle updating of the read marker locally. I was under the impression that its location was bound to the most recent read receipt send for the user. It's empirically not, and it also shouldn't be because reading the most recent message !== reading all messages since the message we didn't read that's furthest in the past.

[lukebarnard1]

See matrix-org/matrix-react-sdk#805 for things that were done following discussion.

[remram44]

This google doc is not publicly readable.

[richvdh]

@remram44: does it work now?

[remram44]

Yes, it is fixed

[lukebarnard1]

As of matrix-org/matrix-react-sdk#805, I think this is resolved.