只是想通知您，我们目前处于这个阶段
5 个赞
太棒了！
我最近为我们的 CoSocial Co-op 设置了一个 Discourse 服务器，该服务器运行一个 Mastodon 服务器。我最终设置了 OAuth2 插件，因此我们只接受来自我们的 Mastodon 服务器的登录 → https://members.cosocial.ca（一个全新的、非常简单的安装，只是“OAuth 证明”）。
我的问题/功能请求是能够将 Mastodon 参与者分阶段/合并到 Discourse 帐户中，这样当 Mastodon 上的帐户回复时，它们就可以链接到关联的 Discourse 帐户/由其拥有。
Lemmy 不这样做
我记录了 Lemmy _不_这样做的方式——你可以通过 Mastodon 进行交互，并在 Lemmy 中为该 Mastodon 帐户创建一个帐户，但你实际上无法使用你的 Mastodon 帐户登录并使用 Lemmy 的一流功能。
4 个赞
这已提上日程……
并且已在队列中等待审核
3 个赞
太好了。听起来我的 Discourse OAuth 插件用户需要“再次确认”才能与此 AP 插件进行互操作。
我认为现阶段这完全没问题，只是想从另一个角度提及 OAuth 服务器，只要它不冲突即可。“锦上添花”的功能将是“如果使用 Mastodon 服务器进行 OAuth，则自动链接 AP actor 身份”。这完全是未来的设想，而且对于这种设置来说也是独一无二的！
（抱歉没有弹出页面查看那部分！太棒了！）
1 个赞
添加此功能集的 PR 现已合并。
正如 Angus 在上面指出的，接下来是 OAuth 令牌的用户验证。
2 个赞
我之前看到的原始 Markdown 文本显示出来的问题似乎也影响到了 meta。我正在关注 @feature@meta.discourse.org，几小时前，这个帖子被创建并从该 Actor 联合过来：
在 Mastodon 上，它显示为这样，存在故障：
在 Elk 中，它看起来是这样的，稍微好一点：
我现在刚刚在我的纯 Mastodon 账户上关注了 @feature@meta.discourse.org 来测试这个问题，但当然现在已经太晚了，无法在那里看到这个特定的帖子了。
所以，我之前从我自己的安装中看到的嵌入式 Markdown 不是数据库有问题，或者即使是，那也是 meta 共享的数据库问题，因此可能与我的测试无关。
2 个赞
是的，我能复现这个问题，我在一个Mastodon实例和Ivory（iOS应用）中看到了类似的输出。
2 个赞
我不确定这是否正常工作。插件已启用，我在启用了 ActivityPub 的类别中创建了一个主题，但我没有在帖子旁边看到徽章（并且我尝试关注该类别的 activitypub actor 似乎失败了，因为它表现得像一个需要用户手动批准的服务器）。
我刚注意到，在 Meta 上针对 Feature 也出现了同样的问题。
1 个赞
了解限制的最终目标将非常有用，而无需担心中间状态。
例如，我认为我在 PR 中看到过一个参考，如果启用了该插件，更改帖子的所有者将被阻止。作为管理员，我必须偶尔使用该功能（例如，在更改类别版主时，我会让新的主要类别版主成为有关置顶帖子的类别的所有者）。我希望最终，这会显示为删除和重新发布，甚至只是被忽略，而不是阻止所有权更改。
我也想知道在类别之间移动帖子。我必须相当频繁地执行此操作，尤其是在新用户发布到错误类别时。我天真地认为，这将导致一个类别参与者取消其提升，而新的类别参与者添加提升，但不会删除底层帖子，这样，如果其他人看到了并提升了帖子，他们的提升就不会因为类别参与者的提升消失而消失。
总的来说，在完成目前指定的特性开发后，无论目前有哪些限制，都非常希望了解启用此插件后，哪些操作将被禁止。
1 个赞
2 个赞
感谢您进一步的报告。我正在调查此事。
感谢您的报告，我们正在调查此事。
我理解您的想法，但是：
-
插件目前正在积极开发中，试图以这种方式解释事情将是徒劳的，因为解释可能会发生变化。
-
该插件已经处理了相当多的不同场景和边缘情况，如果我现在以叙述的方式解释每一个场景，将花费太长时间（即，多次完成这个长帖）。该插件已经有 400 多个不同的 specs。
-
尽管如此，限制通常在 PR 和 commit 的评论中以叙述的方式进行解释，我认为您已经阅读了。
这在 PR 中进行了深入讨论：
我限制了在 AP 主题中更改帖子所有者和创建帖子 wiki，即使是对管理员也是如此。这是因为远程 AP 帖子必须保留原始帖子的保真度，而这两种操作都可能破坏这种保真度。
可能有一种方法可以让联合与 wiki 和更改帖子所有者一起工作，但是我建议我们在未来的 PR 中将其添加为一项“功能”，因为它将涉及乘以或更改跨多个平台联合出去的对象的 actor。我认为我们永远无法允许更改导入的 ap 帖子的所有者（笔记），因为 actor/object 关联不由 Discourse 拥有，而是由内容创作的地方拥有。为了说明一个类比，在这种情况下，与导入的笔记关联的帖子的删除与其说是一种“删除”，不如说是一种选择不显示笔记的选择。
涉及移动帖子的场景有很多。我现在将处理您提到的特定场景，即在两个不同的 ActivityPub 启用的分类之间移动帖子。
您假设帖子在分类之间移动的唯一时间是帖子最初发布在错误的分类中，并且在帖子发布后不久就进行了移动。如果，在帖子发布 4 个月后，您将其移动到另一个分类，因为您想将某个帖子集合合并到一个不同分类的新主题中呢？在这种情况下，发送“撤销”以取消原始 boost 是否有意义？
这取决于我们讨论的是第一个帖子配置还是完整主题配置。对于前者，我们将为第一个帖子添加一个按钮，以便手动发布以专门处理分类移动场景。对于后者，自动添加 boost 可能是有意义的，我将进一步考虑。
我理解您的想法，但是我已经分享了关于第二阶段规范中最终状态的相当多的细节。除了该规范之外，并且尽可能温和地说，有太多的用例和场景需要我与您以及 Discourse.org 团队深入讨论，同时还要处理它们 
我将在第二阶段完成后，在 OP 中更新预期的行为的总体概述。
1 个赞
我无法重现此问题。我刚刚从一个测试的 Mastodon 帐户关注了 feature@meta.discourse.org，在 Mastodon 或 Discourse 中均未看到错误。
1 个赞
这可能与我关注的实例有关，这个实例有什么不寻常之处吗？
哎呀，在我试图提出一个清晰的问题时，我听起来好像在要求大量工作。我很抱歉沟通不当。我很感谢你深思熟虑的回复。
这正是我想要问的，而不是在这个帖子里持续的详细更新。我原意是想说“在当前指定的特性开发完成后”来阐明何时会有帮助，而不是要求你现在就描述未来的状态。我的问题措辞含糊不清。抱歉！
这正是我真正想理解的：大致来说，最终目标是将 Discourse 限制在仅支持标准 ActivityPub 的功能，还是在尽最大努力的基础上，将不受限制的原生 Discourse 体验联合到 fediverse？我过去与 Discourse 集成的经验让我期望尽最大努力；现在我明白你们的计划是追求保真度，以牺牲 Discourse 功能为代价，而这不仅仅是开发过程中的临时措施。
我并没有这样假设。为什么四个月会有区别呢？它现在被归入了一个联合类别，为什么这不会导致联合类别对其进行 boost？至少我天真地会期望发生这种情况。我经常看到人们 boost 几个月前的帖子，所以我不知道有什么特别的原因会导致这种情况不同。
是的，我认为发送对原始 boost 的“撤销”是有意义的。这似乎很常见。（事实上，撤销 boost 然后再进行新的 boost 似乎是“置顶”内容的常见机制；这与此目的无关，但说明了撤销 boost 的常用性，因此不应给其他 ActivityPub 实现带来问题。）
我现在看到 feature@meta.discourse.org 来自 mastodon.cloud 也是同样的情况，我认为它运行的是纯粹的 Mastodon。
1 个赞
就我个人而言，我两种想法都没有。Discourse.org 将在此设定整体议程，但总的来说，决策是基于它的工作方式和实际情况。如果有一种合理且可持续的方式来允许更改所有帖子的作者身份，无论其来源如何，那就太好了。
仅仅关注撤销原始推广，这种特定的撤销似乎没有意义？在某些情况下，它也可能有点令人惊讶，正如我的例子试图表明的那样。更改类别可能并不意味着要撤销（Undo）内容的原始“可发现性”。它可能是为了另一个原因而在以后更改内容的组织方式。
换句话说，在 Discourse 中对类别更改自动应用原始 Announce 的撤销在某些情况下有效，但在其他情况下则无效。即使在似乎更有意义的情况下，原始 Announce 也并没有真正造成任何危害。因此，遵循最小伤害和最小意外原则，似乎保留原始 Announce 更为合理。如果我遗漏了什么，我很抱歉。
从另一个角度来看，我认为将类别 Actor 的 Announce 活动等同于类别本身的分类角色是不正确的。Announce 是类别 Actor 与其关注者分享内容的方式，但它本身并不是一种分类。它是内容在 Fediverse 中被发现的一种方式。我认为类别和类别 Actor 的 Announce 活动之间不需要一对一的关系。
3 个赞
啊。那这确实是团队的问题了。
这也有道理。我同意，撤销这次提升的价值不大。
那么它就是一个边缘触发信号；它意味着“一篇文章刚刚进入此类别，无论是通过撰写还是移动到此类别”。这在概念上很简单。
然后我会以同样的方式考虑更改文章的作者身份。这将是新的参与者为新作者的文章创建一项新活动，并且没有特别的理由去处理在旧作者名下进行的旧活动，因为旧作者不会撰写任何编辑，也不应被归功于这些新更改。他们实际上并没有在 Discourse 上删除他们的文章，因此删除原始作者的活动不一定能反映某些基本事实。但是，旧作者的参与者之前发布的内容将是他们写的内容，没有理由删除这些文章。而且，如果有人点击链接回到 Discourse，他们将看到当前的内容和作者身份，并且（在有足够权限的情况下）可以看到编辑历史记录。
同样的逻辑也适用于维基。它们在 Discourse 下显示为单一作者身份，但允许其他人撰写。其他作者的更新并不被广泛归因（除非您有足够的权限阅读历史记录）。在 Discourse 的 Web 视图中，归因是否由头像显示，或者与活动关联的 ActivityPub 参与者显示，实际上并没有特别的意义；最终结果是通过一个或另一个渲染管道向另一端的读者呈现归因。
1 个赞
嗯，我不确定我是否同意。这样做的最终结果将在 Fediverse 中出现两个由不同参与者撰写的相同笔记，它们都将在多个平台上可见。对于第一次接触该内容的新用户来说，他们会看到由不同人撰写的相同内容。反之，当你在 Discourse 中更改作者时，你实际上是在重写历史，对于第一次接触该内容的新用户来说，你只看到新作者。你认为这之间有区别吗？
我不确定我是否完全理解。你的意思是，维基帖子的所有编辑，无论由谁进行，都应被视为标准更新活动，并归因于原始参与者（即发布者）吗？
请注意，这是此 PR 的主题，并附有说明性注释。
4 个赞