2020年5月29日开发社群应用重要讨论记录备忘录。

[一币逍遥游]

2020年5月29日开发社群应用重要讨论记录备忘录。
讨论人：昌用CID:CY_vpAv pisa 大师 facjas  
今日讨论话题有一下几个：
（一）讨论话题，目前的FreeDrive的协议还是：https://github.com/fchwallet/freedrive，对吗？encrypted_pwd是什么形式？公钥加密后的解密密钥？还是加密公钥？
    上述问题解答：两个主体或者多个主体，进行通讯或者交互的时候，规定的通讯内容的解密密码的密文。比如，A， B 双方加密通讯：1，ECDH：首先是通过ECDH计算出一个公共秘钥，（不用联网传输，本地计算，所以是安全的）2，加密数据：A对交互的内容 指定一个秘钥，用这个秘钥进行加密数据来通讯。3，传递秘钥：A用第一条中的公共秘钥加密 第二条中指定的秘钥，得到的加密数据的秘钥的密文。4，解密秘钥：B收到第三条中的秘钥密文，用第一条中的共享秘钥解开，得到秘钥，在用秘钥进行解密数据。 秘钥的格式，约定用AES算法加密后的格式。因为双方传递的数据可能比较大，直接用公钥加密，私钥解密，非常耗时。所以需要用ECDH来协商一个秘钥。这里有点绕，不过可以等到有现实需求的时候，再做规定，比如要做加密通讯应用的时候。这个秘钥不是必须的，有的双方为了安全需要加密，有些就不需要必须加密，这个字段应该是可空的才对。
（二）讨论话题：我在细化文件存证协议，跟通讯有些不同。使用freedrive进行文件存证时，当文件内容涉及隐私时，需要对文件进行加密。此时是否是：产生一个随机的加密密钥，然后以用户的公钥进行加密，存储于encrypted_pwd？文件则以随机密钥加密存储于data？
上述问题解答：1，当时我这边设计的时候，不是用公钥加密随机秘钥的形式，因为秘钥体积大一点的话，可能加密非常耗时，而且如果实在移动端上操作的话更不可行，所以是用的ECDH来交换秘钥的。2， 加密文件的算法，可以用AES就可以。
问题提问：那么不用于通讯加密，而是个人对文件进行加密存储的话，用什么方法？用固定长度的随机密钥加密文件，用AES可以吗？
解答：如果是规定秘钥大小那么就是可以的。加密文件，应该用对称算法，AES之类的。这里焦点是说，如何选择 加密文件的 秘钥，以及这个秘钥的传输。
提问：加密算法AES要不要确定下来，写入协议？否则还要增加一个字段，注明加密算法。
解答：是可以，而且可以在应用饿协议层规定。比如文件存证，比较简单，用户端生成密钥，不需要传输。通讯分两种情况，一种是各自存各自的通讯记录，这样也是用户随机生成。另一种是通讯双方共享一份通讯记录，存在密钥传输的问题。通讯记录还是各存各的比较好，否则复杂性会增加不少。需要共享密钥的可以采用ecdh看具体的场景和应用需求。
（三）讨论的问题：日志已经做好群内人员一起纠正问题。
 解答：日志基本没有问题，但是手续费给的有点少。而且里面有一组代码需更新成为动态算法更方便。已经更改了。目前计费逻辑现在还没有现在是没有收费的。目前要看真实需求，有真实需求再考虑收费。成本不会太大，至少可以和云存储成本持平。
（四）需要讨论问题：可以通过 访问 存储文件 视频浏览 并且不卡？
解答：不能保证永久，想要时间久，就多存几个节点。现在还不能做太复杂的，先从简单开始。先从小文件、文本数据开始，检验系统稳定性，修复bug，开拓市场。freedrive 是替你做存储在多个节点上，存是有费用的，取也是有费用的。系统稳定了，市场打开了，在逐渐上复杂的。freedrive 只有API 接口，没有界面，上层显示是具体业务应用决定的。freedrive上的文件随时可以同步到本地，如果不愿意支付费用，可以转到本地或者其他存储平台。freedrive只向 应用收费， 至于应用如何向用户收费，freedrive不关心，freedrive 是服务 B 端的。目前还是底层的构建阶段，上层应用的商业逻辑需要逐渐演化出来。freedrive 向oceanbase学习。不过，freedrive会更开放。现在做的接口都是比较原始，只是满足fch基础应用的需求。这个方向是对的，会成为很大的优势。
（五）讨论话题：代码是否有误？

解答：用最先的driveID是就可以了。创建（driviceId1）--》修改（driviceid2）--》修改或者删除用（driviceid2）。一个driveid创建后。只能在这个基础上修改，修改的标识是updateid。如果继续修改，传的是driveId，而不是updateId，就可以了。每次修改你填对应的driveid.表示在这个driveid累积修改。
（六）问题讨论：是不是不同的是协议，header一定不同吗？

解答：是的，header就是指明协议和版本的。