We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
这是讨论前曽做的草案:
最终结论认为: 表设计大致据此行事:
总共应该是三个表 IM Uid 到 UUID 映射表:IM Uid | UUID 角色卡表:UUID | 卡ID | 是否群组卡 | 卡数据 绑卡表: UUID | 群ID | 卡ID
当用户建立多平台绑定后,主id从IMUserId转为一个虚拟ID(即表中的uuid,也可能使用nanoid等方案进行生成)进行角色关联绑定。 虚拟id只作为本地使用 如果未来实现云人物卡,那么届时也不会向服务器提交虚拟id,而是全部的imuserid 此外,论证了一些骰主作为可信赖终端的不足,以及安全方面的风险。最好由用户自己发指令声明自身的身份(需要注册),然后获得token,尽管仍然存在些许中间人攻击的风险,但安全性还是大大提高了。
The text was updated successfully, but these errors were encountered:
关于云任务卡的部分, 或许可以与在线公骰统计一起完成 #230
Sorry, something went wrong.
feat: 初步的表结构和类设计,基本上符合 #278
a5b2e1c
No branches or pull requests
在提问之前...
说说你遇到的问题?
有什么好的想法?
这是讨论前曽做的草案:
最终结论认为:
表设计大致据此行事:
总共应该是三个表
IM Uid 到 UUID 映射表:IM Uid | UUID
角色卡表:UUID | 卡ID | 是否群组卡 | 卡数据
绑卡表: UUID | 群ID | 卡ID
当用户建立多平台绑定后,主id从IMUserId转为一个虚拟ID(即表中的uuid,也可能使用nanoid等方案进行生成)进行角色关联绑定。
虚拟id只作为本地使用
如果未来实现云人物卡,那么届时也不会向服务器提交虚拟id,而是全部的imuserid
此外,论证了一些骰主作为可信赖终端的不足,以及安全方面的风险。最好由用户自己发指令声明自身的身份(需要注册),然后获得token,尽管仍然存在些许中间人攻击的风险,但安全性还是大大提高了。
其他内容
先进行新版表结构的实现 (1.4.0 - 1.5.0)将数据迁移至dicescript格式,但仍然保留rollvm v1,使用兼容层读写数据 (1.4.0 - 1.5.0)在新的api下重新实现pc指令,并实现跨平台绑卡 (1.4.0 - 1.5.0)提供 rollvm v1 -> rollvm v2 迁移辅助The text was updated successfully, but these errors were encountered: