在钱包里管理域名、存储与应用访问
打开一个应用，选择它要使用的存储空间。给网站配置域名，用钱包证明自己有权使用它。进入需要资格的应用，出示相应的 Passport。这几件事，在 ArcBlock 的产品里采用了相近的交互方式：应用发出请求，用户从 DID Wallet 中选择相关对象，再确认这次使用。
这个设计让钱包成为资源的操作入口。用户拿在手里的，是自己与资源之间可以验证的关系。存储、域名和应用访问各自有不同的服务规则，钱包让这些关系能够以相近的方式被识别、出示和使用。
要理解它，从连接一个 DID Space 开始就够了。
选择应用要连接的空间
在支持 DID Spaces 的 Blocklet 应用里，用户可以通过 DID Wallet 发起连接。钱包展示相关的 NFT，用户选择目标空间并确认。连接完成后，应用能够获得这个空间的名称、DID 和服务地址等信息，用来识别并连接相应的服务。
《可复用的 DID Space 组件》展示了这个过程。它也提供另一条入口：先输入空间的 gateway 地址，也就是应用连接该空间的服务入口，再由钱包展示对应的 NFT。一个用户有多个空间时，先指定目标可以减少选择错误。
这一步解决的是非常具体的问题：这个应用接下来要用哪一个空间？
空间可以用于应用备份，也可以用于应用业务数据；产品中还有会话层面的空间连接。用途不同，后续的数据访问方式也可能不同。选择空间把用户的意图带进了连接过程，而不是让应用自行猜测。
这里有一个容易忽略的边界。建立连接，说明应用已经确定要访问的空间，并完成相应的连接流程。应用到底能读取哪些数据、写入哪里、执行什么操作，仍然取决于服务的授权规则。一次“连接”不能被理解为把空间里的所有数据都交给应用。
钱包里的对象，要能对应到真实服务
用户在钱包里看见的是一项可以选择的对象。真正的文件由 DID Space 存储，应用通过空间的服务入口读写数据。NFT 帮助系统识别资源及相关使用关系，钱包负责展示对象、处理证明和签名，资源服务负责实际执行。
把这几个职责分开，界面才不会制造误解。
假设用户已经选中一个空间，后续写入却失败了。这个失败可能来自额度不足、订阅过期、版本不兼容，也可能只是网络暂时不可达。它们需要不同的处理方式。再次出示 NFT 并不能增加存储额度，反复连接也不能修复服务版本问题。
DID Space 连接组件因此会显示连接状态，并区分额度、订阅、版本和网络等异常。这样的反馈属于资源管理的一部分：用户需要知道自己有权使用什么，也需要知道对应的服务此刻能否完成工作。
同样，NFT 仍在钱包里，并不表示服务每时每刻都可用。资源的持有状态、操作权限和服务运行情况，是三个需要分别判断的问题。好的产品体验会把差别说清楚，让用户知道下一步应该处理哪里。
域名也是这样连接到应用的
域名让这个模型更容易看懂，因为它把熟悉的互联网资源和钱包操作连在了一起。
在 Blocklet 中配置已有的 DID Domain 时，用户输入域名，通过 DID Wallet 出示对应的 NFT，系统完成相应的配置流程。域名使用文档展示了应用启动阶段和控制台中的两种入口。用户关心的事情是：把这个域名用于这个应用。钱包把使用资格带到请求发生的地方。
这套方式也能连接已有的域名体系。DID Names 的域名托管流程支持托管在其他注册商注册的域名。域名完成相应的托管设置后，用户获得可在 Blocklet 平台使用的 NFT。原有的域名、DNS 服务以及应用配置由此建立联系。
但这些关系不能合并成一句模糊的“拥有域名”。在注册商处持有域名、由 DID Names 提供托管，以及把域名配置给一个应用，是不同的事情。出示 NFT 证明平台所需的使用资格，并不会自动完成第三方注册商处的域名所有权转移。
这恰恰说明资源映射为何有用：它不要求每种资源抛弃已有的服务体系。域名继续通过 DNS 工作，应用仍需要正确配置。钱包提供一个可以验证相关资格、发起配置的入口。
出示 Passport，发生了什么？
存储和域名让钱包连接到服务资源，Passport 则把同样的交互用于访问资格。
一个应用可以通过 DID Connect 请求符合条件的 NFT 或 VC。用户在钱包里查看请求；如果有多个符合条件的对象，就选择这次要出示的一个。应用收到相关证明后，再按自己的规则决定是否允许继续。
DID Wallet 的出示文档特别说明：出示 NFT，不会把 NFT 发送给应用。
这个区别很实际。证明自己持有某项资格，不需要把资格本身交出去。用户完成的是一次出示，应用完成的是一次核验。涉及转移的操作具有不同的含义，需要按资源本身的规则另行执行，不能混在同一个含糊的确认里。
资格的范围也很重要。某张 Passport 可以满足某个应用的准入条件，但不能据此推导出对其他应用、其他资源的管理权。DID Connect 的请求机制允许应用指定所需对象的类型和认可的签发者，核验因此有了明确的对象。
对用户而言，理想的体验是看得懂这次请求：谁在请求，准备使用哪项资格，以及确认后要完成什么。底层证明可以很复杂，用户做出的选择应当具体。
从展示资源，到发起操作
钱包里的资源如果只能看，用户仍然需要自己寻找每个服务的管理入口。NFT Actions 把与资源相关的操作带到对象旁边，让用户从钱包中查看资源状态、发起相应操作。
这里的“操作”跟随资源类型和权限。存储空间有存储服务的操作，域名有域名的操作，访问资格则受对应应用规则约束。钱包不需要把它们假装成同一种资源；它需要让用户看见自己选中了什么，以及这项资源允许发起什么请求。
发起请求之后，工作仍由服务端完成。钱包处理用户确认及相关签名，服务核验权限与当前状态，再执行允许的操作。这样的分工，让钱包可以成为统一入口，同时保留不同服务的专业能力。
对于支持转移或授权的资源，同样需要准确表达操作后改变的关系。出示证明、允许应用使用，以及把某项可转移权利交给另一位持有者，产生的结果不同。不能因为它们都从钱包发起，就使用同一种含糊的“确认”。
用户带着资源关系进入应用
从 DID Space 到域名，再到 Passport，重复出现的动作是：用户选择与当前任务有关的对象，把可验证的关系带给应用，由服务据此完成允许的工作。
它改变了资源进入应用的方式。应用可以请求用户已经持有的资源或资格；用户则能在请求发生时，明确选择这次要使用哪一项。底层的存储、DNS 和访问控制仍然各司其职。
这也是 DID Wallet 作为资源入口的意义。钱包帮助用户回答“我可以使用什么，以及这次要让哪个应用使用它”，服务负责回答“这个请求现在能否执行”。两边都把自己的事情做好，钱包里的一项 NFT 才会成为用户能够实际使用和管理的资源关系。