SS: Hook up notification counts #17546
Conversation
| highlight_count=0, | ||
| # TODO: What about notifications in threads? | ||
| notification_count=notif_counts.main_timeline.notify_count, | ||
| highlight_count=notif_counts.main_timeline.highlight_count, |
There was a problem hiding this comment.
Do we still need this PR given the latest from ElementX/Rust team is
unread counts sent from the server are indeed thrown away in the Rust SDK, since they can't be precisely computed b/o encryption
Although
I think they are used as a fallback
And we're not sure if the app even shows notification counts.
And we seem to agree that notification counts from the servers perspective seem pointless given encrypted rooms. Perhaps we should just be removing these fields?
There was a problem hiding this comment.
@erikjohnston asked for further clarification in an internal room on Friday but nothing has materialized yet.
There was a problem hiding this comment.
The topic came up again in an internal room. Here is a summary:
There was a strong feeling to get rid of them since there is no point in sending known bad data to clients. The highlight_count/notification_count won't be accurate or make sense in end-to-end encrypted (E2EE) rooms (the client needs to decrypt the messages to see what they actually are or if they mention the user). @stefanceriu and @ara4n also mentioned that even in unencrypted rooms, they are an approximation because the server doesn't know what the client can render. Not sure that I follow the point about unencrypted rooms as it seems like the push rules could align with whatever your client considers.
Product-wise, the Rust SDK ignores highlight_count/notification_count and the Element X apps don't have unread counts, only unread badges (product decision) even though WhatsApp/Telegram do have them.
For clients, that do want to show the unread count, the highlight_count/notification_count is useful for big public chat rooms. Otherwise, the client needs to spider the entire room (probably up to your read-receipt) to see if you're mentioned which feels inefficient. @ara4n was originally in favor of dropping these fields but now considers them useful to keep and clients should ignore them for E2EE encrypted rooms and just calculate it themselves by spidering on the client.
| notification_count=0, | ||
| highlight_count=0, | ||
| # TODO: What about notifications in threads? | ||
| notification_count=notif_counts.main_timeline.notify_count, |
There was a problem hiding this comment.
Can we make this field optional for encrypted rooms please? It's very likely to be inaccurate for such rooms. It's better to return nothing than an incorrect value I think.
No description provided.