当应用需要知道「谁在行动」以及「该调用者能看见哪份数据视图」时，使用本 board。先把三个相关概念分开。
术语
| 术语 | 在 ARC 中的当前含义 | 不要说成 |
|---|---|---|
| DID | 主体与已验证调用者上下文的标识；用于给存储划定作用域。 | 客户端字段、UI 文案或路径片段就能完成认证。 |
| DID Space | 具体的 AFS provider 与用户可见的 DID 作用域存储面。 | 挂上 DID Space 就自动拥有完整 AFS 操作集。 |
| Data Space | 用于讨论调用者数据上下文与视图的文档/架构用语。 | 另一套公开 SDK、后端、API 产品或生命周期对象。 |
/user · /tmp · /space | 为单个调用者与 session 组合的、受约束的 AFS 视图。 | 可以直接去碰 ObjectStore、CAS 或 SQLite 内部布局。 |
路径不是授权决定。运行时先解析调用者上下文、构建 session 视图，再由 provider 策略决定应用能否使用数据。UI 可见性、以及路径里恰好出现 DID，都不是权限授予。
各部分如何连接
受信凭据变成 CallerInfo。session 再把调用者专用视图叠在共享的 instance world 上。/user 与可选的 /space 经 DID Space provider 解析；/tmp 是 session 本地临时区。
| 步骤 | 发生什么 |
|---|---|
| 1 | 运行时接受 cookie JWT、Bearer JWT，或 Bearer blocklet-… access key。 |
| 2 | 共享 caller 核心把 connect-service 身份映射为 CallerInfo（did、roles、authMethod、可选 instanceDid）。 |
| 3 | 构造 session 时仅为该调用者挂载 /user、/tmp，以及可选的 /space。 |
| 4 | DID Space provider 在 system 或 user 角色前缀下持久化数据。 |
按任务阅读
| 如果你需要 | 从这里开始 |
|---|---|
| 理解 ARC 对调用者知道什么 | 调用者上下文 |
| 按 DID 作用域存储或挂载数据 | DID 作用域存储 |
| 理解文档用语 Data Space | 这里的 “Data Space” 指什么 |
理解 /user、/tmp、/space | Session 数据 |
本地运行 arc space 检查 | 检查本地空间 |
| 看 DID Connect 如何进入 ARC 运行时 | ARC 中的 DID Connect |
| 查看本 board 明确不承诺什么 | 当前合同边界 |
| 对照指定 ARC release 复验 | 证据与版本边界 |
验证版本
本 board 的操作命令已在隔离的 --root-path 目录下，针对 ARC CLI 2.0.0-beta.28 重新跑过。源码与测试引用对应文档编写时的当前 ArcBlock/arc 树。关于 instance DID 生命周期的架构草稿只作考古材料，不是公开合同。
相关 board
- AFS — provider 合同与挂载语义。
- Blocklets — package 与 instance 工作流。
- AUP — 声明式 UI 与 session 呈现。
- Web Device — 把 AFS 路径做成静态站点。
- arc space — space 子命令完整 CLI 参考。