Security
Revocation
What MeshKit revocation can and cannot guarantee.
Revocation changes future access checks. It does not erase already decrypted plaintext, remove every IPFS block from every peer, or claw back a data key that a recipient already used.
Use this page to set correct product, security, and compliance expectations.
What Revocation Blocks
MeshKit can block future opens when:
- a share capsule has been revoked
- a capability token has been revoked
- a policy provider denies access
- vault membership no longer includes the opener
- a capsule has expired
The check happens before MeshKit unwraps the key and decrypts content.
What Revocation Cannot Do
Revocation cannot:
- erase plaintext already returned to application code
- delete copies a recipient saved elsewhere
- remove all IPFS blocks from every node or gateway cache
- revoke screenshots, exports, downloads, or logs outside MeshKit
- turn a previously exposed secret back into a secret
Capsule Revocation
const capsule = await mesh.share.file(file).with("alice", {
expiresIn: "7d",
});
await mesh.share.revoke(capsule.id);
await mesh.share.openCapsule(capsule, { as: "alice" }); // throws share_revokedDesign Guidance
| Product language | More accurate wording |
|---|---|
| "Delete shared content from the recipient" | "Stop future opens through MeshKit" |
| "Remove the file from IPFS" | "Unpin or garbage-collect where your provider controls retention" |
| "Revoke all access" | "Revoke future MeshKit-mediated access" |
| "Recall a message" | "Block future opens if the recipient has not already opened or copied it" |
Operational Checklist
- Persist capsule IDs so you can revoke them.
- Persist revocation events for audit.
- Pair revocation with policy or capability checks for stronger future-open control.
- Communicate limits clearly in user-facing UI.
- Do not log decrypted content while investigating revocation issues.