A decentralized, seed-derived identity protocol on Ed25519 — for people, IoT fleets and AI agents. A decentralized, seed-derived identity and authorization protocol built on Ed25519 — for people, IoT fleets and AI agents. No user database, no personal data to leak.
Me2eM is a decentralized identity and authorization protocol built on Ed25519 cryptography and standard key-agreement primitives. Nothing to register, no passwords to store: a person, a device, or an AI agent is represented by keys derived locally from a single seed phrase. Every context keeps its own isolated identity, access is delegated and revoked through signed attestations, and servers confirm a session with a single signature check — serverless authentication with minimal latency that minimizes, or removes entirely, the database you have to run and protect. Me2eM is for one user who safely becomes many: separate profiles (work, home, the gym), hierarchies of IoT devices and drones, autonomous AI agents under signed mandates, E2EE-encrypted channels, and deterministic passwords for third-party services.
Everything derives from the same Ed25519 root — start with the core, add encryption and UI when you need them.
Core primitives for the Me2eM authorization protocol: hierarchical deterministic identities, stateless signed sessions, and parent-signed attestation for delegatable, externally verifiable authorization.
Cryptographic mechanisms for the Me2eM protocol: E2EE channels, X3DH key exchange, purpose-based key derivation, and envelope patterns for offline recipients and media chunk encryption.
React bindings for the Me2eM protocol: identity lifecycle hooks, seed-phrase UX components, session management, and an encrypted per-identity context cache.
Eight properties of the protocol — math, not promises.
Your identity lives in a seed phrase; keys are recomputed on demand. A breached server holds nothing.
Private keys never leave your device. Servers verify signatures without ever learning who you are.
Same seed, same keys — always. One identity on every device, with nothing to sync.
Every Handle is a separate keypair. Compromising one context reveals nothing about the others.
No session database. Any server — or any third party — verifies a token with one signature check.
Attestation chains hand scoped, time-boxed access to partners, IoT devices, and AI agents.
Identity → Handle → SubHandle: a whole device fleet under one root, provisioned offline.
One revoked attestation disables an entire branch — current and future sessions, instantly.
Audited primitives and a lean toolchain — every tile links to its source.
Documented scenarios — people, devices, and AI agents: the same primitives across different domains.
Give an autonomous AI agent its own cryptographic identity and a signed mandate from its owner. One call revokes a compromised agent — across every service it touches.
Sell time-boxed slices of spacecraft resources — EO tasking windows, transponder leasing, downlink capacity. The buyer receives a signed receipt verifiable with your public key alone.
One Me2eM instance lets a user into every application in the ecosystem. The account is a seed phrase: there is no user database — nothing to maintain, leak, or correlate.
One seed, many identities — work, portfolio, home, personal — a separate Handle per context, each with its own keypair. No linking identifier, no user database, deterministic derivation on every device.
Different scenarios use the same primitives to work in very different worlds: autonomous AI agents, a drone fleet, a satellite selling imaging windows, a corporate messenger, and a charging network. None of them requires changing the protocol. One protocol, different use cases.
The blog walks each scenario to a step-by-step tutorial.
Read moreFour use cases, one protocol.
JWT, OAuth and Me2eM solve the same task — authorization. But trust models are fundamentally different: who signs, who does the server trust, and what happens on compromise. A full comparison with code examples.
How a signed token replaces a server session: what's inside, what the verifier checks, how stateless differs from JWT — and why jti rotation makes revocation pinpoint.
A complete breakdown of the deterministic key tree: how 12 words become a hierarchy of identities — Identity, Handle, SubHandle — and why the same seed always yields the same keys.
From first seed phrase to verified session — the quick start covers all three packages, end to end.