Identity And Sharing
Recipient keys, capsules, and trust boundaries.
MeshKit identities are application-level encryption identities. They are not automatically emails, accounts, wallets, DIDs, passkeys, or phone numbers. Your application decides how to bind a MeshKit identity to a user, device, contact, or external proof.
Sharing depends on those identities because a share capsule wraps an encrypted object's data key for recipient public keys.
Identity Model
| Concept | Meaning |
|---|---|
| Local identity | A key pair MeshKit can use to encrypt, decrypt, sign, or unwrap locally |
| Identity vault | Local storage for identity records and exported/imported identity material |
| Contact | An application-trusted recipient public key record |
| Directory | A provider or service that can publish and resolve public identity records |
| Proof adapter | An app-level binding to a DID, passkey, wallet, or other proof system |
| Recovery envelope | App-managed backup material used to restore an identity |
The MeshKit client can create, export, import, publish, and resolve identities. Production apps need a contact and verification story around those operations.
Sharing Flow
The capsule does not contain plaintext. It contains enough information for an authorized recipient identity to unwrap the data key and open the encrypted object.
What Can Block Opening
MeshKit fails closed when:
- the recipient identity is not available
- the capsule is missing
- the capsule expired
- the capsule was revoked
- policy provider authorization is required and missing
- vault membership is required and missing
- a capability token is required and missing
- the encrypted bytes do not match the expected CID
Revocation Boundary
Revocation is a future-open control. It prevents later MeshKit opens through the capsule. It cannot erase plaintext already decrypted into an application process, copied to a device, written to another system, or cached outside MeshKit.
Production Decisions
Before using sharing in production, decide:
- How users and devices get MeshKit identities.
- How contacts are verified before sharing.
- Whether public keys are resolved from a directory, app database, DID, passkey, wallet, or another proof adapter.
- How identity export, recovery, and lost-device flows work.
- What revocation means in your product language.
- Whether shares need policy provider, vault, or capability checks.
API Starting Points
await mesh.identity.create("alice");
await mesh.identity.export("alice");
await mesh.identity.import(record);
await mesh.identity.publish("alice");
await mesh.identity.resolve("alice");
const capsule = await mesh.share.file(file).with("alice");
const opened = await mesh.share.openCapsule(capsule, { as: "alice" });Common Mistakes
- Treating an identity string like an email address without verifying the public key behind it.
- Sharing before the recipient key exists or can be resolved.
- Promising revocation erases already downloaded content.
- Logging exported identity records or private key material.
- Assuming a mobile key vault is non-exportable without checking the runtime bridge.