关于新角色卡存取机制的草稿

[fy0]

在提问之前...

• 我填写了简短且清晰明确的标题，以便开发者在翻阅 issue 列表时能快速确定大致问题。而不是“一个建议”、“卡住了”等
• 我基本确定这是一个新功能/建议，而不是遇到了 bug（不确定的话请附上日志）

说说你遇到的问题？

• 迁移至dicescript
• 支持多平台共享人物卡
• 重构读取用户数据部分，并简化流程

有什么好的想法？

这是讨论前曽做的草案：

最终结论认为：
表设计大致据此行事：

总共应该是三个表
IM Uid 到 UUID 映射表：IM Uid ｜ UUID
角色卡表：UUID ｜ 卡ID ｜ 是否群组卡 ｜ 卡数据
绑卡表： UUID ｜ 群ID ｜ 卡ID

当用户建立多平台绑定后，主id从IMUserId转为一个虚拟ID(即表中的uuid，也可能使用nanoid等方案进行生成)进行角色关联绑定。
虚拟id只作为本地使用
如果未来实现云人物卡，那么届时也不会向服务器提交虚拟id，而是全部的imuserid
此外，论证了一些骰主作为可信赖终端的不足，以及安全方面的风险。最好由用户自己发指令声明自身的身份(需要注册)，然后获得token，尽管仍然存在些许中间人攻击的风险，但安全性还是大大提高了。

其他内容

1. 先进行新版表结构的实现 (1.4.0 - 1.5.0)
2. 将数据迁移至dicescript格式，但仍然保留rollvm v1，使用兼容层读写数据 (1.4.0 - 1.5.0)
3. 在新的api下重新实现pc指令，并实现跨平台绑卡 (1.4.0 - 1.5.0)
4. 服务器合规化 (1.4.0 - 1.5.0)
5. 提供 rollvm v1 -> rollvm v2 迁移辅助
6. 用户服务 (1.5.1 +)
7. 在线车卡 (1.5.1 +)
8. 卡绑定 (1.5.1 +)
9. 移除rollvm v1支持(2.0.0)

[Xiangze-Li]

关于云任务卡的部分, 或许可以与在线公骰统计一起完成 #230