Hidden Read Receipts

[TheBlueMatt]

I know its not stable, but is it possible to get hidden read receipt reports (MSC2285) support in Cinny?

Its supported in element behind a feature flag, and apparently supported in matrix-js-sdk with the hidden flag on sendReadReceipt. Its also possible to enable it only based on the /version response from the homeserver, which mentions msc2885 by name.

[mjarr]

It's stable now. Both Element and Synapse support it.

[ajbura]

I have reviewed #1109 with

This looks fine. But I am still not sure of if we want people to hide their read receipt but still able to see what others are reading. I believe it will change persons behaviour of being a part of community to being a spy like in community.

I would like to know what other has to think about this feature?

• Should we allow hidden read receipt with able to see other read receipt
• Should we allow hidden read receipt without able to see other read receipt
• Or something else?

[vaguerant]

I'm not a dev, just a user of hidden read receipts on other clients. Personally, I don't want anybody to see my read receipts and I don't want to see theirs either, so I have both disabled already. My use case would probably be satisfied by Cinny no matter what decision you end up making, so I think I'm relatively unbiased.

At this point, I realize I'm going to say "hidden read receipts" a lot in this comment, so from here on I'll refer to them as HRRs.

On the one hand, element-web doesn't enforce any restrictions on HRR users and I suspect the vast majority of HRR users are on element-web (it's worth noting that the mobile versions of Element don't support hidden read receipts), so unless the overwhelming majority of those users move to Cinny, it will always be the case that most HRR users are on a client where they can see other users' read receipts. In some ways, this might make Cinny's decision academic: what Cinny does and what the Matrix community in general does are different things.

On the other hand, it's a fairly new and quietly-introduced feature in the scheme of things. HRRs are not well-supported currently (I'm only aware of element-web for desktop and the alpha client Syphon on mobile), which likely means a lot of users are sharing their read receipts with no idea:

1. that they could be hiding them, and
2. that other users already are.

In an ideal world, all clients would have support for HRRs, and as long as users are well-informed (!), they'd be able to make the decision of whether they wish to share their read receipts, knowing that some users will not share theirs back. But that's not the current situation.

If I was looking for a compromise solution, I'd suggest temporarily disabling all display of read receipts when a user is hiding theirs. Eventually, once HRRs have been implemented into more Matrix clients and awareness of them has grown, the Matrix community hopefully reaches a point where the majority of users know about and run clients which support HRRs, and if they continue to share their read receipts, it's an informed decision understanding that not all users reciprocate. At that point, I feel it'd be fine to re-enable the viewing of read receipts by HRR users in Cinny, once you know people are sharing them willingly.

Personally, the one option I think would be wrong is permanently disabling read receipt viewing for HRR users. This would remove the opportunity for (hypothetical?) users who don't have privacy concerns to share their read receipts to Cinny users who hide theirs. It's not my attitude, but I imagine there are users out there who are content to share their read receipts while respecting the privacy of those who choose not to.

tl;dr: I think the two most sensible courses of action would be:

1. temporarily disable read receipt viewing and revisit the decision periodically as awareness of hidden read receipts in the Matrix community grows, or
2. follow element-web's "standard" and just allow read receipt viewing regardless of personal setting

I don't really have strong feelings about either option. If all Matrix clients agreed to follow one option, I think option 1 would be stronger, but if only one client is doing it, I'm not sure how much benefit it really provides to the wider Matrix community. Option 2's main advantage is that it doesn't create extra work down the line, since implementing option 1 really means implementing option 2 in the future.

Sorry about the long comment!

[kfiven]

IMO the sensible way would be how Whatsapp deals with it. If I disable sending my read receipt, I shouldn't be able to see others.

Otherwise people will just turn off their read receipts but will keep watching others. That's really bad at so many levels.

I know we can't fix this problem just alone with Cinny but at least we shouldn't encourage this behavior.

[siddhpant]

I'd say just follow the standard. The "spy" like behaviour may be off-putting, but that is an opinion on what the protocol standard enforces.

A client's main job is to conform to the protocols. Say, major clients enforced two-way blocking. Then someone else can fork/make another client which does away with it, since the protocol allows for it.

[ChewingBever]

Although I do think that turning both on or off at the same time is best, I do agree that there's no real point in not allowing it if the spec supports it. Therefore, I suggest the following:

• Enable read receipts (both ways) by default
• Add a "Disable Read Receipts" setting, which disables both sending and receiving read receipts
• If the above setting is checked, show/enable another check mark that explicitely enables receiving read receipts, while not sending them

This way, users are still encouraged to disable both at the same time, but the option is there as to support the full spec.

[ajbura]

