Use this board when an application needs to know who is acting and which data view that caller may receive. Keep three related ideas separate.
Terms
| Term | Current meaning in ARC | Do not say |
|---|---|---|
| DID | An identifier for subjects and for verified caller context; used to scope storage. | A client field, UI label, or path segment authenticates a caller. |
| DID Space | A concrete AFS provider and user-visible storage surface for DID-scoped data. | Mounting a DID Space automatically exposes the full AFS operation set. |
| Data Space | A documentation and architecture term for a caller's data context and views. | A separate public SDK, backend, API product, or lifecycle object. |
/user · /tmp · /space | Session-constrained AFS views composed for one caller and session. | An invitation to poke ObjectStore, CAS, or SQLite internals. |
A path is not an authorization decision. The runtime resolves caller context, builds the session view, and applies provider policy before an application can use data. UI visibility and a path that happens to contain a DID are not permission grants.
How the pieces connect
Trusted credentials become CallerInfo. The session then overlays caller-specific views on a shared instance world. /user and optional /space resolve through a DID Space provider; /tmp is session-local scratch.
| Step | What happens |
|---|---|
| 1 | Runtime accepts cookie JWT, Bearer JWT, or Bearer blocklet-… access key. |
| 2 | Shared caller core maps connect-service identity to CallerInfo (did, roles, authMethod, optional instanceDid). |
| 3 | Session construction mounts /user, /tmp, and optionally /space for that caller only. |
| 4 | DID Space provider stores persistent data under role prefixes system or user. |
Read by task
| If you need to | Start here |
|---|---|
| Understand what ARC knows about a caller | Caller context |
| Store or mount data scoped to a DID | DID-scoped storage |
| Understand the documentation term Data Space | What “Data Space” means here |
Understand /user, /tmp, and /space | Session data |
Run local arc space inspection | Inspect local spaces |
| See how DID Connect enters the ARC runtime | DID Connect in ARC |
| Check what this board deliberately does not promise | Current contract boundaries |
| Re-verify against a named ARC release | Evidence and version boundaries |
Verified on
Operational commands on this board were re-run against ARC CLI 2.0.0-beta.28 in an isolated --root-path directory. Source and test references use the current ArcBlock/arc tree checked at documentation time. Architecture drafts about instance DID lifecycle remain archaeological, not public contracts.
Related boards
- AFS — provider contract and mount semantics.
- Blocklets — package and instance workflow.
- AUP — declarative UI and session presentation.
- Web Device — AFS paths as static sites.
- arc space — full CLI man page for space subcommands.