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.

Sign up for GitHub

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

Jump to bottom

Use r0 APIs for privacy features when HS supports spec version #11246

Closed
jryans opened this issue Oct 28, 2019 · 8 comments · Fixed by matrix-org/matrix-js-sdk#1066
Closed

Use r0 APIs for privacy features when HS supports spec version #11246

jryans opened this issue Oct 28, 2019 · 8 comments · Fixed by matrix-org/matrix-js-sdk#1066
Assignees
@jryans
Labels
Privacy T-Defect

Comments

@jryans
Copy link
Collaborator

jryans commented Oct 28, 2019

As per MSC2324 on how to ship spec-dependent things, we should change to the r0 API prefix when a server advertises the spec version that includes a feature.

For privacy, this means updating how we handle feature flags and spec versions to change the prefix when the spec version appears.
@turt2live
Copy link
Member

Please double check with the backend team that this is the plan for legacy stuff. Although there's an MSC for the process, it's not final yet. There's also no wording for how past flags are being dealt with, if at all.

@jryans jryans self-assigned this Nov 1, 2019
@jryans
Copy link
Collaborator Author

jryans commented Nov 5, 2019

At the moment, it's not entirely clear to me what the backend team intends here. I have asked for clarification on their r0.6.0 issue.

@turt2live
Copy link
Member

from memory, which may have been a verbal conversation, the plan is to honour the 2 month notice window. I would poke Neil directly to get an answer.

"2 month notice window" being the backend team supports the unstable APIs, spec release, and flags for 2 months at which point they start screaming at us if we haven't done our appropriate checks.

@jryans
Copy link
Collaborator Author

jryans commented Nov 6, 2019

Looks like @neilisfragile indeed agrees with the 2 month window and then unstable prefix would be removed.

We should go ahead and use the stable prefix in Riot when the new spec version appears.

@jryans jryans removed the X-Blocked label Nov 6, 2019
jryans added a commit to matrix-org/matrix-js-sdk that referenced this issue Nov 6, 2019
@jryans
Use stable API prefix for 3PID APIs when supported
20f5c3e 
If the server advertises spec version r0.6.0, it must have the 3PID APIs
available under the stable API prefix.

Fixes element-hq/element-web#11246
@jryans jryans mentioned this issue Nov 6, 2019
Merged
@jryans
Copy link
Collaborator Author

jryans commented Nov 6, 2019

PR is ready to go, so we're just waiting on the r0.6.0 spec text later this week.

@turt2live
Copy link
Member

For good measure: r0.6.0 is now published, as is r0.3.0 for identity servers. The backend team has some work to do in order to have the version published on their end (moving things to the stable namespaces) still. Under the new spec process, if they haven't done so in 2 months we get to yell at them.

@jryans
Copy link
Collaborator Author

jryans commented Nov 7, 2019 •
edited
Loading

Hooray! To be clear though, it's fine to merge this in Riot now though, right @turt2live?

@jryans
Copy link
Collaborator Author

jryans commented Nov 7, 2019

Answer: yes, though it means it's untested.

@jryans jryans removed the X-Blocked label Nov 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jryans jryans

Labels
Privacy T-Defect
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use stable API prefix for 3PID APIs when supported matrix-org/matrix-js-sdk
2 participants
@jryans @turt2live