* Categorise members by role in the ChangeRoles screen
* Fix automatic reload of member list when either the membership or power levels change
* Replace empty space with disabled checkbox
* Add 'pending' label to members who are in invited state
* Implement new designs
* Fix string issue in confirm recovery key screen
* Update screenshots
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
* Move session verification to the FTUE
* Allow session verification flow to be restarted
* Use `EncryptionService` to display session verification faster
* Remove session verification item from settings
* Remove session verification banner from room list
* Remove 'verification needed' variant from the `TimelineEncryptedHistoryBanner`
* Improve verification flow UI and UX
* Remove 'verification successful' snackbar message
* Only register push provider after the session has been verified
* Hide room list while the session hasn't been verified
* Prevent deep links from changing the navigation if the session isn't verified
* Update screenshots
* Renamed `FtueState` to `FtueService`, created an actual `FtueState`.
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
* Implement MSC2530
* Some layout improvements for images and videos with captions
* Update screenshots
* Replace `it` in several previews with `isMine`
---------
Signed-off-by: Marco Antonio Alvarez <surakin@gmail.com>
Co-authored-by: Marco Antonio Alvarez <surakin@gmail.com>
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
* Remove unnecessary `updateMembers` calls.
Some of them can be directly removed since we have a way to automatically get member info updates based on membership changes.
Others can be replaced by a simpler `getUpdatedMember` method. This might still need a full member sync, but it's quite unlikely.
Improve room member list UX:
- Don't display the list in chunks anymore.
- Use an indeterminate linear progress indicator to display some loading is being done (either loading the cached list or the updated one).
- Try to make sure we don't display the members loaded from timeline items as the cached room list by mistake.
* Update screenshots
* Simplify member loading logic.
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
* Change a room's permissions power levels
* Make `currentPermissions` use a `MatrixRoomPowerLevels?` instance instead.
* Update strings
* Update screenshots
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
This happened because `roomInfoFlow` was shared eagerly and the `initial` part was called after the `Room` Rust object was destroyed.
I think there isn't a need for room info to be shared, it was a mistake I forgot to rollback.
Allow Admins to modify room member roles:
- Add a 'roles and permissions' option for each room.
- Allow promoting users to admins, adding or removing moderators, and demote yourself if you're and admin.
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
* Add extra params to bug reports
- `local_time`: the time in the device's timezone.
- `utc_time`: the time in UTC.
- `sdk_sha`: the commit SHA that was used to build the Rust SDK
* Show blocked users list.
Also allow to unblock them from this list.
* Add non-blocking `AsyncIndicatorHost` component
* Use `StateFlow` for getting ignored users.
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
Now, this is a story all about how
Certificates work in Android town
And I'd like to take a minute
Enter, close the door
I'll tell you how I've figured out the inner workings of the Keystore
Well it all boils down the fact that Google got scared
It said, "You're certs are movin' to a place you won't find".
So the directory, user certificates are stored, is hard to find, and possibly
not readable by your application[1]. Instead, we need to use the Keystore[2]
API, specifically we'll need to open the `AndroidCAStore` Keystore type.
The various Keystore types are supposedly documented[3], but I'm failing to
find a logical path that would lead you to conclude that:
a) System certificates can or should be accessed using the Keystore,
specifically the AndroidCAStore type
b) User certificates can be found in the same Keystore type as the system
certificates
So this was mostly found using random googling, swearing, and a couple of
educated guesses.
[1]: https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html
[2]: https://developer.android.com/reference/java/security/KeyStore
[3]: https://docs.oracle.com/en/java/javase/17/docs/specs/security/standard-names.html#keystore-types
Jorge Martin Espinosa