Identity and trust

The JavaScript profile uses one composite identity per (userId, identityType), provisioned across linked devices. Registration identifiers, prekeys, and sessions remain device-specific.

CompositeIdentityV1 =
    version
 || X25519 algorithm tag
 || X25519 public key
 || Ed25519 algorithm tag
 || Ed25519 public key

The complete canonical tuple—not either component by itself—is the identity trust object. A domain-separated commitment is derived locally for comparison and transcript binding.

First contact

First contact establishes an explicitly unverified trust-on-first-use record. It does not claim authenticated identity.

Authenticated comparison can happen through a safety number or another application-provided trust mechanism. Substituting either identity component changes the commitment and produces a mismatch.

Existing trust

Once a composite identity is pinned:

• replacing either component fails against the trusted commitment;
• cached or supplied commitment mismatches are rejected before mutation;
• rotation requires an explicit trust decision;
• rollback to an older tuple is detectable.