In this board, Data Space is a reader-facing term for the data context an application can reason about: which caller is present, which AFS mounts or overlays are available, and which paths are visible through that session.
What exists in code today
| Exists as implementation | Does not exist as a public product surface |
|---|---|
DID Space providers (@aigne/afs-did-space local / Cloudflare) | A DataSpace class, package, or SDK |
CallerInfo and session overlays | A DataSpace configuration file or lifecycle API |
Logical AFS paths such as /user, /tmp, /space | A second backend parallel to DID Space |
CLI arc space against local DID Space data | A separate “Data Space admin” product |
Keep the name at the explanatory layer until a versioned public contract exists.
Mistakes this distinction prevents
- Designing against an imagined
DataSpaceAPI because a product conversation uses the term. - Assuming every DID-scoped path belongs to a single caller-visible session view. The runtime may mount, filter, or reject it according to caller and provider policy.
- Treating ObjectStore layout, SQLite metadata files, or on-disk CID pools as the logical contract. Session and AFS paths are the contract; physical layout is an implementation detail.
How to talk about it
| Prefer | Avoid |
|---|---|
| “the caller's data context” / “session-visible views” | “the Data Space backend” |
| “DID Space provider” for the storage implementation | “Data Space provider” as if it were a package name |
“inspect local DID Space with arc space” | “connect to the Data Space API” |
Use Session data for the verified current views. Use Current contract boundaries before extending this term in public material.