What your relay can see, written down.

• Who is receiving

  The recipient user and device are in the clear on every envelope, sealed or not. Sealed sender hides the sender, not the conversation.

• When, and roughly how much

  Timestamps are plaintext. Message bodies are padded into 160-byte buckets, which coarsens length but does not conceal it, and attachments travel through a separate object store.

• Group context

  The group ID travels in the clear. Multi-recipient sealed sends hand the relay the recipient list so it can fan the message out.

• Network-level metadata

  Addresses, connection timing, and traffic patterns are properties of your transport and deployment. This SDK makes no claim about them, and implements no decoy traffic or timing jitter.

• Sealed sender is best effort

  If the recipient profile key or identity key is unavailable, the client falls back to identified delivery rather than failing the send. Design for the fallback, not the happy path.

5,875

assertions across 351 modules, 0 failing and 1 skipped, on 2026-07-24. The checks live in the private engineering repository this one is exported from; an export is only cut from a revision where they pass.

6

direct production dependencies — @noble/ciphers, @noble/curves, @noble/hashes, @noble/post-quantum, async-lock, unique-names-generator — resolving to 6 packages in total. The only transitive edges are the @noble packages depending on one another, so the resolved tree adds nothing that list does not already name. Everything else is a development or optional peer dependency. The published repository runs a build, a typecheck, and a production-tree advisory audit on every change.

7

published specifications the implementation profile is pinned to, by revision, in the table below.

72 hours

to acknowledge a vulnerability report sent to security@open-e2ee.dev rather than to a public issue, and 7 days to an initial assessment. The full policy, including disclosure handling and severity targets, is in the repository (opens in a new tab).

What those checks are, in the terms used elsewhere on this site: cryptographic known-answer checks run ML-KEM, hashing, AEAD, and signature primitives against published vector data. Conformance scenarios check session, group, and sealed-sender invariants against known-answer material and against behaviour documented in the published specifications. Property-based checks run over protocol and encoding invariants. Integration flows cover multi-device, group lifecycle, provisioning, and relay delivery. Adapter suites cover every storage, relay, and object-store adapter. The quickstart printed in the README is executed as written on every change.

Assurance — what runs, what is not published, and why (opens in a new tab)Third-party notices (opens in a new tab)

Not audited by any independent firm

Reviewed continuously by adversarial AI agents; not audited by any independent firm. Every change passes an adversarial AI review before it merges, and recurring whole-codebase AI audit passes run against the engineering repository. What that covers — and what it does not — is stated in the assurance summary (opens in a new tab). No independent firm has audited the SDK, and none is engaged. The codebase is structured for review — narrow state transitions, injectable adapters, small protocol seams — but structure is not certification, and neither is a machine reading it.

Not a validated cryptographic module

Pure-JavaScript cryptography is not FIPS 140-validated, and no part of this SDK is offered as a validated module. The ML-KEM implementation follows FIPS 203, but following a standard and being validated against it are different things, and only the second satisfies a programme that requires validation. If yours does, this is the wrong choice, and we would rather you learned it here than in week six.

JavaScript is not a constant-time environment

Browser, Node, and React Native engines provide no machine-level constant-time guarantee. The implementation uses best-effort patterns on selected paths; it does not claim timing equivalence against a co-resident adversary.

Memory cannot be reliably wiped

Typed-array overwrites shorten the life of some buffers. Strings, engine temporaries, registers, and garbage-collected pages remain outside the SDK’s control.

Post-quantum means confidentiality, not signatures

Post-quantum key agreement is the default and fails closed, using ML-KEM-1024 for PQXDH and an ML-KEM Braid ratchet. There is no public disabled mode. Identity signatures remain classical Ed25519 and X25519. The protection is against harvest-now-decrypt-later, not against a quantum adversary forging identities.

There is no key escrow, so device loss is real

Nothing recoverable is held on a server. Transferring state to new hardware requires the old device to still be available; a lost device means re-registering, and contacts see a safety-number change. Decide your recovery story before launch, not after.

Not Signal Messenger, and not wire-compatible with it

An independent implementation of the published Signal Protocol specifications. Not affiliated with or endorsed by Signal Messenger LLC or Signal Technology Foundation. The cryptographic core follows the Signal Protocol specification — same key agreement, same ratchet, in many places byte-identical — but the encoding is deliberately our own. Messages, identities, and sessions do not cross between the two, and safety numbers shown here will never match the ones a Signal Messenger client displays. Every deliberate difference, and what it costs, is documented in DEVIATIONS (opens in a new tab).