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.

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

Update Rust crate matrix-sdk to 0.9.0 #36

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

renovate[bot]
Copy link

@renovate renovate bot commented Jul 15, 2022

This PR contains the following updates:

Package Type Update Change
matrix-sdk dependencies minor 0.3.0 -> 0.9.0

Release Notes

matrix-org/matrix-rust-sdk (matrix-sdk)

v0.9.0: matrix-sdk 0.9.0

Compare Source

What's Changed

Bug Fixes
  • Use the inviter's server name and the server name from the room alias as
    fallback values for the via parameter when requesting the room summary from
    the homeserver. This ensures requests succeed even when the room being
    previewed is hosted on a federated server.
    (#​4357)

  • Do not use the encrypted original file's content type as the encrypted
    thumbnail's content type.
    (#ecf4434)

Features
  • Enable persistent storage for the EventCache. This allows events received
    through the /sync endpoint or backpagination to be stored persistently,
    enabling client applications to restore a room's view, including events,
    without requiring server communication.
    (#​4347)

  • [BREAKING] Make all fields of Thumbnail required
    (#​4324)

  • Backups::exists_on_server, which always fetches up-to-date information from the
    server about whether a key storage backup exists, was renamed to
    fetch_exists_on_the_server, and a new implementation of exists_on_server
    which caches the most recent answer is now provided.

v0.8.0: matrix-sdk 0.8.0

Compare Source

What's Changed

Bug Fixes
  • Add more invalid characters for room aliases.

  • Match the right status code in Client::is_room_alias_available.

  • Fix a bug where room keys were considered to be downloaded before backups were
    enabled. This bug only affects the
    BackupDownloadStrategy::AfterDecryptionFailure, where no attempt would be
    made to download a room key, if a decryption failure with a given room key
    would have been encountered before the backups were enabled.

Documentation
  • Improve documentation of Client::observe_events.
Features
  • Add create_room_alias function.

  • Client::cross_process_store_locks_holder_name is used everywhere:

  • StoreConfig::new() now takes a
    cross_process_store_locks_holder_name argument.

  • StoreConfig no longer implements Default.

  • BaseClient::new() has been removed.

  • BaseClient::clone_with_in_memory_state_store() now takes a
    cross_process_store_locks_holder_name argument.

  • BaseClient no longer implements Default.

  • EventCacheStoreLock::new() no longer takes a key argument.

  • BuilderStoreConfig no longer has
    cross_process_store_locks_holder_name field for Sqlite and
    IndexedDb.

  • EncryptionSyncService and Notification are using Client::cross_process_store_locks_holder_name.

  • Allow passing a custom RequestConfig to an upload request.

  • Retry uploads if they've failed with transient errors.

  • Implement EventHandlerContext for tuples.

  • Introduce a mechanism similar to Client::add_event_handler and
    Client::add_room_event_handler but with a reactive programming pattern. Add
    Client::observe_events and Client::observe_room_events.

// Get an observer.
let observer =
    client.observe_events::<SyncRoomMessageEvent, (Room, Vec<Action>)>();

// Subscribe to the observer.
let mut subscriber = observer.subscribe();

// Use the subscriber as a `Stream`.
let (message_event, (room, push_actions)) = subscriber.next().await.unwrap();

When calling observe_events, one has to specify the type of event (in the
example, SyncRoomMessageEvent) and a context (in the example, (Room, Vec<Action>), respectively for the room and the push actions).

  • Implement unwedging for media uploads.

  • Send state from state sync and not from timeline to widget (#​4254)

  • Allow aborting media uploads.

  • Add RoomPreviewInfo::num_active_members.

  • Use room directory search as another data source.

  • Check if the user is allowed to do a room mention before trying to send a call
    notify event.
    (#​4271)

  • Add Client::cross_process_store_locks_holder_name().

  • Add a PreviouslyVerified variant to VerificationLevel indicating that the
    identity is unverified and previously it was verified.

  • New UserIdentity::pin method.

  • New ClientBuilder::with_decryption_trust_requirement method.

  • New ClientBuilder::with_room_key_recipient_strategy method

  • New Room.set_account_data and Room.set_account_data_raw RoomAccountData
    setters, analogous to the GlobalAccountData

  • New RequestConfig.max_concurrent_requests which allows to limit the maximum
    number of concurrent requests the internal HTTP client issues (all others have
    to wait until the number drops below that threshold again)

  • Implement proper redact handling in the widget driver. This allows the Rust
    SDK widget driver to support widgets that rely on redacting.

Refactor
  • [breaking] Rename DisplayName to RoomDisplayName.

  • Improve is_room_alias_format_valid so it's more strict.

  • Remove duplicated fields in media event contents.

  • Use SendHandle for media uploads too.

  • Move event_cache_store/ to event_cache/store/ in matrix-sdk-base.

  • Move linked_chunk from matrix-sdk to matrix-sdk-common.

  • Move Event and Gap into matrix_sdk_base::event_cache.

  • Move formatted_caption_from to the SDK, rename it.

  • Tidy up and start commenting the widget code.

  • Get rid of ProcessingContext and inline it in its callers.

  • Get rid of unused limits parameter when constructing a WidgetMachine.

  • Use a specialized mutex for locking access to the state store and
    being_sent.

  • Renamed VerificationLevel::PreviouslyVerified to
    VerificationLevel::VerificationViolation.

  • [breaking] Replace the Notification type from Ruma in SyncResponse and
    Client::register_notification_handler by a custom one.

  • [breaking] The ambiguity maps in SyncResponse are moved to JoinedRoom
    and LeftRoom.

  • [breaking] Room::can_user_redact and Member::can_redact are split
    between *_redact_own and *_redact_other.

  • [breaking] AmbiguityCache contains the room member's user ID.

  • [breaking] Replace impl MediaEventContent with &impl MediaEventContent in
    Media::get_file/Media::remove_file/Media::get_thumbnail/Media::remove_thumbnail

  • [breaking] A custom sliding sync proxy set with
    ClientBuilder::sliding_sync_proxy now takes precedence over a discovered
    proxy.

  • [breaking] Client::get_profile was moved to Account and renamed to
    Account::fetch_user_profile_of. Account::get_profile was renamed to
    Account::fetch_user_profile.

  • [breaking] The HttpError::UnableToCloneRequest error variant has been
    removed because it was never used or generated by the SDK.

  • [breaking] The Error::InconsistentState error variant has been removed
    because it was never used or generated by the SDK.

  • [breaking] The widget capabilities in the FFI now need two additional
    flags: update_delayed_event, send_delayed_event.

  • [breaking] Room::event now takes an optional RequestConfig to allow
    for tweaking the network behavior.

  • [breaking] The instant module was removed, use the ruma::time module
    instead.

  • [breaking] Add ClientBuilder::sqlite_store_with_cache_path to build a
    client that stores caches in a different directory to state/crypto.

  • [breaking] The body parameter in get_media_file has been replaced with
    a filename parameter now that Ruma has a filename() method.

v0.7.1

Compare Source

v0.7.0

Compare Source

v0.6.2: matrix-sdk 0.6.2

Compare Source

Fix the access token being printed in tracing span fields.

v0.6.1: matrix-sdk 0.6.1

Compare Source

Fixes a bug where the access token used for Matrix requests was added as a field to a tracing span.

There was another such bug, fixed by version 0.6.2.

v0.6.0: 2022-09-28 - Matrix SDK 0.6.0

Compare Source

We are proud to announce the release of the next major milestone of matrix development in rust: matrix-sdk 0.6.0 (and matrix-sdk-base, matrix-sdk-crypto, matrix-sdk-common, matrix-sdk-test @0.6.0, matrix-sdk-test-macros@0.3.0, matrix-sdk-qrcode@0.4.0 , matrix-sdk-store-encryption@0.2.0, matrix-sdk-indexeddb@0.2.0 and matrix-sdk-sled@0.2.0 respectively), available on crates.io for your convenience.

There are a few major API changes since the 0.5.0 release, listed below. You can find the full list and another troubleshooting section helping you fix common errors you will see when upgrading from 0.5.x to this release in the UPGRADING-0.5-to-0.6.md in the root of the tarball.

Upgrades 0.5 ➜ 0.6

This is a rough migration guide to help you upgrade your code using matrix-sdk 0.5 to the newly released matrix-sdk 0.6 . While it won't cover all edge cases and problems, we are trying to get the most common issues covered. If you experience any other difficulties in upgrade or need support with using the matrix-sdk in general, please approach us in our matrix-sdk channel on matrix.org.

Minimum Supported Rust Version Update: 1.60

We have updated the minimal rust version you need in order to build matrix-sdk, as we require some new dependency resolving features from it:

These crates are built with the Rust language version 2021 and require a minimum compiler version of 1.60

Dependencies

Many dependencies have been upgraded. Most notably, we are using ruma at version 0.7.0 now. It has seen some renamings and restructurings since our last release, so you might find that some Types have new names now.

Repo Structure Updates

If you are looking at the repository itself, you will find we've rearranged the code quite a bit: we have split out any bindings-specific and testing related crates (and other things) into respective folders, and we've moved all examples into its own top-level-folder with each example as their own crate (rendering them easier to find and copy as starting points), all in all slimming down the crates folder to the core aspects.

Architecture Changes / API overall

Builder Pattern

We are moving to the builder pattern (familiar from e.g. std::io:process:Command) as the main configurable path for many aspects of the API, including to construct Matrix-Requests and workflows. This has been and is an on-going effort, and this release sees a lot of APIs transitioning to this pattern, you should already be familiar with from the matrix_sdk::Client::builder() in 0.5. This pattern been extended onto:

Most have fallback (though maybe with deprecation warning) support for an existing code path, but these are likely to be removed in upcoming releases.

Splitting of concerns: Media

In an effort to declutter the Client API dedicated types have been created dealing with specific concerns in one place. In 0.5 we introduced client.account(), and client.encryption(), we are doing the same with client.media() to manage media and attachments in one place with the [media::Media type][media typ] now.

The signatures of media uploads, have also changed slightly: rather than expecting a reader R: Read + Seek, it now is a simple &[u8]. Which also means no more unnecessary seek(0) to reset the cursor, as we are just taking an immutable reference now.

Event Handling & sync updaes

If you are using the client.register_event_handler function to receive updates on incoming sync events, you'll find yourself with a deprecation warning now. That is because we've refactored and redesigned the event handler logic to allowing removing of event handlers on the fly, too. For that the new add_event_handler() (and add_room_event_handler) will hand you an EventHandlerHandle (pardon the pun), which you can pass to remove_event_handler, or by using the convenient client.event_handler_drop_guard to create a DropGuard that will remove the handler when the guard is dropped. While the code still works, we recommend you switch to the new one, as we will be removing the register_event_handler and register_event_handler_context in a coming release.

Secondly, you will find a new sync_with_result_callback sync function. Other than the previous sync functions, this will pass the entire Result to your callback, allowing you to handle errors or even raise some yourself to stop the loop. Further more, it will propagate any unhandled errors (it still handles retries as before) to the outer caller, allowing the higher level to decide how to handle that (e.g. in case of a network failure). This result-returning-behavior also punshes through the existing sync and sync_with_callback-API, allowing you to handle them on a higher level now (rather than the futures just resolving). If you find that warning, just adding a ? to the .await of the call is probably the quickest way to move forward.

Refresh Tokens

This release now supports refresh_tokens as part of the Session. It is implemented with a default-flag in serde so deserializing a previously serialized Session (e.g. in a store) will work as before. As part of refresh_token support, you can now configure the client via ClientBuilder.request_refresh_token() to refresh the access token automagically on certain failures or do it manually by calling client.refresh_access_token() yourself. Auto-refresh is off by default.

You can stay informed about updates on the access token by listening to client.session_tokens_signal().

Further changes
  • MessageOptions has been updated to Matrix 1.3 by making the from parameter optional (and function signatures have been updated, too). You can now request the server sends you messages from the first one you are allowed to have received.
  • client.user_id() is not a future anymore. Remove any .await you had behind it.
  • verified(), blacklisted() and deleted() on matrix_sdk::encryption::identities::Device have been renamed with a is_ prefix.
  • verified() on matrix_sdk::encryption::identities::UserIdentity, too has been prefixed with is_ and thus is onw called is_verified().
  • The top-level crypto and state-store types of Indexeddb and Sled have been renamed to unique types>
  • state_store and crypto_store do not need to be boxed anymore when passed to the StoreConfig
  • Indexeddb's SerializationError is now IndexedDBStoreError
  • Javascript specific features are now behind the js feature-gate
  • The new experimental next generation of sync ("sliding sync"), with a totally revamped api, can be found behind the optional sliding-sync-feature-gate

v0.5.0: SDK 0.5.0 - stores and native crypto

Compare Source

The @​matrix-org/rust team is excited to present to the wider public version 0.5 of the matrix-rust-sdk, now available on crates.io for your convenience. This marks an important milestone after over half a year of work since the latest release (0.4) and with many new team members working on it. It comes with many bug fixes, improvements and updates, but a few we'd like to highlight here:

Better, safer, native-er crypto

One of the biggest improvements under the hood is the replacement of the former crypto core written in C, libolm, with the fully rustic, fully audited Vodozemac. Vodozemac is a much more robust new implementation of the olm crypto primitives and engines with all the learning included and pitfalls from the previous C implementation avoided in a freshly baked, very robust library. With this release both matrix-sdk-crypto and matrix-sdk (when the e2e-encryption is enabled, which it is by default) use vodozemac to handle all crypto needs.

Stores, stores, stores

This release has also seen a major refactoring around the state and crypto store primitives and implementations. From this release forward, the implementation of the storage layer is truly modular and pluggable, with the default implementation (based on sled) even being a separate crate. Furthermore this release has also additional support for the indexeddb-storage layer for in-browser WASM needs. As before, the base still ships with an in-memory store, but if none of them fits your needs, you are very much invited to build your own - we recommend looking at the implementation of the existing matrix-sdk-sled to understand what is needed.

We've further extended and cleaned up the storage API and hardened the two existing implementations: both sled and indexeddb will now encrypt all metadata, including all keys, if a passphrase is given. Even a core dump of a database won't show any strings or other identifiable data. Both implementation also hold a database version string now, allowing future migrations of the database schema while we move forward.

WebAssembly

It already came through in the previous paragraph: we now fully support wasm as a primary target for the main sdk and its dependencies (browser for now). While it was already possible to build the SDK for wasm before, if you were lucky and had the specific emscripten setup, even crypto didn't always fail to compile, our move to vodozemac frees us from these problems and our CI now makes sure all our PRs will continue to build on WebAssembly, too. And with the indexeddb-store, we also have a fully persistent storage layer implementation for all your in-browser matrix needs built in.

More features

Of course a lot more has happened over the last few months as we've ramped up our work on the SDK. Most notably, you can now check whether a room has been created as a space, and we offer nice automatic thumbnailing and resizing support if you enable image. Additionally, there is a very early event-timeline API behind the experimental-timeline-feature-flag. Just to name a few. We really recommend you migrate from the older version to this one.

Process and Workflow

We've also ramped up our CI, parallelized it a lot, while adding more tests. In general we don't merge anything breaking the tests, thus our main can also be considered stable to build again, though things might be changed without prior notice. We recommend keeping an eye out in our team chat to stay current.

Versions

This and all future releases of matrix-sdk adhere to semver and we do our best to stick to it for the default-feature-set. As you will see only the main crate matrix-sdk is actually versioned at 0.5, while other crates - especially newer ones - have different versions attached. We recommend to sticking to the high-level matrix-sdk-crate wherever reasonable as lower level crates might change more often, also in breaking fashion.

With this release all our crates are build with rust v2021 and need a rust compiler of at least 1.60 (due to our need for weak-dependencies).

Conventional Commit

We also want to make it easier for external parties to follow changes and stay up to date with what's-what, so, with this release, we are implementing the conventional commits standard for our commits and will start putting in automatic changelog generation. Which makes it easier for us to create comprehensive changelogs for releases, but also for anyone following main to figure out what changed.

v0.4.1

Compare Source

v0.4.0

Compare Source


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch from 0d53ec3 to 819017f Compare July 15, 2022 12:32
@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch 9 times, most recently from a312626 to dce6b55 Compare August 4, 2022 09:55
@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch from dce6b55 to c054394 Compare September 28, 2022 18:41
@renovate renovate bot changed the title Update Rust crate matrix-sdk to 0.5.0 Update Rust crate matrix-sdk to 0.6.0 Sep 28, 2022
@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch from c054394 to e960561 Compare November 20, 2022 21:51
@renovate renovate bot changed the title Update Rust crate matrix-sdk to 0.6.0 Update Rust crate matrix-sdk to 0.6.2 Nov 20, 2022
@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch from e960561 to b32f98c Compare March 21, 2023 15:13
@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch from b32f98c to 996a611 Compare January 5, 2024 16:06
@renovate renovate bot changed the title Update Rust crate matrix-sdk to 0.6.2 Update Rust crate matrix-sdk to 0.7.0 Jan 5, 2024
@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch from 996a611 to 623c3d3 Compare January 22, 2024 11:15
@renovate renovate bot changed the title Update Rust crate matrix-sdk to 0.7.0 Update Rust crate matrix-sdk to 0.7.1 Jan 22, 2024
@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch from 623c3d3 to 6470354 Compare May 5, 2024 10:48
@renovate renovate bot changed the title Update Rust crate matrix-sdk to 0.7.1 Update Rust crate matrix-sdk to 0.7.0 May 5, 2024
@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch from 6470354 to eb28364 Compare November 19, 2024 14:08
@renovate renovate bot changed the title Update Rust crate matrix-sdk to 0.7.0 Update Rust crate matrix-sdk to 0.8.0 Nov 19, 2024
@renovate renovate bot force-pushed the renovate/matrix-sdk-0.x branch from eb28364 to ca95d14 Compare December 18, 2024 14:34
@renovate renovate bot changed the title Update Rust crate matrix-sdk to 0.8.0 Update Rust crate matrix-sdk to 0.9.0 Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants