Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Remove the unspec'd Account Validity feature from Synapse #15273

Open
2 tasks
anoadragon453 opened this issue Mar 15, 2023 · 0 comments
Open
2 tasks

Remove the unspec'd Account Validity feature from Synapse #15273

anoadragon453 opened this issue Mar 15, 2023 · 0 comments
Labels
A-Spec-Compliance places where synapse does not conform to the spec O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. Z-Dev-Wishlist Makes developers' lives better, but doesn't have direct user impact

Comments

@anoadragon453
Copy link
Member

We have an undocumented and unspec'd Account Validity feature currently implemented in Synapse. This was originally written for DINUM. Since then, all of the functionality has been moved into the module API (#9884). https://github.com/matrix-org/synapse-email-account-validity is the only known implementation of this API.

Synapse still has an internal implementation of account validity however, gated behind an undocumented account_validity config option. This implementation was originally written for DINUM, and at this point I don't think they make use of Synapse's internal implementation anymore; instead relying on the module instead. I think we should remove it.

However, even after removing Synapse's internal implementation of this feature and leaving behind the account validity module API, we're still left with unspec'd functionality.

  • Part of the feature works by returning an unspec'd ORG_MATRIX_EXPIRED_ACCOUNT error code to clients when their account expires. Modules shouldn't be returning undocumented error codes to clients on spec'd C-S endpoints.
  • In addition, MSC3720 (Synapse implementation) defines a new endpoint to allow clients to query certain metadata about other local and remote users. Part of that implementation included returning a org.matrix.expired field in the response, which lets clients know whether another user's account is no longer valid. MSC3720 does not mention this field.

This is clearly a feature that people want; but I think more spec work is needed to allow this functionality in mainline Synapse, even in module form.


This issue is really two in one, and latter probably belongs in matrix-spec:

  • Remove the internal account validity implementation gated behind the undocumented account_validity config option.
  • Spec account validity (or something like it) so that we can comfortably have modules that implement it without breaking spec compliance.
@anoadragon453 anoadragon453 added A-Spec-Compliance places where synapse does not conform to the spec T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. Z-Dev-Wishlist Makes developers' lives better, but doesn't have direct user impact labels Mar 15, 2023
@H-Shay H-Shay added O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. labels Mar 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Spec-Compliance places where synapse does not conform to the spec O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. Z-Dev-Wishlist Makes developers' lives better, but doesn't have direct user impact
Projects
None yet
Development

No branches or pull requests

2 participants