时间：2020.7.19
地点：开发组
人员：刘昌用、等人
话题：1）填报截止日期以及填报支持的应用有哪些、2）就是data_hash定位的问题。
记录：修行者dty_rRbH
讨论话题如下：
1）填报截止日期以及填报支持的应用有哪些？
对此问题刘教授做了解答，贡献发生的时间是20号，25号前锁定发布，然后进入评估了。
目前支持填报的应用有两个，18.cash 以及 freecash.info 两个应用。
2）就是data_hash定位的问题。
（注释：这三个英文是freedrive存储是用到的三个变量，data_hash是某数据的sha256哈希值，drive_id是一个数据开始在freedrive上存储时那个交易脚本的哈希值，updata_id是对drive_id做修改是的交易脚本的哈希值。）（drive 是模仿 google drive 的云存储产品的命名方式，drive 有驱动，磁盘的意思。）
pisa_n5oN 提出data_hash定位的问题， 可以通过就是某个drive_id或者具体到update_id 来精确定位。 这完全没问题的。刘教授解释到说，这个问题解决了，就是用统一的drive_id定位就行，现在存在updata_id和drive_id之间的模糊。drive_id即指代最开始创建的那个id，又指代包含了一系列的updata_id的整个系列，这个概念含义的多重含义，会带来不必要的麻烦。前面我说的问题，我在协议中，写freedrive的存储位置时，写freedrive: drive_id，是不行的。一种情况，drive_id指的是第一个创建交易，那么这个版本可能不是我想要的。另一种情况，drive_id指的是一个系列，那我还要再次确定哪个是我想要的。如果底层统一都用drive_id标识，那么我写freedrive：drive_id就定义到了具体的utxo，我从里面拿数据就行了。拿到这个数据之后，我还想看历史数据，才根据这个drive_id找关联关系，扩展到一系列数据。现在好像是把一个具体的数据关系场景定义到底层去了。这样的话，定位一个drive_id，所包含的不是最小内容。首先需要一个最小可检索的定位，然后才是更大的类。这样的话，定位一个drive_id，所包含的不是最小内容。首先需要一个最小可检索的定位，然后才是更大的类。我们需要用“Freedrive：drive_id”定位到一个确定的数据，而不是一系列数据。
在听到刘教授的解答后pisa_n5oN 回答说那是不是可以用update-id？刘教授回答说，第一个drive_id又不叫updata_id第一个drive_id只有drive_id，没有updata_id。否则，最小定位就用updata_id了。pisa_n5oN 反驳说到，那是因为我们现在应用层每次update都是全量更新，不是增量更新，所以你们才会决定updateid更精确。刘教授同意pisa_n5oN 的观点，还有就是我说的，你把特定的应用场景定义到了底层。pisa_n5oN 继续说道，那应用层如何确定业务呢？把一系列的driveid列出来说，这几个id代表了这个业务？还有就是如果未来有增量更新，uodateid就是字面代表的意思？刘教授继续说道，不改也可以用，存文件的时候，应用就判断，如果是第一个drive_id，就记录drvie_id，如果有updata_id就记录updata_id。取得时候，先查找drive_id，找到的话，就取第一个drive_id的数据。找不到的话，再找updata_id。应用层根据自己的业务需要做数据关系。如果是编辑文档，就记录更新关系，一般去最新版本，需要的时候，查找历史版本。如果是留言记录，那就是追加的关系。可能还有其他不同场景，如果是通讯簿，不需要单独规定数据关系。通过协议编号和cid就能确定所有属于某个cid的好友记录了。场景不同，数据关系是不一样的。编辑文档可以在metadata里标注比如“create_id"字段，填入第一个drive_id，后续形成一个系列，就跟现在的逻辑一样。总之，需要先给一个无差别的最底层的数据定位，然后在根据需求进行分类和定义关系。
pisa_n5oN 继续说道，driveid.和updateid是utxo变迁历史，不一定是业务关系。
在上述 pisa_n5oN 提出的讨论刘教授并不是很清楚需要pisa_n5oN 跟大师对接此深层讨论这个问题。但是刘教授认为，utxo变迁的关系也应该是底层的，需要跟业务场景分开。
pisa_n5oN 说道，没有限制上层，完全是应用层如何选的问题，你选driveid.定位也没问题，即使有更新记录，多做下解析即可。用uodateid也没问题，直接就解析这一条。
对于第二点问题pisa_n5oN 一直没能理解这里买的重点是什么。
刘教授也存在疑问提出，我在协议里写定位的时候如何写呢？freedrive：drive_id定位不到utxo，freedrive：updata_id，又会漏掉第一个drive_id。现在我们存了一些数据了，要解决的是用户要用的时候，能够找到它，下载它。首先要一个底层的、基本的、统一的、能够唯一地定位到具体单一数据utxo的方式。后续要在这个基础上展开更加复杂的检索。如果这个基础单位没有明晰，不够简洁，采用多种情况的组合。那么后续整个密码经济的数据检索会增加非常大的负担，而且容易出错。对此pisa_n5oN 解答，关于drive_id 和 update_id 统一命名为 drive_id, 这个需要做如下调整：get 操作的时候，需要考虑索引drive_id内容的深度，以及内容的分支（branch），分叉(fork)的问题。branch 是相对于内部的操作。fork 是外部协调协作driveid问题。类比git的 branch, fork。但是，branch,和fork 这2个没考虑到。
刘教授补充道，还是需要有一个只标记单一utxo的名称。然后再考虑utxo内容的关系。先定义实体，然后才能定义关系。对此，pisa_n5oN 提出，统一命名 为drive-id 就可以。这个问题解决了就可以做文件柜的文件存取了。也能够统一位置格式为：freedrive：drive_id了。pisa_n5oN 还提出了，drive_id 就是类似git 的commit_id。刘教授补充说，我对git的逻辑不熟悉，git是一个特定的应用逻辑，freedrive是通用的数据库，借鉴的时候需要注意区分层级。pisa_n5oN 解答，git就是没有共识的区块链。
对此上述问题因打字太慢的问题刘教授跟pisa_n5oN 和大师开了一个视频会议达成共识如下：
底层最小存储单位统一为drive_id；
get通过参数可以获取drive_id在一个输入输出链条上的其他drive_id
从一个drive_id可以通过多个输出的方式形成数据的分支（branch）
输入输出链条通过签名形成了授权关系，为应用层提供实际的权限控制。
非授权cid可以复制某个drive_id的数据内容，开始一个新的drive_id，即分叉（fork）。
分叉只是数据内容的复制，所以无法在底层体现。对fork有需求的应用，可以协议的metadata中给出来源drive_id。
信息的加密不需要freedrive底层的控制，有应用在两端进行加密和解密。
freedrive已经可以用于存证类联盟链的商业应用，相关商业需求欢迎对接。
这次讨论解决了困扰freedrive已久的get操作drive_id和updata_id的问题，使多个逻辑变得清晰，freedrive系统更加成熟。
3）底层框架上有没有实际的应用问题？
@浩 提出，有具体例子的场景吗。前面两个是完成数据的对比吗？第三个修改什么哈希，为什么要修改。想不明白这个代码的应用场景。对此刘教授解答说，这三个地方使用了freedrive来实现分布式存储： http://111.229.195.222/admin/login、https://www.18.cash、http://freecash.vip/user/login.aspx?r=/fund/fundform.aspx。涉及到贡献填报、知库、个人文件柜、自由协议等应用，都还在测试中，主要是把辅链freedrive的逻辑先完善。 数据存储的分层考虑平衡性能、用户体验和安全性，密码经济的数据应该有三个层次：
主链：主要承载非常重要、数据量不大、调用频率不高的全局共享数据，用于定义社会共识和社会关系。
辅链：主要承载比较重要、数据量较大、调用频率不高的用户共享数据，用于消除信息垄断，实现用户数据主权。
本地或中心化云存储：主要承载数据量很大和性能要求很高的日常数据，用于实现用户日常的最佳体验。
这三个层次是互补的。应用层面需要综合根据场景需求，综合考虑三种存储。
不同场景涉及到主链和辅链的策略，涉及到去中心化，有必要形成自由协议。一旦实现逻辑成熟了，可以将基本定型的协议发布，吸引更多应用一起实现，发挥密码共识的优势。
pisa_n5oN 对此也做了解答，底层实现来说不是修改，是重新生成一个新的，业务层体现出来的就是修改