知识内容应该存放的位置、metadata的数据存储方式等话题讨论。

[一币逍遥游]

2020.6.15 开发讨论重点 关键字 知识内容应该存放的位置、metadata的数据存储方式、个协议版本好的升级后修改版本号、知识库使用的链接修改（https://shimo.im/docs/cSyC12PiCYwYahrx/）
大师提出：author = ming type = definition title = Ming content = 内容

1. data内容
   ming|definition|Ming|内容
   2.变十六进制
   3.签名存储
   刘教授问到：@一棵树上 @pisa_n5oN @大师CID:master_SAe7 freedrive的data数据用“|”分割吗？不是变长吗？
   大师回复：是的，变长。
   刘教授问到：data内容 ming|definition|Ming|内容？
   一棵树回复：能不能把这块内容 ming|definition|Ming| 全部移动到 metadata这里data 就只放内容？
   刘教授回复：不能这样，这些数据都是知识的内容。
   大师@pisa_n5oN ：知识中长度我们定义长度为8，这样基本满足要求了，太长的估计也没有了。
   刘教授问到：8的长度定义的内容最大是多少字符？
   大师回复：16进制的八次方，就是8字节。
   刘教授回复：知识都是文本，多媒体以引用的方式调用其他地方的独立文件。应该足够了。你可以添加到协议文档的2.3.3里，你只管表述出来，后面我再整理。https://shimo.im/docs/YANuwfI5qAEYu9AO/《FOCP3V2_知库》
   大师回复：我开始修改。修改完成昌用CID:CY_vpAv你看看。
   刘教授回复：好，@大师CID:master_SAe7@pisa_n5oN metadata的数据也是这种方式存储吗？
   大师回复：如果都是这种方式的是可以的。
   刘教授回复：好，那就统一起来。
   大师回复：主要是，大家都成共识就行了，剩下的就是执行方案了。链上也是这种方式吗？
   刘教授回复：对的，有行业通行的方案，最好是参照通用方案。链上不是，链上已经成熟了。字段之间以“|”（UTF8编码0x7C)分隔。字段内容可以为空，字段间分隔符保留。如果后面的所有字段均为空，则这些字段之间的分隔符可省略。
   大师回复：好的。看图这是主链的吗？
   刘教授回复：是主链的，不动。metadata的各字段最长是32字节，用一个字节表示长度够了吧？
   大师回复：是的。
   大师回复：这个都要写到协议里面，这样别人看到就知道怎么回事了。
   刘教授回复：是的，要写的明明白白，让开发者不用问任何人，看着协议就能开发一致的应用。我在数据结构前面加了说明，在表格里加了一列给出标记长度的字节数。看看哪里还不清楚https://shimo.im/docs/YANuwfI5qAEYu9AO/《FOCP3V2_知库》。
   大师提出：升一下版本号吧，这样也可以和以前的知识区分开。
   刘教授提出：metadata和data两部分之间是如何区分的？是用不同的接口分别存取吗？@大师CID:master_SAe7@一棵树上 你们看一下，仅凭这个协议，一个开发者是否能够独立开发，还需要补充什么？哪些地方需要指引开发者去读@pisa_n5oN 的freedrivej协议？如果数据不是存在freedrive上，而是其他地方，需要做什么样的说明？
   大师回复：字段长度还需要改吗，希望都看看最终确定我在做，这个地方我已经改了不下3次了。
   刘教授回复：字段长度我看过了，我这里没有问题。硬顶是“标记长度字节”限定的，”内容建议长度“是建议的长度。@大师CID:master_SAe7这样有没有问题？实现上，主要是你们几位开发者达成一致，能够做到清晰明确，符合通行标准，新开发者看了知道怎么做，就可以了。
   一棵树回复：@大师CID:master_SAe7那我们把他改成json格式？或者按之前得来。 就不用管那个长度了。
   刘教授回复：主链的数据结构不动了。主要是辅链你们商定。我们现在是奠定基础，不要图快，要能够避免后面的反复。
   大师回复：@昌用CID:CY_vpAv我看长度没问题够用了，升以下版本号吧，就封板了，剩下的就继续开发了。
   刘教授回复：需要用json吗？还有就是内容的格式（主要是短文和论文两个类型需要）直接采用markdown，还是用html？
   一棵树回复：Html 吧。 那个还需要在处理一次。
   刘教授回复：markdown到作者比较友好。https://shimo.im/docs/cSyC12PiCYwYahrx/《FOCP3V3_知库》@大师CID:master_SAe7新版用这个链接。
   刘教授回复：各位还是要在协议细节上多考虑，我主要思考基本逻辑，技术细节上我不行，需要你们多考虑。
   大师提出：就是这个结构。
   一棵树回复：是把数据转成16进制。然后获取他的长度，我们俩把格式改成json 不就行了？往后的开发者进来也方便些。
   大师回复@一棵树上： 我可以开发接口，给你发布知识，这样你可以发挥你的优势做前台。
   一棵树上回复：用那些都没问题。 要确定。我觉得转来转去太麻烦，前台代码我都是抄袭的。
   刘教授回复：我这里没什么，主要方便开发者们按照简洁一致的方式处理。
   大师回复：这是在咱们说的变成，还有就是使用json存freedrive，顶一下，我这边就开发了@昌用CID:CY_vpAv @pisa_n5oN。
   @pisa_n5oN 回复：变长编码格式有2个优点：1，解析效率，一个大的文件，从头读到尾就全部搞定了， 而以标记（xm, json）这类格式，解析效率不高。也会让文件体积变大。编码出来的内容，很紧凑。2，变长编码本身也在比特币的底层用的这样方式。当然也有缺点：1，没做过这种变长编码的感觉不习惯。我的建议依然是变长编码格式，因为我们自己也在做应用，用变长格式，上层和下层都是统一的。
   一棵树上回复：反正你们决定。
   @pisa_n5oN 回复：不是的，你觉得json方便，是因为你直接用的json库，这个库帮你做好了转换工作，看起来你觉得方便了。现在应用层，可能没有独立的好用的 解析变长格式的库。
   刘教授回复：这个未来是广泛和高频使用的，效率需要重视。是否能给应用层提供变长解析的工具。
   @pisa_n5oN 回复：这个可以的，要设计下这样的库现在都是各自根据自己业务来解析的。
   刘教授@大师CID:master_SAe7 ：你那个示例可以拷贝到协议的“示例”部分。
   大师回复：好，我解析出来也是java，他那边好像是node。没事，将来在应用层和freedrive中间加一个适配层就行了，定下来吧，这个事拖拖拉拉都两周了。
   @pisa_n5oN 回复：适配层这也是工作量。 而上下层都统一为一种格式，是会更好的， 效率来说也更高。
   刘教授回复：我倾向变长方式内容的格式我倾向于markdown底层数据尽可能简洁一些。
   大师回复：@昌用CID:CY_vpAv 你别倾向了，这个时候，需要一个领袖来拍板。
   刘教授回复：我不专业，不能武断。
   pisa_n5oN 回复：bch上的最有名的token 方案，slp发token的协议，也都是变长编码。
   刘教授回复：这个确实是比较成熟了那就用变长吧。
   刘教授提议：接下来考虑内容的格式，跟比特币体系保持一致比较好。
   大师回复：的时候，就是这种变长，但是随着后来要求可读性，慢慢的变长xml，json，甚至序列化好的对象，反正这个东西，各有利弊。
   一棵树上@pisa_n5oN 说道：https://en.bitcoin.it/wiki/Script是和这个一样的吧
   pisa_n5oN 回复：你发的这个是op_code 本身的解释，不是变长编码格式。这个是slp协议的 列子bch上的你从头到尾看下那个图，就懂了。https://github.com/simpleledger/slp-specifications/blob/master/slp-token-type-1.md
   大师回复：比特币的tx字符串也是这个。
   pisa_n5oN 回复：当然，他们都是同宗同源。
   大师：道理大家都懂，现在的问题是大家必须确定下来。
   刘教授回复：没有显著的问题，就不改动了，用变长吧。
   pisa_n5oN 回复：其实我记得小神童先前建议过，FCH主链协议，也应该用这种编码方式。
   刘教授回复：主链不行，主链要求用户签名验证的可读性性质不同辅链是面向开发者的主链面向用户。
   pisa_n5oN 回复：@一棵树上 对不住你了，freedrive 主要是一开始就用了变长，所以你将就下我们吧，用变长吧。而且我们已经有很多内容基于此方式来构建了。
   刘教授回复：共识性的协议需要有妥协，后面通过工具的开发逐步改善应用内容格式用markdown还是html？
   pisa_n5oN 回复：mardown 吧
   刘教授回复：可以参考一下bbs.cash和石墨文档感觉markdown也比较成熟了，更加简洁，容易操作。普通用户既能图形化操作，又能输入中设置格式。
   一棵树上回复：好的，那个应该随意啊markdown 还是 HTMLmarkdown 最后还是要转成HTML 才能显示。
   刘教授回复：好，那协议里就确定markdown了。还一个问题是跨平台的修改涉及到的私钥关系和权限问题。
   一棵树上回复：别啊 HTML吧。
   刘教授回复：html的话，文件引用协议是不是需要改需要确定一个格式规则。否则不同应用不能操作同一个知识条目。最好是确定简洁的基础性的格式，各种应用端都能处理才行。目前markdown似乎是个趋势。
   一棵树上回复：Md不也是转成htmlWordpress编辑器就是html。
   刘教授回复：md可以在不同应用中转成各种格式。貌似各种应用都在兼容md了。需要在协议里规定下来。就是在数据库里以什么样的格式存储，越简洁越好，简单的可以被复杂的兼容，复杂的格式，简单应用处理不了。md容易转换成html，html不容易转换成md的话，就用md。
   修行者：开发一套知识竞猜题发给社区。
   刘教授回复：@修行者dty_rRbH 很好！晚上跟几位开发者沟通了知库的一些细节，尽快把工具给大家做好，然后发动社区一起创建知识。我会帮大家认证知识有创作、修改、发布、邀请和认证的机制。
   @阿拉丁张海波 问到：这个怎么激励？
   刘教授回复：自由创作自由认证。