XMTP client SDK for JavaScript applications
xmtp-js
provides a TypeScript implementation of an XMTP client for use with JavaScript and React applications.
Build with xmtp-js
to provide messaging between blockchain wallet addresses, delivering on use cases such as wallet-to-wallet messaging and dapp-to-wallet notifications.
xmtp-js
was included in a security assessment prepared by Certik.
To learn more about XMTP and get answers to frequently asked questions, see the XMTP documentation.
xmtp-js
Use the XMTP React playground app as a tool to start building an app with XMTP. This basic messaging app has an intentionally unopinionated UI to help make it easier for you to build with.
Use the XMTP Inbox Web example app as a reference implementation to understand how to implement features following developer and user experience best practices.
Access the xmtp-js
client SDK reference documentation.
NPM
npm install @xmtp/xmtp-js
PNPM
pnpm install @xmtp/xmtp-js
Yarn
yarn add @xmtp/xmtp-js
A Buffer polyfill is required for browser environments.
See this solution for implementation details.
This SDK uses WebAssembly, which may require additional configuration in your environment.
vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
optimizeDeps: {
exclude: ['@xmtp/user-preferences-bindings-wasm'],
},
})
Configuration is dependent on your version of Next.js.
next.config.mjs
Next.js < 15
const nextConfig = {
experimental: {
serverComponentsExternalPackages: ['@xmtp/user-preferences-bindings-wasm'],
},
}
export default nextConfig
Next.js >= 15
const nextConfig = {
serverExternalPackages: ['@xmtp/user-preferences-bindings-wasm'],
}
export default nextConfig
This SDK uses BigInt
in a way that's incompatible with polyfills. To ensure that a polyfill isn't added to your application bundle, update your browserslist configuration to exclude browsers that don't support BigInt
.
For the list of browsers that don't support BigInt
, see this compatibility list.
Check out our official documentation to get started developing with XMTP and JavaScript.
Important
If you are building a production-grade app, be sure to use an architecture that includes a local cache backed by an XMTP SDK.
To learn more, see Use local-first architecture.
If the user has a compatible version of MetaMask installed in their browser, and the useSnaps
ClientCreateOption
is set to true
, the SDK will attempt to install and connect to the "Sign in with XMTP" Snap as part of client creation. If successful, all cryptographic operations will happen inside the secure context of the Snap instead of the main browser thread. This offers greater security and a smoother sign-in experience.
In cases where the Snap is being used, Client.getKeys()
will fail because the client application has no access to the private key material when used with Snaps.
Currently, useSnaps
uses a default value of false
. However, in future versions of xmtp-js
, it will be updated to use a default value of true
.
Because xmtp-js
is in active development, you should expect breaking revisions that might require you to adopt the latest SDK release to enable your app to continue working as expected.
XMTP communicates about breaking revisions in the XMTP Discord community, providing as much advance notice as possible. Additionally, breaking revisions in an xmtp-js
release are described on the Releases page.
Older versions of the SDK will eventually be deprecated, which means:
The following table provides the deprecation schedule.
Announced | Effective | Minimum Version | Rationale |
---|---|---|---|
2022-08-18 | 2022-11-08 | v6.0.0 | XMTP network will stop supporting the Waku/libp2p-based client interface in favor of the new gRPC-based interface |
Issues and PRs are welcome in accordance with our contribution guidelines.
production
and dev
network environmentsXMTP provides both production
and dev
network environments to support the development phases of your project.
The production
and dev
networks are completely separate and not interchangeable.
For example, for a given blockchain account address, its XMTP identity on dev
network is completely distinct from its XMTP identity on the production
network, as are the messages associated with these identities. In addition, XMTP identities and messages created on the dev
network can't be accessed from or moved to the production
network, and vice versa.
Important
When you create a client, it connects to the XMTPdev
environment by default. To learn how to use theenv
parameter to set your client's network environment, see Configure the client.
The env
parameter accepts one of three valid values: dev
, production
, or local
. Here are some best practices for when to use each environment:
dev
: Use to have a client communicate with the dev
network. As a best practice, set env
to dev
while developing and testing your app. Follow this best practice to isolate test messages to dev
inboxes.
production
: Use to have a client communicate with the production
network. As a best practice, set env
to production
when your app is serving real users. Follow this best practice to isolate messages between real-world users to production
inboxes.
local
: Use to have a client communicate with an XMTP node you are running locally. For example, an XMTP node developer can set env
to local
to generate client traffic to test a node running locally.
The production
network is configured to store messages indefinitely. XMTP may occasionally delete messages and keys from the dev
network, and will provide advance notice in the XMTP Discord community.