MeshKit

MeshKit Docs

Encrypted IPFS-ready storage for application developers.

MeshKit is a TypeScript SDK for encrypted app storage on IPFS-ready providers. Your application stores files or records, receives CIDs and proofs, and can share access with recipient identities without handing plaintext to the storage layer.

Start with the SDK facade unless you already know you are building provider infrastructure, runtime bridges, CLI workflows, or agent tools.

First Path

Use this route when you want the shortest working path:

  1. Install @meshkit/meshkit.
  2. Create a client with the local development provider.
  3. Store and read one encrypted object.
  4. Learn the mental model: envelope, CID, proof, provider, identity, capsule.
  5. Choose a runtime and production provider profile.
import { meshkit } from "@meshkit/meshkit";

const mesh = await meshkit();

const saved = await mesh.files.put("notes/intro.txt", "MeshKit encrypts before storage.", {
  contentType: "text/plain",
});

const opened = await mesh.files.get(saved.cid);

console.log(saved.cid, await opened.text());

That snippet proves the core contract: plaintext enters your app client, MeshKit encrypts it, the provider stores encrypted bytes, and your app keeps the returned CID for later retrieval.

Choose Your Track

You need to...Start hereWhy
Add encrypted storage to an appSDKOne import, local development defaults, files, records, sharing, and sync
Understand the product modelCore conceptsEnvelopes, providers, metadata, identities, CIDs, and proofs
Configure production infrastructureProvider setupLocal-dev is not production; providers need explicit byte, metadata, retrieval, policy, and persistence boundaries
Pick a runtimeRuntimesNode, Web/PWA, React Native, and Ionic have different key storage, streaming, and background behavior
Diagnose a project from the terminalCLIDoctor checks, local sandbox commands, provider tests, Filecoin checks, and policy audits
Expose MeshKit to an agentMCPNarrow, schema-checked tools for files, inspection, identity creation, and sharing
Look up exact APIsCore referenceFull client namespaces, types, configuration, and error codes

Product Mental Model

Application plaintext
-> MeshKit client
-> encrypted envelope
-> provider stores encrypted bytes
-> metadata, proofs, capsules, logs, and sync records support workflows
-> app stores CID, proof, capsule, job, or message identifiers
-> authorized identity opens the data later

Keep these boundaries clear:

  • MeshKit is an SDK and provider contract, not a hosted storage service.
  • local-dev is for tutorials, tests, and deterministic development. It is not durable production storage.
  • A stock IPFS node or gateway stores and retrieves bytes; MeshKit production workflows also need MeshKit-compatible metadata for proofs, capsules, mailboxes, sync jobs, and policy records.
  • MeshKit identities are application-level encryption identities. They are not automatically email addresses, wallets, DIDs, or passkeys.
  • Revocation blocks future MeshKit opens. It cannot erase plaintext that an application already decrypted and exposed.
  1. Install
  2. SDK Quickstart
  3. Files
  4. Records
  5. Identity and sharing
  6. Choose a runtime
  7. Production setup
  8. Troubleshooting

Production Boundary

Do not treat a successful local quickstart as production readiness. Before shipping:

  • Choose a runtime package or facade pattern that matches your app.
  • Replace the local development provider with an explicit provider configuration.
  • Decide where encrypted bytes, metadata, retrieval, policy decisions, persistence proofs, and logs live.
  • Keep provider tokens and private keys out of source control.
  • Run CLI or live-provider validation and keep the output as evidence.

Where To Go Next

If you are new, continue with Install. If you already have a local proof of concept and need production infrastructure, jump to Production setup.

On this page