-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Move experimental features MSC3026, MSC3881, and MSC3967 to per-user flags #15345
base: develop
Are you sure you want to change the base?
Changes from all commits
fea933f
0d61d3d
1739ce6
4aea2de
4291c66
d3cc11d
ca3e15b
51769a9
f9e7a0a
842eb40
e5f33c5
15dd372
e53a8a5
e8c571b
aea7cbd
e156b84
7568c72
9155b82
2cb4182
a767f1c
b99dab3
86ec834
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Follow-up to adding experimental feature flags per-user (#15344) which moves experimental features MSC3026 (busy presence), MSC3881 (remotely toggle push notifications for another client), and MSC3967 (Do not require UIA when first uploading cross signing keys) from the experimental config to per-user flags. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -96,7 +96,7 @@ def on_GET(self, request: Request) -> Tuple[int, JsonDict]: | |
"io.element.e2ee_forced.private": self.e2ee_forced_private, | ||
"io.element.e2ee_forced.trusted_private": self.e2ee_forced_trusted_private, | ||
# Supports the busy presence state described in MSC3026. | ||
"org.matrix.msc3026.busy_presence": self.config.experimental.msc3026_enabled, | ||
"org.matrix.msc3026.busy_presence": True, | ||
Comment on lines
98
to
+99
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think this is really accurate -- don't we need to check this based on which user is requesting For example, a client might use this to enable UI allowing users to say they're busy. The user would then receive an unexpected error when attempting to use that feature. (Similar feedback to below for MSC3881) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm I think you're right - it would be True or False based on either the config or whether the feature is enabled in the DB, but how would that be checked here per user? Is it possible to extract the username from the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nevermind I figured it out. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well I thought I figured it out but since There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The only thing I can think of is to make it optionally accept authentication and ask the clients to pretty please change their request code so it sends auth for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, I wonder if we should start putting unstable features in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I think at some point I was told to prefer There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It's in the spec: https://spec.matrix.org/v1.6/client-server-api/#capabilities-negotiation
Given this it seems like Oliver's suggestion is the way to go? Any other suggestions I should consider? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'd probably double check if clients would be willing to do this first? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. MSC4026 was written for this, it has now passed FCP. |
||
# Supports receiving private read receipts as per MSC2285 | ||
"org.matrix.msc2285.stable": True, # TODO: Remove when MSC2285 becomes a part of the spec | ||
# Supports filtering of /publicRooms by room type as per MSC3827 | ||
|
@@ -115,7 +115,7 @@ def on_GET(self, request: Request) -> Tuple[int, JsonDict]: | |
# Adds support for login token requests as per MSC3882 | ||
"org.matrix.msc3882": self.config.experimental.msc3882_enabled, | ||
# Adds support for remotely enabling/disabling pushers, as per MSC3881 | ||
"org.matrix.msc3881": self.config.experimental.msc3881_enabled, | ||
"org.matrix.msc3881": True, | ||
# Adds support for filtering /messages by event relation. | ||
"org.matrix.msc3874": self.config.experimental.msc3874_enabled, | ||
# Adds support for simple HTTP rendezvous as per MSC3886 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was moved to the experimental features database class to avoid a circular import that occurred when using this type in the presence handler.