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.

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

MSC4076: Let E2EE clients calculate app & E2EE-room badge counts themselves #4076

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

ara4n
Copy link
Member

@ara4n ara4n commented Nov 12, 2023

This gives a way for E2EE-aware clients to accurately maintain their own app badge counts, rather than having the server incorrectly override them based on partial information.

Solves element-hq/element-x-ios#2993 (and is a full soln to element-hq/element-x-ios#2066)

Rendered

@turt2live turt2live added push proposal A matrix spec change proposal client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Nov 12, 2023
@@ -0,0 +1,127 @@
# MSC4076: Let E2EE clients calculate app badge counts themselves

Choose a reason for hiding this comment

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

I fail to see how you couldn't already calculate them clientside?

Copy link
Member

Choose a reason for hiding this comment

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

Agreed. TBH I've only skimmed this, but I don't entirely follow why this MSC is necessary for clients to calculate their own badge counts.

(You might justifiably argue that the counts should be removed on the grounds of redundancy, but that doesn't appear to be what this MSC is saying?)

Copy link
Member Author

Choose a reason for hiding this comment

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

You can and should calculate them clientside. However, the server currently overrides them and there is no way to stop the server from doing that, prior to this MSC.

Copy link
Contributor

Choose a reason for hiding this comment

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

Clearly some crucial information is missing here? Since to my understanding you can just make either fully ignore the server response and do it without it or have an if case for only e2ee rooms. I don't see how that currently impossible? The server isn't demanding a particular execution path on the client obviously?

Copy link
Member

Choose a reason for hiding this comment

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

However, the server currently overrides them and there is no way to stop the server from doing that, prior to this MSC.

Is this done at the OS-level and the server needs to not include that information to not fight the client doing it?

Copy link
Member Author

Choose a reason for hiding this comment

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

Is this done at the OS-level and the server needs to not include that information to not fight the client doing it?

yes.

Copy link
Member Author

Choose a reason for hiding this comment

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

(this is why literally the first sentence in the proposal is explaining this behaviour and linking to the apple documentation that describes it)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal push
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants