【提案】♻️ uuid 的定义与存储

[Gaubee]

当下，UUID 的逻辑是这样的：

1. 如果 AppContext 没有初始化的 UUID
   1. 查找外部磁盘中是否存在备份
      1. 如果外部磁盘不存在备份
         1. 初始化 UUID 到 AppContext 中保存
         2. 并写入到外部磁盘中进行持久化备份
      2. 如果外部磁盘存在备份
         1. 读取备份信息，并将它恢复到 AppContext 中保存
2. 如果 AppContext 已经初始化过 UUID，那么直接使用该 UUID 信息

   无视外部备份的修改

   未来可以实现 Dweb 备份导出导入的功能

这个方案有几个点值得改进：

1. 目前保存到 AppContext 脱离了 file.std.dweb 的文件体系，未来做备份恢复，或者跨设备同步的时候会存在问题
2. UUID 的保存不该是明文
   1. Dweb 未来作为一个 OS，那么其实是应该有一个本地用户系统
   2. 用户视角里的 UUID，其实应该指代用户自己，而不是用户的手机设备，在更换设备的时候，uuid 应该跟着“用户”走而不是设备。
   3. 基于以上两点，可以构想出未来 UUID 的标准：
      1. 首先用户在启动 dweb-browser 的时候，其实应该是在启动 dweb-os，那么需要初始化用户信息与密钥
         1. 密钥 = 主密钥+pin
         2. 提供一些安全信息，来做主密钥的生成，因此我们需要内置一些常见的问答题目，或者用户可以自定义题目。题目将单独明文存储，而其题目和答案将作为主密钥生成的基础。
         3. 要求用户一个提供易于记忆的 pin 码，来作为安全密码，安全密码的作用是对主密钥进行加密
         4. 如果硬件支持，可以将 pin 码存储在安全的硬件中
         5. 这里务必要提示用户，这里所有的数据不会有任何服务端主动接入进行备份，因此需要用户自己做好备份服务。但是未来可以提供系统级别的备份模块，那么第三方就可以介入帮助用户在云端做备份。
      2. 拥有密钥后，UUID 就有了加密的凭证
         1. 首先 UUID 还是随机生成，这个不可避免，不能使用密钥，因为密钥是用户自己主观意识生成的，不能确保它的唯一性，只能确保它的私密性，因此 UUID 需要随机生成从而确保唯一性
         2. 其次，在保存到外部磁盘的时候，我们需要对 UUID 进行加密存储，避免被别人在外部恶意修改，但是被删除是不可避免的，但至少不会被篡改
3. 还有一个提议值得商榷，我觉得应该把 UUID 存储到“联系人”信息中，这是可以跟着设备联系人备份功能走的，更加容易形成迁移

最后说个题外话，生态内的应用如果要使用 UUID 来作为壁垒，那么就应该为 UUID 赋予价值，最常见的就是提供标准，让第三方平台可以对 UUID 进行实名认证。越多元的标准与这个 UUID 绑定在一起，那么这个 UUID 就越发有价值，就像人的信用一样，需要有一个培养的过程。否则任何优惠业务想基于 UUID 来展开，如果 UUID 自身没有壁垒，没有价值，那么薅羊毛的问题是不可能被解决的。