在 SocialHub 上，@keunes 提议 联邦化声誉，其含义是：如果 Discourse 支持 ActivityPub，用户就可以利用他们在互联网上一个或多个 Discourse 实例上已有的声誉，绕过初始的信任等级 0 和 1，在加入新论坛时直接达到等级 2（成员）级别。
我刚在这个 Discourse 实例上发布了第一篇帖子，因为我是新用户，所以只能发布两个链接。这可以理解，但相当令人烦恼。所以我一直在想：有没有办法让 Discourse 实现联邦化，特别是我的声誉？
例如，在 AntennaPod 论坛中，我们可以将 SocialHub 设置为“受信任的信任源”，允许用户受益于他们在其他地方获得的信任等级。
确实，当你是拥有良好声誉的知名网民时，加入新论坛时较低信任等级的限制可能会成为一种负担。另一方面，如果你获得了不良声誉，这也可能阻碍你在新的论坛上获得权限（例如，作为提升信任等级的负面权重，尽管这很容易通过使用新身份来规避）。
因此，这个想法实际上是促进 Discourse 实例之间良好行为声誉的共享。由于 Discourse 实例的全球网络已经存在，Meta 上的许多用户也活跃在其他多个实例中，因此对于普通用户来说，跨实例统一身份变得越来越必要，以便对话更加流畅。ActivityPub 是实现这一目标的一种方法，我们目前正在探索开发一个插件来为 Discourse 添加 ActivityPub 支持，这可以作为其他联邦功能（包括此功能）的基础。
并行历史
@erlend_sh 提醒我注意三年前这个匆匆提出的方案：
提议的有趣功能总结
自愿加入
信任网络
可发现性
在 第 4 条帖子 中，@erlend_sh 提议添加与其他用户的“共同社区”，并最终将徽章跨社区移植，以便成员更容易发现新社区。
9 个赞
关于“声誉迁移”的初步想法：
- 每个论坛应设置为可选加入
- 每位用户应设置为可选加入（参见第 1 点）
- 应提供一个可编辑的允许论坛白名单（或许由 Discourse 本身提供）
- 应提供一个可编辑的允许论坛黑名单
1：这引发了一个问题：我们是否要在用户使用论坛的前 5 分钟内不断提醒他们此事？
4 个赞
我认为信任等级更多地是关于学习各个论坛的规则和习俗。允许人们基于其他论坛的规则跳过默认的两周/15 次访问的“适应”阶段，可能效果并不理想。
我并不介意增加一个“关联会员”信任等级，该等级可应用于已注册到中央目录枢纽的论坛或用户。这样我可以获得大量论坛的读取权限，或许还能投票或点赞；但若要发帖、提升信任等级等完整会员功能，仍需注册特定论坛。
2 个赞
erlend_sh
(Erlend Sogge Heggen)
4
我正在运营几个小型的 Discord 实例，一想到将来不得不折腾 moderation bots 来防止垃圾信息和恶意行为，我就感到头疼。
Discord 在 Moderation 方面的许多不足，其实可以通过“信任等级”（Trust Levels）来解决，而这一功能在社区软件中目前仍被严重低估。
在网络化（联邦式）的信任等级体系下，多个互操作的实例可以共享信任等级，从而实现两个重要功能：
信任网络
如果一个用户在 Meta 上达到了 TL 2 等级，那么当他加入任何将 meta.discourse.org 列为“受信任论坛”的论坛时，应直接提升至 TL 1。这本质上是 Let experienced users skip "new to Discourse" features 这一提议的下一步。
这是一种非常直观的类似 PageRank 的机制。
可发现性
Discord 有一个很实用的功能，可以让你看到你和另一位用户共同所在的聊天社区（服务器）：
这让我想起了我仍然认为最具吸引力的 Discourse Hub 使用场景：
一种类似的从其他实例继承徽章的方式也会非常有用。当某人获得了第一个“乐于助人”徽章（目前默认情况下尚无此徽章）后，该徽章在每一个额外实例中显示，都会提醒并肯定这个人：他是那种乐于帮助他人的社区成员。
6 个赞
如果引入信任网络，我希望同时支持“受信任信任列表”和“受信任论坛”。例如，一个 Discourse 实例可以发布其受信任论坛列表，我可以在我的实例上选择信任 meta.discourse.org/trusted-forums.json。（大概是非递归的）
3 个赞
osioke
(Osioke Itseuwa)
6
您认为这将如何运作？是匿名进行且不涉及任何用户数据，还是……？
我不确定哪些用户数据与受信任论坛列表具体相关。我设想“受信任论坛”是由实例管理员选择的，如果管理员选择发布，那么请求 meta.discourse.org/trusted-forums.json（或 whatever 该 URL 可能是什么）将会产生类似以下内容：
{
"trustedForums": [
"meta.discourse.org",
"bestforum.com",
"marvellousdiscussions.org",
...
]
}
然后，作为实例的管理员，我可以将 meta.discourse.org 输入到“受信任论坛”中，仅信任该实例（不信任它所信任的实例）；或者，我可以将其输入到“受信任信任列表”（需要一个更好的名称）中，以信任该实例及其所信任的实例。
该 JSON 实际上可能不会包含对其自身实例的引用，这只是为了说明信任来自另一个实例的列表也应意味着信任该实例本身。
既然你提到了用户数据，我假设你指的是我看待信任本身如何运作的方式。这超出了我评论的范围，但鉴于 @erlend_sh 提出的将用户提升至 TL1 的想法，我猜实例必须在注册时（或更可能在注册后的 Sidekiq 任务中）与受信任论坛共享类似电子邮件地址的 sha256 哈希值。
虽然这避免了直接共享用户数据，但我立刻能看到一个缺陷：以上述 JSON 为例，如果用户在 bestforum.com 上拥有账户，然后注册到 meta.discourse.org，这将向前者揭示该用户在后者上创建了账户，同时也可能向后者揭示该用户在前者上已有账户，这可能是不理想的。
我不太确定该如何处理这个问题。让用户在注册时选择加入实际上并不可靠，因为想要滥用该机制的实例只需将其移除即可。
也许“Discourse Hub”可以通过仅保留（且仅被提供）带有相关实例和信任级别的哈希电子邮件地址，在很大程度上解决该问题。实例可以使用哈希后的电子邮件地址向 Hub 查询，并可能采用基于分数的系统，统计该哈希值出现过的实例及其达到的信任级别，这样实例就永远不会看到涉及哪些其他实例，只会看到最终得分。
不过，鉴于此类 Hub 的明显运营者是 Civilized Discourse Construction Kit, Inc.，这种安排仍然有一个重要问题：作为 meta 及其他实例的用户，我是否希望 CDCK 能够看到我正在使用哪些其他实例？（因为实例+Hub 运营者完全有可能将其自身实例的用户与 Hub 中的条目关联起来）
总之，信任如何运作对于我这混乱的大脑来说太过复杂了。
尽管我认为“可信论坛”的方法有趣且有用，但我同时也看到了一个潜在的安全问题：攻击者可能会针对监管较少的“可信论坛”，以获取其实际目标的访问权限——而这些目标他们无法直接访问。因此，如果我们确实要实施这种“传递性信任”机制，它不应容易被“遍历”，并且应配备强有力的反制机制，能够在多个实例中暂停攻击者的权限。我认为这是一个硬性约束，会大幅增加复杂性，因此最好留待开发的第二阶段再考虑。
另一方面，维护一个“私有可信论坛列表”似乎更容易，其中成员在每个论坛上的远程声誉将强化其在本地论坛的地位。也许“信任等级”的概念可以同时扩展到实例和用户？例如，如果某个实例（如 Meta）的等级为 TL3，那么来自该实例的用户初始等级可为 TL2，但如果用户不参与，则会有“衰减因子”；这增加了另一层复杂性，但我只是随口说说，旨在勾勒出一些替代整体实例信任的可行方案。
我同意在涉及用户使用的是哪些实例时应保持谨慎。这一点应当被纳入考量，尽管向公共实例发布内容可能等同于公开你正在使用这些实例这一事实；不过，这一原则可能更适用于私人板块。
2 个赞
我仍在为目录级别的用户列表进行规划。
h airsp ttps://DiscourseDiscovery.org -
匿名用户将看到一个已注册加入公共列表的论坛目录（可按类别或“论坛标签”搜索），并可在目录中的所有实例中搜索关键词。
注册以创建 DiscourseDiscovery 用户账户。新账户将从 Hub_Level_0 开始，并通过完成特定操作以及经过调整的 Discobot“论坛培训”（涵盖您认为人们所需的所有必要技能）逐步晋升至剩余的 Hub_Levels。
不同的 Hub_Levels 将允许访问目录中更多的功能。例如：查看通常对匿名用户不可见的类别、执行点赞或在投票中投票等操作（头像周围可添加红色圆圈以标识为关联成员/Hub_Levels 成员），或接收关于话题内容的通知等。点击头像将显示其 DiscourseDiscovery 用户卡片。
用户随后可以将任何“正式成员”论坛账户添加到一个串联的 DiscourseDiscovery 用户页面（可选择排除任何他们不想包含的账户）。徽章统计、最新活动等也可在此汇总。
论坛也可以在安全设置中选择仅允许正式成员访问某些内容（如类别、投票等）。他们还可以选择是否被包含在公共目录中，或基于用户的 Hub_Levels 被包含在更私密的目录中（或者完全不包含）。
只是一些想法。
3 个赞
