Everything you need
to build on Me2eM
API references for all packages, glossary, quick starts, and guides — from first seed phrase to a verified session.
Core entities
The core of the protocol: a root Identity derived from a seed phrase, contextual Handles, and stateless signed sessions.
Nothing here is stored or looked up: a server verifies a session with one signature check, and a third party verifies delegated access using only your root public key. Attestation chains carry audiences, scopes and TTL caps enforced at verification time — trust can be delegated, and revoked, without sharing a private key.
What you get
-
A seed-derived Identity — from 32 bytes or a 12/24-word phrase — constant forever, stored nowhere.
-
Isolated Handles — a separate Ed25519 keypair per context; compromising one reveals nothing about the others.
-
Attestation chains — parent-signed grants with audiences, scopes and TTL caps, verified offline by any third party.
-
Stateless sessions — verifyStateless for your backend, verifyAttested for partners — with instant branch revocation.
-
Derivations built in — deterministic passwords, channel keys and X25519 shared secrets, plus BIP39 passphrase support.
End-to-end encryption
Protocol cryptography for real communication: canonical Signal X3DH, long-lived encrypted channels, and envelopes for recipients who are offline.
Channels derive a fresh key for every message and rotate epochs, so what was encrypted stays sealed even if a key leaks later. Pre-keys make asynchronous delivery work: you can encrypt for someone who hasn't been online for days. Underneath sit audited primitives — HKDF, X25519, AES-256-GCM — with Argon2id protecting passwords at the edges.
What you get
-
Canonical X3DH — Signal's key agreement with mandatory one-time pre-keys — no zero-fallback, MITM-resistant.
-
Channels with forward secrecy — per-message keys, strictly-increasing replay protection, epoch rotation at defined points.
-
Envelopes for the offline — X3DH-wrapped keys reach recipients who haven't been online; every envelope is self-contained.
-
Argon2id password hardening — named profiles for interactive and sensitive use, strength checks and HIBP breach lookup.
-
Verified primitives — HKDF against RFC 5869 test vectors, X25519, AES-256-GCM, secure key wipe.
React SDK
React bindings that turn the protocol into product UI: identity hooks, seed-phrase screens, self-renewing sessions.
The seed phrase is the one secret users must never lose — so its UX is part of the security model. Words are shown once, verified by an order grid, validated word by word on import. Derived keys persist only as non-extractable CryptoKeys, isolated per identity. A headless layer keeps every state machine framework-agnostic — the future @me2em/sdk.
What you get
-
Identity hooks — useCreateIdentity, useImportSeed, useHandle, useSubHandle — the full identity lifecycle.
-
Seed UX that prevents disasters — show-once display, single copy, order-verification grid, per-word import validation.
-
Sessions that renew themselves — useSession tracks expiry and auto-renews at half-life.
-
Encrypted context cache — per-identity IndexedDB isolation with non-extractable persisted CryptoKeys.
-
Headless layer — framework-agnostic state machines with zero React imports.
Speak the protocol
A shared vocabulary for the whole model — each term is defined once, here, and used everywhere else.
Identity
Root cryptographic identity derived from a seed phrase. Constant forever.
Handle
A derived, attested, named key representing a distinct identity context.
SubHandle
A leaf child of a Handle.
Attestation
A parent-signed statement binding a child key to a name and a grant.
Session
A stateless signed authorization token.
Channel
A long-lived E2EE relationship derived from an X3DH shared secret.
Transient material
Key bytes existing only in RAM at the moment of use.
Ephemeral material
TTL-bound rotating material (SPK/OTK, cache keys, session tokens).
The protocol
at work.
This is a collection of action guides for the use cases — protocol code examples across industries. Every scenario becomes a step-by-step tutorial. Take them as a base for your own projects: read the docs, study the examples, build.
New tutorials land in the blog as the protocol grows.
Read the tutorialsOne protocol, many scenarios.
From seed to verified session
Four steps — the same in every scenario, from a messenger to a charging network.
Write the seed
12 or 24 BIP39 words on paper. The only permanent carrier of identity — never transmitted, never stored.
Derive the root
The Identity is computed locally by HKDF. Handles for each context — work, personal, devices — derive offline from it.
Delegate & sign
Attestation chains grant scoped, time-boxed access to devices, partners, and AI agents. Sessions are stateless signed tokens.
Verify & revoke
Any third party verifies with the root public key alone. One revoked jti disables an entire branch — instantly.
Frequently asked questions
The questions that come up before the first derivation.
The protocol
Do I need to register anywhere?
What happens if I lose my seed phrase?
Is Me2eM a blockchain?
Is it production-ready?
Building on it
Which verification mode should I use?
How deep can the hierarchy go?
Can I revoke a device or an AI agent?
Where do I report a vulnerability?
License
Is it free to use?
Your first session in minutes
Install a package, derive a Handle, and verify a stateless session — the quick start runs across all three packages.