Move experimental features MSC3026, MSC3881, and MSC3967 to per-user flags #15345
Conversation
H-Shay
force-pushed
the
shay/experimental_flags_part_2
branch
3 times, most recently
from
d8e9080
to
19e26c5
Compare
…eys) from config to per-user flag
H-Shay
force-pushed
the
shay/experimental_flags_part_2
branch
from
19e26c5
to
15dd372
Compare
H-Shay
changed the title
H-Shay
force-pushed
the
shay/experimental_flags_part_2
branch
from
73cf3c3
to
e8c571b
Compare
| # Supports the busy presence state described in MSC3026. | ||
| "org.matrix.msc3026.busy_presence": self.config.experimental.msc3026_enabled, | ||
| "org.matrix.msc3026.busy_presence": True, |
There was a problem hiding this comment.
I don't think this is really accurate -- don't we need to check this based on which user is requesting /versions?
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.
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 GET request to /versions (my suspicion is no?)
There was a problem hiding this comment.
Nevermind I figured it out.
There was a problem hiding this comment.
Well I thought I figured it out but since /versions doesn't require authentication there's no access token to extract the user id from. Is there a way to figure out the user id from a request that doesn't require authentication? If not, what's the best way to handle what /versions should return here if we can't determine the user (and thus cannot check if it is enabled per user)?
There was a problem hiding this comment.
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 /versions if they want to use unstable features... :/
There was a problem hiding this comment.
Hmm, I wonder if we should start putting unstable features in /capabilities API (which is authed) instead?
There was a problem hiding this comment.
Hmm, I wonder if we should start putting unstable features in
/capabilitiesAPI (which is authed) instead?
I think at some point I was told to prefer /versions over /capabilities, but after some searching I can't seem to find a reference to this.
There was a problem hiding this comment.
I can't seem to find a reference to this.
It's in the spec: https://spec.matrix.org/v1.6/client-server-api/#capabilities-negotiation
The relevant bit is:
This system should not be used to advertise unstable or experimental features - this is better done by the /versions endpoint.
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.
Given this it seems like Oliver's suggestion is the way to go? Any other suggestions I should consider?
I'd probably double check if clients would be willing to do this first?
There was a problem hiding this comment.
MSC4026 was written for this, it has now passed FCP.
…atrix-org/synapse into shay/experimental_flags_part_2
| from synapse.types import JsonDict, UserID | ||
|
|
||
| if TYPE_CHECKING: | ||
| from synapse.server import HomeServer | ||
|
|
||
|
|
||
| class ExperimentalFeature(str, Enum): |
There was a problem hiding this comment.
This was moved to the experimental features database class to avoid a circular import that occurred when using this type in the presence handler.
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
This is a follow up to #15344 (and is based on that branch) which actually implements moving the features from the experimental config to per-user flags.