MSC4052: Hiding read receipts UI in certain rooms #4052
Conversation
cloudrac3r
changed the title
turt2live
added
proposal
|
|
||
| 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. |
There was a problem hiding this comment.
This specific use case sounds like an xy problem, better solved by msc3968
There was a problem hiding this comment.
Could you please elaborate on how it is an XY problem?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Thank you everybody for the feedback. I will try to collaborate on #3968 to get read receipts in there instead. |
turt2live
added
the
obsolete
Rendered
Signed-off-by: Cadence Ember cadence@disroot.org