Conversation
ajbura
changed the title
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
|
|
||
| Currently, messages are pinned using the `m.room.pinned_events` state event (see [specification](https://spec.matrix.org/v1.12/client-server-api/#mroompinned_events)). However, when new messages are pinned by the super user, other users can not detect newly pinned messages. | ||
|
|
||
| It primarily happen because `m.room.pinned_events` does not have any information that can help users detect the change. Resulting in users having no visual clues about newly pinned message. To cope with it they either have to mentally remember the total number of pinned message or discovery of `m.room.pinned_events` state event in clients timeline reminds them to check for possibly new pinned messages. |
There was a problem hiding this comment.
Why is prev_content not sufficient?
There was a problem hiding this comment.
Because prev_content doesn't have info regarding the read status of events. Also it contain content of immediate previous whereas new pinned events entry can span multiple events.
| It primarily happen because `m.room.pinned_events` does not have any information that can help users detect the change. | ||
| Resulting in users having no visual clues about newly pinned message. To cope with it they either have to mentally | ||
| remember the total number of pinned message or discovery of `m.room.pinned_events` state event in clients timeline | ||
| reminds them to check for possibly new pinned messages. |
There was a problem hiding this comment.
I generally agree with the problem statement but not sure if a solution really needs one more read marker. The existing m.read marker applies to message and state events alike so in theory a client could (should?) check whether any (and which, in fact) m.room.pinned_events state events are newer than m.read. The same problem exists with m.room.topic, for example: without being in a room, you cannot tell whether the room topic has changed unless the client marks the room as unread when a new m.room.topic event arrives.
When it comes to the conditions to mark the room as unread, these are effectively defined by push rules. If you add a push rule that says to notify (not highlight) on new m.room.pinned_events the respective room will end up being marked as updated. I encourage the author of this MSC to explore this direction; adding a push rule is easier for the spec as well as for clients.
4 participants
Rendered