2020年5月7日开发社群重要讨论记录备忘录
-
刘教授发起的讨论内容： freedrive的使用应该主要是面向应用，个人使用应用，应用存储数据，这样的话，收入可以考虑贡献奖励分成。节点和准备使用freedrive的应用一起商量一下，定一个合适的分成比例和节点间分配比例如何？pisa_n5oN Skeyil1lLiaeyr₿ch 沙枫 随心 一棵树上 facjas向这六位技术人员发起谈论。
技术人都得到回复。
刘教授向facjas问起： 能在文本里@后根据输入提示cid就好了。
facjas回复：会有这个功能的。下个版本。
刘教授发起讨论：我修改了《FEIP2V3_文件存证》协议，加入文件存入FreeDrive的数据结构和逻辑。这是FreeDrive最简单的应用：在主链上发布文件哈希，文件存FreeDrive。借助这个应用，可以实现协议的规范化，协议链上存证并存入FreeDrive，有助于协议系统发展，提高FCH生态的演进速度和安全性。https://shimo.im/docs/ziSwu2IIYqEtmx14/
请@随心 和@一棵树上 @pisa_n5oN 看看有没有问题，能否尽快实现？这是FreeDrive最简单的应用。
刘教授发起讨论：基于CID和FreeDrive的《在线办公》应用提议
类似石墨文档的办公系统，石墨文档类的痛点：
1）无法下载所有内容。个人文档不能批量下载。
2）担心运营方倒闭。运营方倒闭，文档有丢失风险。
3）隐私问题。运营方拥有个人文档的控制权。
4）监管与访问限制。中心化监管方可以要求运营方对用户文档进行控制或修改。
基于FreeDrive可以通过分布式存储、用户公钥加密、私钥签名授权等方式解决以上问题。
初期可以先实现简单的word功能。编辑采用markdown技术，文档存储于FreeDrive，用户可以在fch生态的任何平台上，以cid登录，即可开始编辑使用自己的文档。
此应用可以集成到fch的各个平台中https://bbs.cash/topic/359/ 大家留意一下，有这方面开发经验或产品的可以推荐一下，尝试做一做。
技术对FCH的认知与看法：fch 最有意思的是一簇簇的应用协议，这些是有可能让大家摆脱以币价本身作为盈利来源的唯一途径的。币本身是没价值的，只有用起来才有价值。越是能方便的用起来，价值越大，协议作用就在此。
刘教授与@Skeyil1lLiaeyr₿ch @facjas @随心 @一棵树上发起讨论：发布新协议：https://shimo.im/docs/3A3pMu2VyI0UBbbm/《FOCP3V1_知库》，形成分布式的知识生产系统。让社区每个人都能边学习，边创作，边入库。初期先通过freecash.vip、dplanet、微信机器人自主填写知识和查询知识。后面慢慢加上知识审核和其他应用。
刘教授发起讨论：基于CID和FreeDrive的《在线办公》应用提议
类似石墨文档的办公系统，石墨文档类的痛点：
1）无法下载所有内容。个人文档不能批量下载。
2）担心运营方倒闭。运营方倒闭，文档有丢失风险。
3）隐私问题。运营方拥有个人文档的控制权。
4）监管与访问限制。中心化监管方可以要求运营方对用户文档进行控制或修改。
基于FreeDrive可以通过分布式存储、用户公钥加密、私钥签名授权等方式解决以上问题。
初期可以先实现简单的word功能。编辑采用markdown技术，文档存储于FreeDrive，用户可以在fch生态的任何平台上，以cid登录，即可开始编辑使用自己的文档。
此应用可以集成到fch的各个平台中https://bbs.cash/topic/359/ 大家留意一下，有这方面开发经验或产品的可以推荐一下，尝试做一做。
技术对FCH的认知与看法：fch 最有意思的是一簇簇的应用协议，这些是有可能让大家摆脱以币价本身作为盈利来源的唯一途径的。币本身是没价值的，只有用起来才有价值。越是能方便的用起来，价值越大，协议作用就在此。
刘教授与@Skeyil1lLiaeyr₿ch @facjas @随心 @一棵树上发起讨论：发布新协议：https://shimo.im/docs/3A3pMu2VyI0UBbbm/《FOCP3V1_知库》，形成分布式的知识生产系统。让社区每个人都能边学习，边创作，边入库。初期先通过freecash.vip、dplanet、微信机器人自主填写知识和查询知识。后面慢慢加上知识审核和其他应用。
目前因安排的事项太多技术人员目前都已经忙不过来了，刘教授的说道根据根据难易程度和紧急程度，排一下，选最简单、最紧急、影响最大的做，贡献奖励会更大些。
刘教授提出：谁能做《知库》的库和接口？目前知库格式已经定好了。
pisa_n5oN回复：由我负责添加，到时候接口一起调整。这个type 是 文件类型吗？
[图片]
刘教授回复：不是的下面有说明的知识类别，文件是此项知识相关文件，比如图片。
pisa_n5oN回复：哦，这个知识条目的修改权限是谁呢？ 是所有人？还是有人审核？
底层存储，出了 metadata , data外， 还有lockingscript 部分， 这个lockingscript可以用来控制 数据的变更权限等等。所以需要知道下 知识条目的 修改权限是 怎么样的。
刘教授回复：发布者自己，谁发布谁修改谁删除。
pisa_n5oN问道：好，有没有可能其他人向发布者提交 修改请求之类的？
阿拉丁提问：知识正确或者错误 这个需要审核？
刘教授回复：不审核，可以评价。
pisa_n5oN提出异议：是不是要考虑，知库这个是 协作权重多些呢？ 还是存储权重些？
如果是前者的话，协作的协议可能要定得细一点才能解决这个问题。如果是存储权重大，我到觉得直接打包成一个文件，每次更新的时候，重新传全新文件即可。设计需求的时候，需要个取舍，这样才好实现。
刘教授回复：主要不是为协作，主要是发布。可以作为一个文件发布。但文件内的结构也要定义吧的。现在是确定知库这类data内部的结构。一般的文字性条目，前四个字段就可以了。但有些条目的内容里要插入图表，才有了对文件字段的需求。现在就是看文件字段：1）如何处理文件名、类型和文件本身的关系；2）多个文件如何处理；3）如何将各个文件定位到“内容”中的相应位置。
pisa_n5oN解释道：内部结构如果是单文件，到还好。 现在是多文件， 也就意味着，我们是以多个文件分别的hash 作为唯一确定 整个文件呢， 还是以把多个文件合成一个文件的hash 来表示。
刘教授回复道：我把“文件”改成“附件”吧不然容易说混。因为你把附件单独定义出来，这个事情感觉变得异常复杂了。