A client's main job is to conform to the protocols. Say, major clients enforced two-way blocking. Then someone else can fork/make another client which does away with it, since the protocol allows for it.

I don't think a client should just do what protocol do. A client job is to give a good experience to its users. For example custom emojis and sticker is not in protocol but we implement them for same reason.

Just hiding sending receipt have high tendency that people will just turn them off result on negative effect on read-receipt as a feature. I think we should maintain a give & take in both sending/hiding read receipt. Aligning either side will hurt other experience.

[tezlm]

I agree with having a "disable read receipts" option. For me, I don't want to send or receive read receipts at all. I like being able to read and reply to messages when I feel like it, and read receipts put pressure against that.

[siddhpant]

I don't think a client should just do what protocol do. A client job is to give a good experience to its users.

This is a slippery slope with no end, which will result in non-standard implementation and potentially standard / protocol forking. xkcd 927.

For example custom emojis and sticker is not in protocol but we implement them for same reason.

That is an additional feature, which is different from disallowing something allowable by protocol, and thus not conforming to the spec.

Just hiding sending receipt have high tendency that people will just turn them off result on negative effect on read-receipt as a feature. I think we should maintain a give & take in both sending/hiding read receipt. Aligning either side will hurt other experience.

As mentioned earlier, that is a domain of standard / spec and should be dealt with there. Otherwise there is no point in making a "standard" if people are going to do what they like.

We can do something like what @ChewingBever said. Maybe the extra option can be added in some global "Additional settings" page to make it more opaque.

[Hydroidev]

I'm not a huge fan of read receipts in general so the most important thing to me is that the functionality for hidden read receipts is added sooner rather than later regardless of whether I can see others' or not.

As far as which one is better to do, I think that ultimately the option to view others' read receipts regardless of the status of your own is important; in a naive sense, if a user is not using hidden read receipts then they intend for that information to be viewed. That's obviously complicated by the fact that hidden receipts are not default in Element, not well supported in other clients, nor particularly well-known as far as I am aware. In that sense, I might tend to agree with @vaguerant here that going with "hiding others' if your own are hidden" is a good temporary option that can be refined at a later date. It shows a certain respect for the situation that some might not realise they can turn them off (or don't even have the option in their client). But I'd then also recommend @ChewingBever 's solution to broadly encourage the behaviour without forcing it on potential edge cases where some user is fully aware they are sending read receipts and wants them to be viewed.

To summarise, I think implementing "hide others' if yours are hidden" is probably the better option initially just so Cinny supports hidden read receipts at all; then add @ChewingBever 's suggestion if there's a good way to do so. The discussion and possibility of re-enabling 'spy' functionality (as the default) should then remain open over time (potentially in another issue dedicated to showing receipts while one's own are hidden) as the functionality matures across the ecosystem.

[ajbura]

This is a slippery slope with no end, which will result in non-standard implementation and potentially standard / protocol forking. xkcd 927.

From my perspective non-standard implementation of protocol is not a problem but a diverse offering different clients have to people using it. Otherwise there is no point in building same app as other.

Also our current implementation of read-receipt is a lot different from something like element.

[ajbura]

Spec actually does not tell client how to show information(with some specific instance where it does) in it's interface so we are not breaking any spec and instead gathering feedback on the taste of implementation.

[kfiven]

This is a slippery slope with no end, which will result in non-standard implementation and potentially standard / protocol forking. xkcd 927.

Spec just offers recommendation at technical level. How client developers use those technical standard recommendation is up to them. As long the feature is technically correct it's following spec.

If spec started to offer the steps to implement a feature and how it should behave then all the clients will be copycat and nowhere in spec it says when you implement private read reciepts it should be like this or like that, that's upto us to use the technical info as per our needs.

About the feature, Whatsapp is the perfect example and quite successfull as well. We also need to keep in mind, there's are DM conversation in matrix as well.

[ajbura]

About the feature, Whatsapp is the perfect example and quite successfull as well. We also need to keep in mind, there's are DM conversation in matrix as well.

I am agree with this choice.

[siddhpant]

Let me be clear, I'm not against what is being said and I agree with it (that the blocking should go both ways), that is the established convention and courtesy.

But since other clients do not and will not necessarily honour it (since the spec allows for it), there should be an option to do the same.

I know the spec doesn't provide a mandate for two different flags or disabling two way. But since it is possible it should be allowed (albeit in a non-straightforward way), as to not force or have only Cinny users reciprocate.

If spec started to offer the steps to implement a feature and how it should behave then all the clients will be copycat

I disagree. As an extreme example, IEEE provides a standard detailing how communication should be done, that doesn't mean every product in the world is a copycat.

[nulldg]

i refuse to use cinny until i can disable sending read receipts like i can on other clients.