The merged element-enterprise#261 well-known schema advertises the feature
under custom_recovery_passphrase (no _settings/_requirements suffix), so the
parser previously looking for custom_recovery_passphrase_settings would never
activate the flow. Update the @SerialName and drop the narrow "Requirements"
suffix from the type — the block is now general, extensible feature settings —
to mirror the .pkl CustomRecoveryPassphrase class. Bumps the enterprise
submodule to the matching consumer change.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When the homeserver advertises custom_recovery_passphrase_settings, always run
the custom passphrase flow, flooring min_character_count at 1 (covering missing,
zero, and negative values) so the derived passphrase can never be empty. Any
stronger minimum stays the operator's choice. Replaces the previous behaviour of
dropping the spec and falling back to the auto-generated key.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add CustomRecoveryPassphraseRequirements to ElementWellKnown and decode
the custom_recovery_passphrase_settings block (currently just
min_character_count) from the homeserver's element.json. Invalid specs
(missing or non-positive min_character_count) are logged and mapped to
null so the setup flow falls back to the generated-key path. Field names
match the ESS well-known schema (element-enterprise#261).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Use the SDK `Client` to check whether a HS is compatible
* Remove usage of unused `WellKnown`, keep `ElementWellKnown`
* Make `HomeServerLoginCompatibilityChecker.check` return `true/false` values to distinguish non-valid homeservers from a failed check
* Use `inMemoryStore` and `serverNameOrHomeserverUrl`
* Do some cleanup of `isValid` and `isWellknownValid`
* Make the debounce for starting the search a bit higher, as checking for the homeservers seems more resource-intensive now
Jenna Vassar