Identity and storage have different jobs. A verified caller context describes who made a request and which role the runtime resolved. A DID Space is an AFS provider that exposes storage within a DID-scoped logical space. Data Space is the name this board uses when discussing the resulting data context from a developer's point of view.
Do not collapse those roles into one object:
| Concern | Object in ARC | Public surface today |
|---|---|---|
| Who is calling | CallerInfo after credential resolution | Runtime handoff into session and AFS context |
| Where durable data lives | DID Space (@aigne/afs-did-space) | AFS mount + local arc space inspection |
| What a session can see | Session overlays /user, /tmp, optional /space | Session-constrained AFS paths |
| How docs name the whole context | Data Space (term only) | No separate importable API |
The caller may be authenticated without receiving a particular mounted data view. A storage path may be present without allowing a network-origin read or write. A product term may be useful for explanation without being a stable API.
Child pages
- Caller context — verified identity, credentials, roles, membership overlay.
- DID-scoped storage — provider package, role prefixes, transport capability differences.
- What “Data Space” means here — deliberately narrow documentation use of the term.
After the core model, read Session data for the views a session actually receives, then Current contract boundaries before shipping assumptions.