讨论一下给公共数据打TAG的设计

[waterflier]

原始文档在这里：
https://github.com/buckyos/DCRM/blob/main/doc/TAG%E7%B3%BB%E7%BB%9F.md

基本逻辑

1. Tag拥有唯一路径(path_id)，我们要限制Tag能使用的合法字符（头尾不能有空格等符号）
2. Tag可以有一个描述用的json文件，出了对该Tag的含义进行详细说明外，还可以设置其多语言
3. Tag的描述是可以更新的。我们需要设计规则来更新，几个思路：、

• a. 基于经济学，首次设置不需要GWT，后续更新都需要GWT，且每次更新都是上一次GWT的10%
  消耗手续费 赞成/反对 算积分也是一种方法，不过考虑到钱包的注册成本为0，这里还是比财力
• b. 通过DAO组织处理争议

4. 每个用户对TAG的描述都是独立的（自己更新自己的），有UI层决定怎么展示。可以设计独立的认证体系来引导UI展示高权重的TAG
5. 对Tag的认证，本质上是用户消耗手续费，表达对Tag的认同/不认同操作。有一些特殊的账号，会被UI识别，并把其认同转化为可以展示的认证。

设置公共数据的Tag

• 从手续费的角度考虑，在Show的时候可以有一个选填参数，来指定本次SHOW使用的TAGList(最多5个？）

• 提供一个单独的函数 （收藏?)）,给一个公共数据打多个Tag，这个单独的函数，还允许附加为什么这个数据应该有这个Tag的原因

• 对公共数据的Tag，也可以单独的进行认同和不认同，并给出一个文本理由

[weiqiushi]

1. tag的字符处理，应该在后台和前端共同进行。
   因为合约中的string,本质上是byte[]，缺乏对字符进行处理的必要功能
   后端提交，和前端展示时，剔除掉含有不合规字符的tag即可
2. 这个json文件可以存储在组织的中心服务器上，链上的desc部分存储url即可
   由于tag的创建和修改是有审核的，由组织中心化的存储描述也是可以接受的
   因为类比wiki，tag的描述会越来越长，越来越详细，就算在eth的layer2链上，存储和修改成本也是比较高的
3. tag的描述更新可以通过DAO组织的proposal合约来提交，由DAO组织来处理
   比财力来更新我个人的观感不好，容易出现wiki那样的编辑战争
4. 每个用户对tag的描述都独立，这一点不是与3冲突么？
   如果每个用户对每个tag都有自己的描述，那就不存在tag描述争议的问题，也不利于公共浏览
   考虑常见的场景：一个新用户看到公共library页面，他能看到每个数据的tag，但是所有tag的描述都是空的，需要自己来填。这怎么想都有问题把

我觉得应该是这样：

1. 用户在“下载”和“收藏”一个数据时，可以给数据附上(最多5个?)tag。这些tag可以从已有的tag中选择，也可以自己创建新的
2. 当创建新的tag时，允许用户填写tag的描述，经审核后将tag添加到链上，并附加到数据上
3. 当选择已有的tag时，不需要经过审核，直接附加到数据上
4. 数据附加的所有tag都可以被所有人看到，每个人都可以花费手续费(链的手续费，合约不额外收取)，来给一个tag点赞或踩
5. UI上可以优先展示赞数多的tag，踩多的tag可以被默认隐藏

设置tag的部分：

1. 参见上文，应该是在“下载”和“收藏”时设置tag，而不是每次show的时候允许用户填写不同的tag。这个操作在show之前应该就完成了
2. 对tag的操作大多数时候应该是不言自明的，tag本身就能说明我为什么要附加这个tag了

给一个动作电影附上"动作电影"，或者"{电影主演}"的tag，应该是不需要多余的文字说明的
同样，我给一个附在动作电影上的"搞笑"tag点踩的时候，应该也是不需要额外的文字信息的

[weiqiushi]

提交了第一个Tag合约的实现，只有写函数

contracts/data_tag.sol

[waterflier]

0.Tag拥有唯一路径(path_id) ，游戏/动作 和 电影/动作 是两个不同的Tag，不能单独的用动作作为Tag的Id。

1. 我们在创建合约的前台做限制
2. Tag的描述是很重要的，还是保存在链上。
   每个Tag都有描述（创建的时候由创建者提供第一个）
   我们允许每个人都可以针对一个Tag(通过Path保证唯一性)创建一个描述文件。同一个用户对一个Tag的新描述会覆盖其老描述
3. 通过 合约调用“认可”，用户A可以表达对 “用户B认为Tag的描述是X” 这个行为的认可。这个模式可以广泛的应用在所有“给一个对象绑定描述”的行为上
4. 白名单用户的认可，可以认为是一种认证。我们的前端可以筛选被认证过的描述来展示
5. 用户看到的描述，通常是最近被认证的描述（可以来源于任何用户）

