OpenE2EE Relay
Identity and authentication
Development identity, production providers, and the authority boundary for every Relay request.
Relay authorizes each request from verified credentials. A user ID, device ID, provider subject, organization, project, or environment sent by a client is never authority by itself.
Development first
Device-owned identity is the shortest path to the first managed message. It is development-only. The device proves possession of its local identity, and the resulting scope cannot cross into production.
Production provider order
Production onboarding presents Clerk and Firebase first. They are the clearest common paths for TypeScript applications. You can select another provider before activation:
- generic OIDC/JWKS.
- Auth0, Supabase, Cognito, WorkOS, or Okta through their OIDC/JWKS surface.
- a Convex upstream provider.
- a custom-token verifier that your backend owns.
These advanced paths require you to define issuer, audience, subject mapping, key rotation, revocation, and migration behavior.
Provider migration
A provider change is an authenticated account transition, not a new account. Relay binds the old and new verified subjects to one canonical account and one recovery generation. The migration cannot adopt another account, reuse an expired assertion, or keep two active provider authorities after completion.
What identity does not do
Authentication does not move private keys to Relay. Device identity keys, sessions, ratchets, safety-number state, and recovery secrets stay under the SDK's device-side storage contract. Relay stores public key material and the routing metadata required to deliver ciphertext.