# DID Web5 Local ID FAQ ## Metadata **Status**:: #x **Zettel**:: #zettel/fleeting **Created**:: [[2025-06-27]] ## 应用里 Local ID 可以使用 did:plc: 前缀吗？ 可以。Local ID 因为不需要全局共识，想怎么用由应用自己决定： - 可以使用 `did:plc:` 前缀也可以使用 `web5:plc` 前缀 - 可以使用 PLC Directory 也可以使用自己运行的 PLC 私服 从 did:web5 的角度，只是提供了一种密码学可验证的方式建立 Local ID 到 DID Web5 的双向链接。Local ID 之前在哪里，怎么使用的 DID Web5 不关心，链上的合约也没有办法验证这些信息。 ## Local ID 到 DID Web5 的索引一定要通过同步 CKB 链建立吗？ 不需要。Local ID 是用户在某个应用里使用的未上链的身份标识。如果这个用户想上链，要么是通过应用来上链，要么是上链后通知应用这个 Local ID 已经上链了。所以索引完全可以是在应用内通过用户输入来建立。用户在应用里执行上链并成功之后，或者用户通知应用上链然后应用验证通过之后，应该在数据库上记录一下即可。对于用户上链又不通知应用的场景，应用继续使用原来没上链的 DID Document 是可以接受的行为。 基于以上分析，其实 Local ID 和 DID Web5 Identifier 是不是一样就没那么重要了。 - Local First 的应用，统一都只使用 Local ID 的 Identifier，可以是 `did:plc:` 也可以是 `web5:plc:`。用户上链应用必须知道并在数据库中记录，记录后的 Local ID 的解析会重定向到保存在 CKB 链上的版本。 - DID First 的应用，就没有 Local ID 的存在了。 ## Local First 应用上链后怎么更新 DID Document? 取决于上链后 Lock Script 是怎么，由谁所有。如果是 App 运营方所有，那可以继续使用 PLC operations 进行更新，定时同步到 CKB 链上。 如果是用户所有，链上更新就需要拉起用户钱包进行验证。可以做成 git stage 类似的方式，应用内还是通过 PLC operations，然后提醒数据还没有同步的链上，点击同步到链上再执行打包和提交交易的操作。 ## Local ID 上链后每次都要去实时去链上查询吗？ 不一定，取决于是否能接受 DID Document 更新一定时间的延迟。其实实时去查，在返回之后也不保证是最新版本了。所以应用也可以做成本地优先，定时去比较链上和本地数据，如果有差异的话提醒用户要选择哪个版本。