[讨论] DID-Connect 的 传统login，wallet-connect等的fallback支持

[mave99a]

两个设想：

• 可以fallback 用传统login方式 （passport，social login）能兼容部分did connect
• 可以用wallet connect / metamask 方式 能部分兼容 did connect

主要的考虑是用户adoption 和转化。 如果用户必须先下载did wallet，那么会有部分用户不能转化而直接流失。 如果能让这些人先on-board，那么可以慢慢转化。

另外有一个问题是 DID Space 和 DID Wallet 有 chicken & egg 的问题， 我倾向于让did space能有fallback 访问机制，从did space里 boot 出钱包的使用。 这种fallback 访问机制基本只能是密码方式。

• https://github.com/ArcBlock/did-storage/issues/80

这也是一个难题，我们需要讨论。

[FireTable]

传统 login 方式, 我觉得这个支持起来很不错

• 因为我觉得我们有这样一个这么好的应用平台, 除了 web3 这条大赛道外, 其实随时都能扩展出 web2 的小赛道
  • 我们的有些应用, 也只是用到钱包登录而已?
• 但是要看看 老冒 的想法, 会不会有人说我们不纯净了...

如果实现 传统login方式, 应该要区别一下 Blocklet DID-Connect 类别

• 钱包授权 ( 数据/应用逻辑, 严重依赖链上数据的, 类似于 Wallet Background )
• 传统 login ( 数据/应用逻辑, 不依赖链上数据的, 类似于 NFT Blender )
• hybird (数据/应用逻辑, 部分依赖链上数据的, 类似于 NFT Maker )

理想中, 用户体验了我们的样板间应用后, 如果对链上内容好奇的话, 确实就会带来钱包转化

[mave99a]

这个我觉得最合适的是在两个可能的地方来支持：

• did connect ： 增加一种connect 方式
• did spaces： did spaces里自己定义自己的passpord验证，类似 /etc/passed 的设计

为什么在spaces里，应为spaces 和钱包关系并列，有鸡和蛋的问题，必须再其中一个地方让其自包含，spaces感觉更为合理。