Runtimes
Runtimes
Runtime adapters that bind MeshKit Core to app environments.
Runtime packages adapt MeshKit Core to the environment your app runs in. They do not replace Core or change the envelope/provider model.
Choose a runtime when platform capabilities matter: key storage, file streaming, background work, filesystem access, IndexedDB, service workers, native bridges, or environment-based provider config.
Runtime Chooser
| Runtime | Package | Best for | Main caveat |
|---|---|---|---|
| App facade | @meshkit/meshkit | Most app features and local quickstarts | Uses default local-dev behavior unless configured |
| Node | @meshkit/node | Servers, workers, CLIs, integration tests | Process memory is not a durable key vault by itself |
| Web/PWA | @meshkit/web | Browser apps and service-worker-aware clients | Do not expose unrestricted Kubo RPC to browsers |
| React Native | @meshkit/react-native | Native mobile apps with bridge hooks | Native bridge availability decides key-vault strength |
| Ionic/Capacitor | @meshkit/ionic | Hybrid apps with Capacitor secure storage | Browser fallback is weaker than native secure storage |
Same Product Model
Every runtime still follows the same MeshKit flow:
plaintext in app runtime
-> MeshKit Core
-> encrypted envelope
-> provider stores encrypted bytes and metadata
-> app stores CID, proof, capsule, message, or job identifiersWhat Runtimes Change
| Capability | Why it differs |
|---|---|
| Key storage | Web, Node, React Native, and Ionic have different secure storage primitives |
| File access | Node has filesystem access; browsers and mobile apps depend on platform APIs |
| Streams | Runtime stream types and memory pressure differ |
| Background sync | Service workers, mobile background tasks, and server workers have different lifecycle rules |
| Provider config | Browsers/mobile should not receive privileged provider tokens for operator services |
| Native bridge | React Native and Ionic features depend on installed native modules |
Production Questions
Before selecting a runtime, answer:
- Where are identity records stored?
- Are keys exportable or non-exportable in this runtime?
- Can this runtime safely reach the provider endpoint?
- Is background work caller-managed, service-worker-managed, or native-managed?
- Can this runtime stream large files without loading them fully into memory?
- How are provider tokens kept away from public clients?