Concepts
Provider Model
The storage protocol shared by local, IPFS, gateway, cluster, and bridge providers.
Providers are the boundary between MeshKit Core and storage infrastructure. Core owns encryption and client semantics; providers persist encrypted bytes and the workflow metadata needed to retrieve, share, audit, sync, and operate those bytes.
Provider Responsibilities
| Responsibility | Why it matters |
|---|---|
| Raw encrypted bytes | The encrypted envelope or stream chunks identified by CID |
| Proofs | Evidence about provider writes, reads, algorithms, size, and verification |
| Capsules | Share records that let authorized recipients open encrypted content |
| Revocation state | Future-open controls for share capsules |
| Mailboxes | Message and share delivery queues |
| Sync jobs | Durable retry and offline work records |
| Vaults and capabilities | Advanced access-control records |
| Logs and health | Diagnostics, doctor checks, and operational evidence |
Raw byte storage alone is not enough for every MeshKit workflow.
Provider Types
| Provider | Primary use |
|---|---|
LocalDevProvider | Deterministic local tutorials and tests |
HttpIpfsProvider | Kubo/IPFS HTTP-backed encrypted byte storage plus MeshKit metadata endpoints |
HeliaProvider | App-owned in-process IPFS/UnixFS integration for web or mobile-style runtimes |
PinningServiceProvider | Pinning-backed byte durability |
GatewayRetrievalProvider | Retrieval through a gateway with CID verification |
IpfsClusterProvider | Cluster-backed operator infrastructure |
FallbackProvider | Ordered provider failover |
| Filecoin persistence provider | Long-term persistence proof bridge, not direct app storage by itself |
| Lit-like policy provider | Authorization boundary for policy-bound shares |
How Core Uses A Provider
Production Implication
When a guide says "configure a provider," ask which capabilities your workflow needs:
- File storage needs encrypted bytes and proofs.
- Sharing needs encrypted bytes, proofs, capsules, and identity metadata.
- Messages need mailbox records.
- Sync needs durable sync jobs.
- Vaults and capabilities need access-control records.
- Production diagnostics need logs and health checks.
If a provider only stores bytes, features that need metadata must be backed by a MeshKit-compatible metadata service.
Validation Checklist
- Can the provider write encrypted bytes and read them back by CID?
- Does it preserve MeshKit proofs?
- Does it support capsules if sharing is enabled?
- Does it support mailbox records if messages or share delivery are enabled?
- Does it support sync jobs if offline/retry flows are enabled?
- Does
mesh.doctor.run()report healthy checks? - Does the CLI provider validation prove the same environment your app uses?