wangshijun
commented
1 year ago 一个最新思路是我们有了 did storage 之后，我们可以设法：
- 以当前用户的 did storage 提供的一个后端授权为基础，在所有支持相同协议的网站之间以此为信息交换中介 （过去需要通过浏览器或插件的支持）
- 每一个开启了此支持的 did-connect 部件和其背后的relay 负责和当前用户的did storage通信
"所有支持相同协议“ 里面的协议具体是什么协议？应用和 DID Storage 之间相互信任的协议？谁来决定 DID Storage 信任哪些应用？另外，我们的技术实现中 Blocklet 软件和 Blocklet 实例不是一回事，DID Storage 可能知道某个 Blocklet 软件的存在，但是不知道某个 Blocklet 实例的存在？这个区别如何体现在”协议中。
还是说你上面的描述只是想解决：用户来到我们的网站上，比如 Store、Launcher、Storage 等服务间跳转时 Profile 自动获取的问题？但是目前钱包的 DID 实现是每个 Blocklet 实例生成的 DID 不同，如果这个环节少了钱包，DID 的生成无从谈起。
mave99a
NateRobinson
skypesky
linchen1987
痛点：
太多不同的域名和DID下的站点，每一个都需要重新连接钱包认证， 无论如何实现，这个体验都不好。
理想中，一群可信任的站点，用户只需要一次连接，就可以通行所有的站点，仅当需要执行关键的操作才需要连接钱包。
现在的服务，例如Google，可以用自己的account一票通行自己所有的服务。 过去 Facebook connect 流行的时候，所有的Facebook connect授权过的站点都能一票通行，这个使用体验是非常优秀的。
困难
过去似乎完美的解决方案只有实现自己的浏览器或者在浏览器上使用特定插件。 但这些都会影响用户体验。
另一个思路是有一个属于自己的app shell，访问其他人的服务，实际上都在自己的shell 下进行，这样实际上相当于不存在跨域访问。（这个思路在这里讨论：
上述两个方案都不理想，前者需要有新浏览器或安装插件，用户onboard成本过高。 后者可能实现困难，并且对UX 体验有限制，尤其可能会因此限制应用本身的个性化程度，以及降低别的网站的访问量，用户对这种方式提供访问的积极性不高。
解决方案
一个最新思路是我们有了 did storage 之后，我们可以设法：
这个动作仿佛用户把自己的一个专业的u盘授权插入了被访问的站点，这个站点从此盘里获得必要的信息，并且写入和这个站点相关的信息。
达到的效果
用户可以一次确认后，在各个不同的网站上畅通无阻，各个网站能立刻识别当前的用户，并把这个用户在这个网站上的个性话数据 （例如配置、comment 等）直接写入用户自己的storage。 达到非常好的用户体验。
局限
只有使用did-connect 并且使用我们的平台的应用才有可能实现互通。
安全性
用户可以自己 opt out这种跨域方式，这样支持跨域的did connect 无法获得任何信息，也不会开启这个过程
用户第一次到一个新的网站（新的DID）的时候，did connect 会提示用户授权 （这个授权可以做到需要或不需要钱包，根据用户的安全设置），只有被授权了的did，才有可能连接这个用户的 storage
用户可以在自己的管理界面立刻revoke 访问权力，清除数据等。
对方站点的bug 或恶意滥用风险，比如大量写入数据或者写入垃圾恶意数据等
隐私
这种方式有可能会让DID 的隐私一定程度上下降，但是否如此以及如何规避待具体思考。主要原因是，既然用户不需要每个站点登陆，那么这个用户用于连接的DID 以及profile 可能在多个站点之间会被获知。