Skip to content

v8.0.0

Compare
Choose a tag to compare
@github-actions github-actions released this 13 Apr 18:09
· 809 commits to main since this release
112f90e

8.0.0 (2023-04-13)

New features

This release is focused around two key themes: performance and security.

Conversation Caching

Performance-minded developers have already been using the previous conversations.export() and conversations.import() functionality to cache conversations in their application’s persistent storage. Caching the conversation list can improve performance of client.conversations.list() by up to 90%.

We have now moved this functionality natively into the SDK to make these workflows easier, and added authenticated ECIES encryption to keep this sensitive cache data private and secure. Conversation caching is enabled by default when using xmtp-js in the browser, and the only thing you need to do to take advantage of it is upgrade to version 8.

DecodedMessage Serialization

In addition to caching conversations, many developers would like to cache entire message histories. Previously this was quite difficult, as DecodedMessage objects were not easily serializable.

With v8 of the SDK we have two new methods available: decodedMessage.toBytes() and DecodedMessage.fromBytes(messageBytes, client). Now developers can keep copies of decrypted messages in their application’s persistent storage and avoid the need to download and decrypt the same message on every session.

Keystore API

Protecting users against malicious applications is an important part of our security strategy. With v8 of xmtp-js we have moved all code that interacts with a user’s private keys into a separate module called the Keystore. All interactions with this Keystore happen across a well-defined API boundary using Protobuf request types.

The first Keystore implementation will live in memory with your application, which offers only marginal security improvements. But this pattern of development allows us to build future Keystore implementations that live in contexts more secure than your web application. Some examples include browser extensions, service workers, and using the upcoming MetaMask Snaps framework.

Future Keystore implementations will be compatible with version 8 of xmtp-js.

Pre-signature callbacks

In previous versions of our SDK, we would prompt for wallet signatures without warning to the developer. This made it difficult to update your app’s UI to explain why we needed the signature. It also caused issues for applications requesting signatures from WebViews in mobile apps using deep-links, which require user interaction between two consecutive links. These new callbacks make it possible for developers to require a user interaction between signatures if desired, but are strictly optional.

Upgrade from v7.x.x to v8.0.0

Use these instructions to upgrade from v7.x.x to ≥v8.0.0.

Breaking changes

v8.0.0 introduces the following breaking changes for apps using v7.x.x:

  • conversations.export() , conversations.import() , conversation.export , and conversation.fromExport() have all been removed. Exporting and serializing conversations is now encrypted and handled inside the SDK. See Upgrade Tasks for more details.
  • client.listEnvelopes now accepts only a single topic as an argument instead of an array of topics.
  • The constructors for ConversationV1 and ConversationV2 have changed. If your code relies on directly creating these types of objects it will have to be modified.
  • ClientOptions.keyStoreType has been removed.

Upgrade tasks

To avoid the impact of these breaking changes in your app, upgrade to v8.0.0 as soon as possible. Additional tasks might be necessary based on XMTP functionality provided by your app.

If your app caches conversations, similar to the method described in this caching guide made obsolete by v8, do the following to avoid breaking changes:

  1. Remove any usage of conversations.import() and conversations.export() in your code and the caching class
  2. Pass { persistConversations: true } as a ClientCreateOption when calling Client.create()

For a full example of this migration, you can see this PR to our Inbox app.

If your app uses the listEnvelopes low-level API and queries with multiple topics, do the following to avoid breaking changes:

  1. Replace any usage of client.listEnvelopes with client.apiClient.batchQuery. The semantics of batchQuery are different from listEnvelopes and you should evaluate whether they work for your use case. listEnvelopes provides a single set of results across all topics, while batchQuery provides one set of results per topic.

See this PR for an example of replacing a call to listEnvelopes with batchQuery.