设置tag的部分：

参见上文，应该是在“下载”和“收藏”时设置tag，而不是每次show的时候允许用户填写不同的tag。这个操作在show之前应该就完成了
同意，按现在的逻辑，SHOW之前必须另存为。（收藏可以看做不占空间的另存为），此时要么用户选择一个已有的TAG，要么可以在这个时候创建一个新的TAG。

[weiqiushi]

大致同意。
这里有一些需要明确的问题：

1. 用户可以修改他自己对某个tag的描述，这会出现：
   a. 用户可以将一个点赞很多的tag描述修改为其他内容，造成欺骗的效果
   b. 为了防止a的出现，可以实现成当用户更新内容时，清空他的点赞数。但这样做的成本可能会很高，也会打击正常改进内容的用户的积极性

2. 用户赞同/反对的其实是tag的某个具体的描述，那么：
   a. 在另存为和收藏时，用户填写的其实也不是tag，而是tag下，他认同的某个具体的描述
   b. 用户是否可以添加同一个tag下的多个描述？如果这些描述都是对的，且都反应了tag的某个侧面

[weiqiushi]

进一步思考：
上述问题的1，很难解决，选择哪种方法，都会损害一部分人的利益
上述问题的2，会对用户的使用上造成困难：
当用户设置tag的时候，用户先选择一个tag，然后查看这个tag下的10个描述，然后再选择一个/多个他认为正确的
然后这样的行为要重复5次

如果我们将tag合约看作一个简化版的wiki系统，这个wiki上的条目，必须绑定在一个已知数据上，那么：

1. 我们是否可以增加一个"编辑"权限，管理者可以随时授予和撤销某个地址的编辑权限

2. 任何用户都可以创建一个tag，但创建的tag都是没有描述的，且一个tag的描述只有一份

3. 只有编辑有权限修改一个tag的描述，普通用户可以通过DAO的propose系统来申请对tag的描述更新
   这样可以解决问题1

4. 用户在数据上附加的是tag本身，而不是tag的描述了

5. 其他人的 赞同/反对 也集中在"数据上的这个tag是否合适"，而不是"tag的这个描述是否合适"的问题上
   一个合适的tag，比如"电影/动作"，不需要编辑增加描述，也可以被大多数人认可，并附加在合适的数据上。
   一个错误的tag，比如"电影/游戏"，本身就不会被人认可而添加。就算添加了，也会被其他用户disagree掉。

从视频网站的tag角度来看，没有哪个视频网站的tag是强调tag的描述的，大多需要点击这个tag才会链接到一个wiki页面。多数情况下，tag的字面意义本身就足以表达它传递的信息

youtube：没有tag
nicinico：有tag，任何人都可以添加，简单的几个字。其他人可以 赞/取消赞，点赞越多的展示排名越靠前，点击跳转到搜索页面
bilibili: 有tag，只有up主可以添加，普通tag点击跳转到搜索页面，特殊tag点击跳转到指定分类/排行榜页面

[weiqiushi]

按照tag描述逻辑，更新了文档，给数据附加tag，还是tag描述的问题尚未确定。文档中保留附加tag的逻辑
TAG%E7%B3%BB%E7%BB%9F.md

0.Tag拥有唯一路径(path_id) ，游戏/动作 和 电影/动作 是两个不同的Tag，不能单独的用动作作为Tag的Id。

1. 我们在创建合约的前台做限制
2. Tag的描述是很重要的，还是保存在链上。
   每个Tag都有描述（创建的时候由创建者提供第一个）
   我们允许每个人都可以针对一个Tag(通过Path保证唯一性)创建一个描述文件。同一个用户对一个Tag的新描述会覆盖其老描述
3. 通过 合约调用“认可”，用户A可以表达对 “用户B认为Tag的描述是X” 这个行为的认可。这个模式可以广泛的应用在所有“给一个对象绑定描述”的行为上
4. 白名单用户的认可，可以认为是一种认证。我们的前端可以筛选被认证过的描述来展示
5. 用户看到的描述，通常是最近被认证的描述（可以来源于任何用户）

设置tag的部分：

参见上文，应该是在“下载”和“收藏”时设置tag，而不是每次show的时候允许用户填写不同的tag。这个操作在show之前应该就完成了
同意，按现在的逻辑，SHOW之前必须另存为。（收藏可以看做不占空间的另存为），此时要么用户选择一个已有的TAG，要么可以在这个时候创建一个新的TAG。

[waterflier]

大致同意。 这里有一些需要明确的问题：

1. 用户可以修改他自己对某个tag的描述，这会出现：
   a. 用户可以将一个点赞很多的tag描述修改为其他内容，造成欺骗的效果

