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 all 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
72 changes: 72 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,72 @@
# 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.
Comment on lines +9 to +13
Copy link
Member

Choose a reason for hiding this comment

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

My drive-by take on this is that this is probably better handled by having a state event, say m.room.features contain a dictionary of supported features in the room; read_receipts being one of them.

A room then created by an IRC bridge would set the read_receipt feature to false, and clients could adjust their UI accordingly.

Copy link
Author

@cloudrac3r cloudrac3r Sep 11, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

by having a state event...contain a dictionary of supported features

I thought about this at the time, but I decided having a separate state key for each feature would work better, to avoid a similar hassle to how difficult it is to update power levels.

For example, to update power levels currently, one has to fetch the current power levels state, make changes to it in memory, and then set that modified dictionary as the state: https://github.com/matrix-org/matrix-appservice-bridge/blob/2334b0bae28a285a767fe7244dad59f5a5963037/src/components/intent.ts#L352 While this works, it is hard to read and prone to bugs.

It's also a similar problem to updating m.direct in account data, which also requires one to fetch the existing event first and modify it so that they don't accidentally erase all of the existing data.

I can bypass that problem by having each event in a separate state key. Then to hide or show a particular feature, I can unconditionally send a state event of {"hidden": true} without being concerned about what was already there.

Copy link
Member

Choose a reason for hiding this comment

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

I see, and that makes sense. I suppose my main point was to eliminate the "UI" wording in the state event. So we could still use individual state keys for each feature, but the type would be m.room.feature (now singular), instead of m.hide_ui.


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.

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.

## 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)