MSC1796: improved e2e notifications #1796
Conversation
| @@ -0,0 +1,125 @@ | |||
| # Proposal for improving notifications for E2E encrypted rooms | |||
There was a problem hiding this comment.
leaving this here so I don't forget later:
My overall concern with this proposal is that it proposes that notifications still be handled server-side. Given the direction of e2e and extensible events, I continue to be convinced that server-side unread/notification counts are not the right approach. Instead, clients should be responsible for tracking this information as they are the best part of the stack to determine what the numbers should be.
Doing client-side notifications/unread counts does mean that clients are more complicated and duplicating efforts, however the server cannot possibly be expected to be as reliable anymore. I think it's better worth our time making it easier for clients to calculate counts and set expectations for how they work rather than continue to try and keep this server-side.
There was a problem hiding this comment.
more complicated and duplicating effort
That's not really the point @ara4n is making though. The point is that in the best case it just chews bandwidth and CPU (and hence battery). In the worst case, it is imperfect (read: misses notifications!!) because of the need to resync potentially large amounts of data which isn't feasible to do currently. This seems like a good use case for the server to do this work to me. Yes, there are privacy concerns, but it opens no new security fronts given the amount of metadata already being passed through the server's hands in the clear.
Co-Authored-By: ara4n <matthew@arasphere.net>
|
Should this be closed in favour of #3952 ? |
|
@ara4n I believe you mentioned somewhere that this should indeed be closed. If this is accurate, could it be closed please? |
|
alternatively, @mscbot fcp close |
|
Team member @richvdh has proposed to close this. The next step is review by the rest of the tagged people: Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
While I am not to say moth foaming that is the approach best or not, I would want to point out, maybe in more general, that is the fact that "other meta already leaks information" the grounds to add another one? instead of thinking hot to make existing metadata leak less? :P |
|
This MSC is set to be closed at the end of FCP, not merged, fwiw. We're of the opinion that #3952 (which respects metadata a bit more) is a better option. |
|
The final comment period, with a disposition to close, as per the review above, is now complete. |
Rendered
FCP tickyboxes