2020.6.19 开发社群讨论 贡献协议 知识库协议的修订话题。

[一币逍遥游]

大师提出：图片要修改的地方长度应该也改成3.我来做修改。密钥改成3.
/Users/pro/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9/ba92630ecd0321cbdfd4e291f7af2bb7/Favorites/temp/DataImage179378144682.jpg
刘教授回复：好的，@pisa_n5oN @大师CID:master_SAe7 这种data只有一个完整文件的情况，是否不应该再加前置长度标记？加上的话有个问题，即data的hash不等于文件的hash了。文件类的存储，希望能够保证metadata里的data_hash与原文件的hash值完全相同，这样方便全网定位文件和使用文件。
大师回复：是的。data前面不用加上次。

刘教授回复：好，那么data存放文件类的协议，就不用加前置长度了。这样的话能够保证data_hash与原文件的hash相同吧？会不会有其他格式转变之类的差异？

大师回复：data就一个，不用加长度了，这样data_hash和文件hash就一样了。

刘教授回复：好，可以测试一下。

大师回复：应该不会，所有的文件我们都会变成byte，然后再计算hash，跟文件类型没关系，只要文件是一个文件，hash就一样。以前我们做文件系统都是这么搞的，没有问题。不过这个是不是应该限制一下大小？

刘教授回复：那就好。后面要用广泛使用哈希寻找文件。

大师回复：现在下载的文件里面都有hash，md5，sha256的，就是为了保证文件中途没有被篡改过，文件hash现在已经非常普遍了。

刘教授回复：如果一个图片在freedrive里有人开放存储，那么其他人使用该图片实际上是可以不再自己存储，直接按照哈希找到，调用即可，这样会节省大量存储空间。如果一个图片在freedrive里有人开放存储，那么其他人使用该图片实际上是可以不再自己存储，直接按照哈希找到，调用即可，这样会节省大量存储空间。协议的协议马上做好了。

一棵树回复：存文件是那个引用协议？

刘教授回复：是这个。

一棵树回复：那那个file字段长度变了。 hash就会不一样。

大师回复：首选文件变成16进制字符串，data_hash计算的是16进制字符串的hash，而不是二进制流文件的hash，你是不是说这个@一棵树上 。

刘教授回复：发布了《FEIP1V3_自由协议(zh-CN)》，根据这段时间的经验，全面取代原来的《FEIP1V2_通用协议》，作为协议的协议，实现更加自由开放去中心化的协议发布、应用和进化。https://bbs.cash/topic/422/。自由协议跟文件引用的freedrive结构差不多，但主链上的数据丰富一些。空间问题，不再提供存储位置字段，可以通过data_hash定位协议文件。起草和修改可以在freedirve里的一个drive_id里进行。正式发布时在主链上发布。

pisa提出：浙江省电子商务促进会关于发布《区块链电子合同平台服务规范》等两项团体标准的通知 。http://www.ttbz.org.cn/Home/Show/13618/

刘教授回复：可以参考制定fch的密码合同协议，这算是传统经济合同的区块链改造。身份认证和合同履行还都需要传统体制来实施。fch从cid开始，借助fch的支付功能，逐渐实现完整的密码经济合同系统。

一棵树回复：这个也改好了吧，https://shimo.im/docs/Gzfm4F96eG8xZGd4/read？

刘教授回复：上午改了。稍等，我再审核一遍。@facjas @随心 链上贡献填报的协议定下来了，你们看一下，7月10日之前是否能实现。这次贡献填报应该是7月20日截止。

facjas回复：可以完成。

一棵树上回复： 这边将在18.cash和机器人上实现。大师CID:master_SAe7 这里在以知库为例跟@pisa_n5oN 一起对接实现，遇到的相关问题，可以一起讨论。

pisa_n5oN回复：好的。freedrive这边新版下周更新。等大家先把现有的对接好。

大师回复：是这样的吧？
/Users/pro/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9/ba92630ecd0321cbdfd4e291f7af2bb7/Favorites/data/l34343a6093a42f8251f6d2284c675803-s-m289bc8fb6cd2dd77f1e6f5d66614eefc.jpg
/Users/pro/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9/ba92630ecd0321cbdfd4e291f7af2bb7/Favorites/data/l20b88ca8c7a0e0379adc8d69a0b3951b-s-me71349b4ab5ec409e903aae684ddcce0.jpg

刘教授回复：freedrive前面的“/”什么含义？@pisa_n5oN freedrive协议的细节还是这个链接吧？《Freedrive Protocol Specification》https://github.com/fchwallet/freedrive/blob/master/freedrive.md

pisa_n5oN回复：是这个。

刘教授回复：好的。

随心问到：@pisa_n5oN 现在有查询所有贡献的接口吗？还是需要遍历所有的freedrive数据才能得到所有的贡献？

pisa_n5oN回复：只有遍历。因为贡献数据是和某个fch地址对应的。我们可以给到所有 传过数据的fch地址，然后再拿地址去读取所有的drive_id

随心回复：那遍历的话，也会遍历到其他数据吗？比如知识库的。

pisa_n5oN回复：会的，freedrive不区分 贡献数据 和 知识库 。只有drive_id. 区分的话需要应用层解析才知道是知识库还是贡献数据。理论上，现在freedrive可支持任何类型的应用数据。

随心回复：那这个以后freedrive数据多的话，效率会比较慢。

pisa_n5oN回复：我们可以再在freedrive上 再写增加些接口，来区分不同的应用数据。

随心回复：是的，最好能区分下。要不然以后效率不行。

pisa_n5oN回复：这个区分应用协议的数据接口，我们可以单独提供，好的。相当于，我们再调用freedrive接口，来解析，然后给到应用调用。

张三疯回复：可以遍历一遍做一个存储，把专门的数据的分出来。

pisa_n5oN回复：底层足够简单和稳定。 上层丰富多样会好些。嗯，是这样考虑。freedrive其实还有很多有趣（或鸡肋）的功能， 最近本身项目比较忙，下周可能会好些，到时候全力支持大家对接freedrive.

修行者dty_rRbH：完成机器人查找协议关键字的查找工作。