Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4052: Hiding read receipts UI in certain rooms #4052

Closed
wants to merge 3 commits into from
Closed

MSC4052: Hiding read receipts UI in certain rooms #4052

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a715395
MSC4052: Hiding client UI in bridged rooms
cloudrac3r Sep 6, 2023
1bb7c83
MSC4052: Add another use-case example
cloudrac3r Sep 6, 2023
4db2269
MSC4052: Refill lines to 80 characters
cloudrac3r Sep 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions proposals/4052-hiding-client-ui-in-certain-bridged-rooms.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# MSC4052: Hiding read receipts UI in certain rooms

Displaying read receipts is not relevant or useful in all kinds of rooms. This MSC proposes a hint for clients that they shouldn't display read receipts in the UI for certain rooms.

## Proposal

A new room state event `m.hide_ui` with state key `read_receipts` determines whether read receipts should be hidden in the UI. To opt-in to hiding read receipts, the event should contain `{"hidden": true}`. Other properties are ignored. If `hidden` is not `true` then read receipts are not hidden.

An example use-case is when rooms are bridged to other platforms but those platforms don't support all of Matrix's features. As a practical example, read receipts are not a feature on IRC. Any IRC rooms bridged with Matrix will show each user as only having read messages that they themselves sent. Implementing this proposal would make the behaviour consistent between Matrix users and bridged users.
cloudrac3r marked this conversation as resolved.
Show resolved Hide resolved

Another example use-case is for announcement rooms which may be read by thousands of users. Users probably don't care whether other users have read the latest update, so the read receipt UI is noise in these rooms. Hiding it would provide a better experience.

The `m.hide_ui` event is designed to be sent by a compatible appservice bridge when it manages a bridged room. It can also be sent manually for any reason.

In the future, this concept could be extended to hide other parts of the UI using other state keys. Sticking with IRC as an example, the bridge bot may ask clients to hide "add reaction" buttons, "create rich reply" buttons, "upload file" buttons and so on, if it knows that it cannot handle those events in a satisfactory way. The exact details are out of scope for MSC4052. MSC4052 only specifies hiding read receipts in the UI.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This specific use case sounds like an xy problem, better solved by msc3968

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please elaborate on how it is an XY problem?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a msc for discouraging feature usage, it's one written for hiding ui to discourage feature use.

msc3968 takes the other approach, specifying which features are encouraged/discouraged then letting clients prioritize/deprioritize/hide ui elements based on that

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I've been thinking about this a lot and I agree with you. I think MSC3968 is a better direction to take it. However, 3968 doesn't currently provide a way of disabling read receipts, since the author didn't think of that. Is it possible for me to collaborate on 3968 in a more significant way than asking the author to make changes in the comments?


## Potential issues

Since this flag applies to the entire room, users on the Matrix side of the bridge will not be able to see read receipts from other Matrix users, even when those read receipts are correct. See below.

## Alternatives

Rather than hiding all read receipts, it may be desirable to only hide read receipts of bridged users. However, this comes with its own issues: without a visible read receipt a particular user might not be perceived by others to be part of the room.

## Security considerations

The default power level required to send state events, including `m.hide_ui`, is PL 50. This should be fine for most rooms. PL 100 might be a better fit.

Not all clients will follow this spec, so read receipts might still be displayed. We may want clients to also send private read receipts (see MSC2285 which is merged) for rooms in this mode. Otherwise, users might not realise they are leaking what messages they've viewed.

## Unstable prefix

When unstable, the event type `chat.schildi.hide_ui` should be used instead. (The state key is still `read_receipts` and the content is still `{"hidden": true}`.)

## Implementations

* [SchildiChat (client)](https://github.com/SchildiChat/matrix-react-sdk/pull/18)
* [Out Of Your Element (bridge)](https://gitdab.com/cadence/out-of-your-element/commit/5e6bb0cd2edaa8c340b5f27d5ccfce622c22fc8e#diff-1712f73f1ef677367997f55e69a76b0cc2a2b425)