* Create a `ContentScanner` component:
- Add `:features:contentscanner:api` module with the interface.
- Implement the concrete component using the Rust SDK in `:libraries:matrix:impl`.
This can be used to both set up the content scanner media fetching in the SDK Client and manually scanning media sources from the Android side
* Create `ContentScannerUrlProvider` in a new `:features:contentscaner:api` module as a noop implementation
Use it as a placeholder for the code to instantiate a `RustContentScanner` with the fetched URL and set it as part of the SDK client.
* Expose the optional `ContentScanner` in the `@SessionScope`
* Split the storage part of the Element well-known retriever so it can be reused for the non-session bound retriever.
Also add the new `content_scanner_url` field to it.
This will be used by the enterprise code to fetch the actual content scanner url.
* Bump enterprise commit to have access to the actual content scanner url provider implementation
* Fix tests and lint issues
* Use the right namespace for `:features:contentscanner:api`, also use the right namespace for `impl`
---------
Co-authored-by: Benoit Marty <benoitm@element.io>
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>
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
Jorge Martin Espinosa