Architecture
ADRs
Architecture decision records for MeshKit.
Architecture decision records explain why MeshKit behaves the way it does. They are maintainer evidence, not a first-stop onboarding guide.
Use ADRs when a product, provider, security, package, or release decision needs a stable rationale that future contributors can audit.
Decisions Worth Recording
| Decision type | Examples |
|---|---|
| Product boundary | SDK-first product, not a hosted storage service |
| Crypto profile | Envelope algorithms, authenticated metadata, migration plan |
| Provider strategy | Local-dev, IPFS HTTP, Helia, Filecoin bridge, policy provider |
| Identity model | App-level identities, contacts, proof adapters, recovery |
| Runtime support | Web, Node, React Native, Ionic, mobile key-vault limits |
| Release governance | Package naming, version compatibility, deprecation policy |
| Documentation IA | Public docs versus maintainer/release evidence |
ADR Template
# ADR XXXX: Title
## Status
Accepted | Superseded | Proposed
## Context
What problem forced this decision?
## Decision
What are we doing?
## Consequences
What tradeoffs, limits, and follow-up work does this create?
## Evidence
Which tests, scripts, docs, or source files support the decision?Review Rules
- Keep status current.
- Link to validation evidence when the decision affects production claims.
- Separate implemented behavior from roadmap behavior.
- Update docs when ADRs change user-facing behavior.
- Do not use ADRs to hide information that belongs in public concepts or guides.