认证的是一个确定的描述，用户更新后的描述不会被自动认证
白名单用户的认证其实就是编辑，我希望好的设计是能用最小的概念完成我们的目标，至少现在在L2上我们不太要操心手续费的问题。

b. 为了防止a的出现，可以实现成当用户更新内容时，清空他的点赞数。但这样做的成本可能会很高，也会打击正常改进内容的用户的积极性
2. 用户赞同/反对的其实是tag的某个具体的描述，那么：
a. 在另存为和收藏时，用户填写的其实也不是tag，而是tag下，他认同的某个具体的描述
b. 用户是否可以添加同一个tag下的多个描述？如果这些描述都是对的，且都反应了tag的某个侧面

我觉得我们主要的编辑会集中在TAG本身的 描述上，我认为用户并不会集中研究 “一个文件是否应该有这个TAG”，大部分情况下一个文件拥有TAG都是显然的，除非一些争议性很强的TAG。

[waterflier]

我们其实是用 认证的TAG系统在进行数据的分类保存，这个和一般视频网站的TAG目的是截然不同的。我们这个更接近WIKI

[waterflier]

文档我看了，基本没有分歧。只是从手续费的角度，SHOW里面如果要打TAG的化，可能需要做一些合约的集成。

[weiqiushi]

按照以下规则，重新实现了tag合约：

1. tag具有层次结构，tag的全名是以"/"开始，以"/"连接全部层次的字符串
2. tag的全名具有唯一性
3. 任何地址都可以给任何tag附加一段说明，不同地址的tag说明相互独立。每个地址对某个tag的说明是唯一的
4. 任何地址都可以赞同/反对其他人的tag说明
5. 数据可以附加多个TAG
6. 任何地址都可以给数据附加TAG，所有人都能看到数据上附加的全部TAG
7. 数据上不能同时存在父子TAG
8. 当给数据附加TAG时，它会替换掉之前附加的父TAG
9. 任何地址也可以赞同/反对数据上的某个TAG

[weiqiushi]

还是有些疑问：

1. 数据上的tag是否是全局的？

如果是，那么根据规则7，8：
假设某个资源有tag"/电影/动作电影"，某人附加了错误的tag“/电影/动作电影/1997”，那么这个错误的tag就会把正确的顶掉，而且没有办法恢复过来

如果类似tag meta，每个人有自己的data -> tag的绑定关系，那么：
前端应该展示哪些账户设置的绑定关系？如果只展示自己的，和白名单账户的。那这个tag实际上不能用于社区交流，我不清楚这个系统的意义何在。
一定会变成：白名单(管理员，编辑)设置tag->其他人原封不动选择这些已有的tag，即对用户来说，思考绑定哪些tag这件事的吸引力不足

我觉得我们主要的编辑会集中在TAG本身的 描述上，我认为用户并不会集中研究 “一个文件是否应该有这个TAG”，大部分情况下一个文件拥有TAG都是显然的，除非一些争议性很强的TAG。

我对此观点持保留意见。我认为一个公众参与的tag编辑系统中，对附加TAG这个行为的争议要远大于对TAG本身意义的争议。大众不会花很多心思思考一个TAG的精确描述，更多的注意力集中在“为什么会有这个TAG”和"这个TAG的绑定关系是否合适"。nico，bili，知乎的tag系统都是如此的表现形式

[waterflier]

当给数据附加TAG时，它会替换掉之前附加的父TAG

这个行为只限于同地址打Tag，比如用户A先给数据打了"/电影/动作电影的TAg，随后又打了/电影/动作电影/1997 的Tag，那么站在用户A的角度看，这个电影的Tag是/电影/动作电影/1997

前端应该展示哪些账户设置的绑定关系？ 这个现阶段是纯产品行为，站在合约的角度，我们只需要先让系统能尽量保存下更多的原始数据，规则简单就好了。如果需要在合约里就可以确定"给数据添加什么属性"的规则，那这个规则一定是一个在中心化系统里，被充分验证的规则，这可以在系统进入下一期的时候来考虑要不要新增一个“编辑合约”来实现。

我对 主要的编辑会集中在TAG本身的 的判断是基于系统的早期阶段的。这个时候数据比较少。到了后期，我觉得肯定会演变到 更多的注意力集中在“为什么会有这个TAG”和"这个TAG的绑定关系是否合适"

[weiqiushi]

合约和文档更新了，正式版本的接口和事件应该就是这样的了

以下逻辑尚未实现：

• TAG的有效字符判定
• 数据绑定TAG时的父子判定
• 子TAG替换已有的父TAG

[weiqiushi]

合约代码和文档都已更新，完善了上述提到的所有逻辑。

没有问题的话可以close本issue了
@waterflier