在本 board 中，Data Space 是面向读者的术语，用来描述应用可以推理的数据上下文：当前有哪个调用者、有哪些 AFS 挂载或叠加可用，以及通过该 session 可见哪些路径。
今天代码里有什么
| 作为实现存在 | 不作为公开产品表面存在 |
|---|---|
DID Space provider（@aigne/afs-did-space local / Cloudflare） | 名为 DataSpace 的 class、包或 SDK |
CallerInfo 与 session 叠加 | DataSpace 配置文件或生命周期 API |
/user、/tmp、/space 等逻辑 AFS 路径 | 与 DID Space 平行的第二套后端 |
针对本地 DID Space 数据的 CLI arc space | 独立的 “Data Space 管理” 产品 |
在出现已版本化的公开合同之前，把这个名称留在解释层。
这一区分避免的错误
- 因为产品讨论用了这个词，就去对接想象中的
DataSpaceAPI。 - 假定每条 DID 作用域路径都属于某一个调用者可见的 session 视图。运行时可能按调用者与 provider 策略挂载、过滤或拒绝。
- 把 ObjectStore 布局、SQLite 元数据文件或磁盘上的 CID 池当成逻辑合同。session 与 AFS 路径才是合同；物理布局是实现细节。
怎么说
| 优先 | 避免 |
|---|---|
| “调用者的数据上下文” / “session 可见视图” | “Data Space 后端” |
| 用 “DID Space provider” 指存储实现 | 把 “Data Space provider” 说成包名 |
“用 arc space 检查本地 DID Space” | “连接 Data Space API” |
已验证的当前视图见 Session 数据。在公开材料中扩展该术语之前，先读 当前合同边界。