就像类别更改一样，我认为这真的取决于具体情况。例如，考虑一下：
- 帖子 1 由用户 1（Actor 1）在类别 1 中创建
- 2 分钟后，帖子 1 的作者被用户 3（管理员）更改为用户 2（Actor 2）
- 类别 1 被来自 20 个域和 5 种不同软件平台的 400 个 Actor 关注，每种平台对时间线和内容发现的实现略有不同。
- 在帖子 1 创建后的 2 分钟内，有 2 条具有相同内容和不同 Actor 的笔记被发布给这 400 个关注者。
我认为这很可能会让相当一部分关注者感到困惑，更不用说用户 2 可能甚至没有意识到他们的名字现在与他们在 20 个不同域上的这些重复内容相关联，而这些内容不是他们写的。他们可能可以接受管理员在单个实例上这样做，在发布到该实例时，这在某种程度上是隐含同意的，但是，我认为我们应该非常谨慎地将这种隐含同意扩展到整个 Fediverse，尤其是在复制内容的这种不完美的情况下。更改帖子所有者是一项强大的管理功能，特定于 Discourse，并且隐含地与单个实例的“社交契约”相关联。
我认为 wiki 的情况更强一些，但我会再次观察你已经暗示过的。Wiki 是根植于正常的Discourse 中的概念。将任何人的编辑（不仅仅是员工）与原始作者相关联是一个 Discourse 概念，在 ActivityPub 中没有类似的概念。我们应该谨慎地通过 ActivityPub 的标准方法将这个概念扩展到整个 Fediverse。这些更新活动将被视为与其他实例和软件平台上的任何其他更新活动一样，脱离了它们原始的 wiki 上下文。此外，正如你所暗示的，员工和高度信任的用户编辑他人帖子的能力已经存在潜在问题。我认为在讨论 wiki 之前，需要对这个更有限的问题进行更多考虑。
我并不是想在 Discourse 和 ActivityPub 之间为这些功能设置一个二元选择。我想说的是，我们不应该仅仅试图将敏感的 Discourse 功能映射到 Fediverse，而不仔细考虑后果。默认情况下，这些更敏感的功能在 ActivityPub 帖子上应该是禁用的，直到我们更有信心我们不会损害或意外地给相当一部分用户或用例带来麻烦。
就个人而言，我认为我们在这两方面都还没有达到那个阶段，尽管我的直觉是，wiki 的情况在这个阶段有更大的潜力，即使我还没有找到一个好的解决方案。