Start
From install to a working encrypted round trip, then the one decision — which adapters you run — that constrains every page after it.
This section gets a real ciphertext moving between two identities on your runtime. You then replace the development adapters with production adapters.
Everything here is reversible. Nothing in Start commits you to a backend, a storage strategy, or a trust policy: those decisions start in Build.
Run the examples
Open the playground to send an encrypted message and decrypt a reply. The page and developer console show actual results. You need no account or installation.
| Example | Run and inspect | Storage |
|---|---|---|
| Browser | Edit on StackBlitz or run the source locally | Both identities and the relay use temporary memory. |
| Expo / Hermes | Run the native example on iOS or Android. | Alice keeps her identity and sessions in SQLCipher. Bob and the relay use memory. |
The Expo example checks Alice’s identity and another exchange after restart. SQLCipher requires a native development or release build. Expo Go does not include it.
Pick your runtime now
The site remembers the choice below and shows it in runtime-specific instructions on later pages.
The SDK runs on Hermes. Its protocol code is Pure TypeScript. Expo modules provide secure randomness and SQLCipher storage.
npm install @open-e2ee/signal-protocol-sdk@6.0.0 expo-crypto expo-secure-store expo-sqlite drizzle-ormRequires a native development or release build. Expo Go does not include SQLCipher.
The fastest way to see the protocol work. The adapter is supported, and the browser threat model is not something a storage choice can fix.
npm install @open-e2ee/signal-protocol-sdk@6.0.0Services, integration tests, CLIs, and relay development. Also the runtime where you should consider why you run a client at all.
npm install @open-e2ee/signal-protocol-sdk@6.0.0The order these build in
-
Quickstart: run two identities, one development relay, and one encrypted round trip in a single process. This path needs no backend or accounts. Run it before you read the rest of this section. It verifies that the protocol works in your runtime.
-
Your runtime page: select Expo, Browser, or Node. Each page replaces the quickstart's in-memory store with a production store. It answers seven runtime-specific integration questions. These questions cover key location, lifetime, backend isolation, and prekey replenishment. They also cover reinstallation, cleared data, relay storage, and backups.
-
Choosing adapters: review the four slots, required slots, and maturity of each shipped option. This decision shapes the rest of the integration. Make it after you see one runtime work.
Then
Build is where the application architecture above the protocol starts, beginning with how a user becomes a set of devices.
If you would rather see a complete application than assemble one: Guides are end-to-end builds with every custody decision stated.