ActivityPub 插件

[mcdanlj (Michael K Johnson)]

@angus

我不确定我是否同意。这样做的最终结果是在 Fediverse 中出现两个由不同参与者撰写的完全相同的帖子，并且这两个帖子仍然可以在多个平台上看到。对于第一次接触该内容的新用户来说，他们会看到由不同的人撰写的相同内容。

嗯，Mastodon 用户会在时间线的上下文中看到它，而时间线通常是有限的。在 Mastodon 上，默认情况下，总时间线不超过 400 篇帖子。如果你查看原始内容，你实际上是在 Discourse 中查看。所以，虽然理论上是正确的，但我认为在实践中不会造成实际的混淆。你必须已经是关注者才能看到内容；点击链接到原始内容会带你进入 Discourse，在那里混淆会得到解决。

不完美，但也许是“最不坏”的选择？

我想，作为替代方案，你可以将编辑内容进行联合，并添加注释，说明该帖子已由所有权转移所取代，有点像添加“在我们的论坛上讨论此帖”链接？

相反，当你更改 Discourse 中的作者时，你实际上是在改写历史，对于第一次接触该内容的新用户来说，你只看到新作者。这之间存在差异，你不觉得吗？

当然，我并不是说它没有区别，只是说这似乎是一个可以接受的区别，而不是阻止一个有用且已得到利用的 Discourse 功能。

删除原始内容会使线程“孤立”，在与其他联合的平台上下文中，因为据我所知，你无法更改编辑中活动的参与者。

一种替代方案可能是，如果 Discourse 中的帖子与首次联合时不同，就完全停止联合编辑。也许会有一个警告？“更改所有者将禁用此帖子的联合，你真的想继续吗？”

@angus

我不太明白。你的意思是，Wiki 帖子中的所有编辑，无论由哪个用户进行，都应该被视为由原始参与者（即发布者）归属的标准更新活动？

是的。这在 Discourse 中对普通用户来说是这样的，他们可能不知道可以点击铅笔图标并查看更改进行审查，或者没有权限。在我看来，这些是正常 Discourse 使用中根深蒂固的：

• 将帖子设为 Wiki 意味着你接受其他用户在正常使用下以你自己的名义进行编辑。
• 即使不是 Wiki，拥有足够权限的用户也可以在 Discourse 中编辑你的帖子，具体取决于站点配置。

从我的角度来看，考虑到底层模型的差异，这已经是尽可能接近的等效了。

在我看来，“点击查看原始网站上的帖子”在 Fediverse 优先的实现之间已经显示出不同的内容，即使忽略了这个插件。可见的评论集不同，标记不同，文章处理方式也不同。所以，通过这个插件看到一些差异并不奇怪；我认为这是不可避免的。

（再次感谢你认真考虑这些想法。我认识到这些是困难的边界情况，我很感激这项工作，我不认为我的想法是最好的，我也不打算为这个阶段或任何阶段的工作造成任何义务，甚至不打算回应我所写的任何内容。）

[angus (Angus McLeod)]

@mcdanlj

嗯，Mastodon 用户会在时间线的上下文中看到它，而时间线通常是有限的。在 Mastodon 上，默认情况下，总时间线不超过 400 篇帖子。如果你查看原始帖子，你实际上是在查看 Discourse。所以，虽然理论上是这样，但我认为这在实践中不会造成实际的混淆。你必须已经是关注者才能看到内容；点击链接到原始帖子会带你进入 Discourse，在那里混淆会得到解决。

就像类别更改一样，我认为这真的取决于具体情况。例如，考虑一下：

1. 帖子 1 由用户 1（Actor 1）在类别 1 中创建
2. 2 分钟后，帖子 1 的作者被用户 3（管理员）更改为用户 2（Actor 2）
3. 类别 1 被来自 20 个域和 5 种不同软件平台的 400 个 Actor 关注，每种平台对时间线和内容发现的实现略有不同。
4. 在帖子 1 创建后的 2 分钟内，有 2 条具有相同内容和不同 Actor 的笔记被发布给这 400 个关注者。

我认为这很可能会让相当一部分关注者感到困惑，更不用说用户 2 可能甚至没有意识到他们的名字现在与他们在 20 个不同域上的这些重复内容相关联，而这些内容不是他们写的。他们可能可以接受管理员在单个实例上这样做，在发布到该实例时，这在某种程度上是隐含同意的，但是，我认为我们应该非常谨慎地将这种隐含同意扩展到整个 Fediverse，尤其是在复制内容的这种不完美的情况下。更改帖子所有者是一项强大的管理功能，特定于 Discourse，并且隐含地与单个实例的“社交契约”相关联。

@mcdanlj

在我看来，这些都根植于正常的 Discourse 使用中：

• 将帖子设为 wiki 意味着你接受他人对你名下的正常使用的编辑。
• 即使它不是 wiki，根据站点配置，具有足够权限的用户也可以编辑你的 Discourse 帖子。

我认为 wiki 的情况更强一些，但我会再次观察你已经暗示过的。Wiki 是根植于正常的Discourse 中的概念。将任何人的编辑（不仅仅是员工）与原始作者相关联是一个 Discourse 概念，在 ActivityPub 中没有类似的概念。我们应该谨慎地通过 ActivityPub 的标准方法将这个概念扩展到整个 Fediverse。这些更新活动将被视为与其他实例和软件平台上的任何其他更新活动一样，脱离了它们原始的 wiki 上下文。此外，正如你所暗示的，员工和高度信任的用户编辑他人帖子的能力已经存在潜在问题。我认为在讨论 wiki 之前，需要对这个更有限的问题进行更多考虑。

我并不是想在 Discourse 和 ActivityPub 之间为这些功能设置一个二元选择。我想说的是，我们不应该仅仅试图将敏感的 Discourse 功能映射到 Fediverse，而不仔细考虑后果。默认情况下，这些更敏感的功能在 ActivityPub 帖子上应该是禁用的，直到我们更有信心我们不会损害或意外地给相当一部分用户或用例带来麻烦。

就个人而言，我认为我们在这两方面都还没有达到那个阶段，尽管我的直觉是，wiki 的情况在这个阶段有更大的潜力，即使我还没有找到一个好的解决方案。

[pmusaraj (Penar Musaraj)]

@angus

支持“喜欢”活动

• 请参阅 活动词汇表

支持 Discourse 用户在 Mastodon 上验证其身份，以便从其 Toots 创建的 Discourse 帖子与他们的 Discourse 用户帐户相关联。

• 允许用户执行 Mastodon OAuth 授权流程，与存储其帐户的 Mastodon 服务器进行交互。这从用户的 Discourse 帐户设置中启动。
• 使用 Discourse 用户的 Mastodon 访问令牌，获取并存储其 Mastodon 帐户的 AP ID，并将其与 Discourse 帐户一起存储。
• 将与 Actor 发布的 AP 活动相关联的所有 Discourse 活动（该 Actor 拥有 Discourse 用户的 AP ID）与该 Discourse 用户相关联，无论这些活动是在用户验证身份之前还是之后执行的。

这两个项目现在也已完成，我刚刚合并了 @angus 的 通过 OAuth 进行身份验证的 PR。除错误修复和性能改进外，这标志着当前阶段插件功能添加的完成。

目前，该插件功能非常丰富。快速回顾一下主要功能，该插件支持：

• 仅关注者帖子发布到 ActivityPub（默认为公开）
• 首帖或完整主题发布（默认为首帖）
• 使用完整主题发布时的双向同步，即主题中所有 Discourse 创建的帖子都将发布到 ActivityPub，反之亦然，ActivityPub 中的回复将发布到 Discourse
• 可选将帖子发布为“笔记”（适用于像 Mastodon 这样的短内容服务）或“文章”（更适合长内容服务）
• 身份验证

接下来，我们将致力于微调现有功能，改进可用性。当然，我们仍然欢迎反馈。我特别感兴趣的是如何向普通用户解释所有这些工作原理，这并非易事。

@mcdanlj

**大体来说，**最终目标是将 Discourse 限制为仅支持标准 ActivityPub 功能，还是在尽力而为的基础上，将不受限制的本机 Discourse 体验联合到 fediverse？

@angus

我个人不这么想。 Discourse.org 将设定整体议程，但大体上决策是基于其工作方式和实际可行性。如果有一种合理且可持续的方式允许更改所有帖子的作者身份，无论其来源如何，那就太好了。

我非常赞同 @angus 的观点，我们的目标是做实际可行且付出合理努力就能实现的事情。为此，我们愿意在此时接受 Discourse 功能有所减少。这是我们找出特定限制是否重要以及如何解决的最佳途径（例如，插件用户是否经常遇到 wiki-ActivityPub 的限制？）。

[mcdanlj (Michael K Johnson)]

@pmusaraj

为此，我们愿意接受 Discourse 目前的一些功能缩减。

那么，我的理解正确吗？我们现在是否到了可以明确限制的地步了？

[Matthias_Schuster (Matthias)]

你好

首先，感谢你开发了这一切。

其次，我非常感兴趣将不同的 ActivityPub 服务连接在一起，据我所知，这主要是关于在 Discourse 和 Mastodon 之间来回发送消息。

我知道该协议是独立于服务的，但是否有任何文档可以，比如说，连接不同的 Discourse 实例，或者集成 Nextcloud、PeerTube 等？

[angus (Angus McLeod)]

@mcdanlj

我们是否应该明确这些限制了？

我们目前已在 ActivityPub 主题中禁用了帖子作者更改和 wiki 功能，原因如我之前所述（它们的假设开箱即用无法与 ActivityPub 配合使用）。这是唯一两个在此类 ActivityPub 主题中被暂时禁用的功能。任何其他功能受限的情况都应报告为问题。

@Matthias_Schuster

那么，我真的很想将不同的 ActivityPub 服务连接在一起，据我所知，这主要是关于在 Discourse 和 Mastodon 之间来回发送消息。

我知道该协议是服务无关的，但是否有任何文档可以用来连接不同的 Discourse 实例，或者集成 Nextcloud、Peer Tube 等？

这是一个 ActivityPub 插件，它严格遵循 ActivityPub 规范，因此它能够与遵循该规范的任何服务配合使用，包括您提到的所有服务（以及其他服务）。我们首先专注于与 Mastodon 集成，因为实际上，您必须一次确保与一个服务的兼容性，而 Mastodon 是最大的 ActivityPub 平台。

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

在 https://meta.discourse.org/u/rokejulianlockhart/preferences/activity-pub 尝试了两次

• https://meta.discourse.org/ap/auth/oauth/redirect?code=N7bmMhl5YsaASW-D7U-wHxeQzNVtV4O2a-5siMp_Ax8
• https://meta.discourse.org/ap/auth/oauth/redirect?code=InxG0OIEqB1WH7tuNWtaiF9UpC8NAPJ8uBuvZ7fgqZ4

```json { "errors": ["You are not permitted to view the requested resource."], "error_type": "invalid_access" } ```

我该怎么办？

[angus (Angus McLeod)]

嘿 @rokejulianlockhart，感谢您的反馈。您是如何执行授权流程的？您是在浏览器中（请问是哪个浏览器？）点击上面截图中的“授权”，还是以某种方式复制/粘贴网址？我之所以这么问，是因为您的帖子中包含了这些网址。下面是我在 meta.discourse.org 上成功运行的标准流程的视频：

您做的有什么不同吗？

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

@angus

你做的和那个有什么不同吗？

@angus,

0. 

   rokejulianlockhart@mastodon.social

1. 

2. 

   您即将以用户名“rokejulianlockhart”登录网站“mastodon.social”，但该网站不需要身份验证。这可能是试图欺骗您。

   “mastodon.social”是您想访问的网站吗？

   我在这里点击

   是

3. Log in - Mastodon
   

   

   需要授权
   meta.discourse.org 希望获得访问您帐户的权限。这是一个第三方应用程序。如果您不信任它，则不应授权它。
   查看权限

   帐户
   只读访问

   我在这里点击

   授权

4. 然后出现之前的

   “mastodon.social”是您想访问的网站吗？

   提示，我做了同样的操作。

5. https://meta.discourse.org/ap/auth/oauth/redirect?code=s2H3Og_3oLTb8cAsYN9Kmgeh8xPySeOaWSp2bdZ2sEE

   0. .JSON

      {"errors":["您无权查看所请求的资源。"],"error_type":"invalid_access"}
      

   1. Headers

      X-Firefox-Spdy: h2
      content-encoding: gzip
      content-type: application/json; charset=utf-8
      date: Mon, 25 Sep 2023 11:39:30 GMT
      referrer-policy: strict-origin-when-cross-origin
      server: nginx
      vary: Accept-Encoding
      x-content-type-options: nosniff
      x-discourse-route: o_auth/redirect
      x-discourse-username: rokejulianlockhart
      x-download-options: noopen
      x-frame-options: SAMEORIGIN
      x-permitted-cross-domain-policies: none
      x-request-id: 01276bd6-77ea-42ae-8f60-6fa365a70e1f
      x-xss-protection: 0
      
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
      Accept-Encoding: gzip, deflate, br
      Accept-Language: en-GB,en;q=0.7,en-US;q=0.3
      Connection: keep-alive
      Host: meta.discourse.org
      Sec-Fetch-Dest: document
      Sec-Fetch-Mode: navigate
      Sec-Fetch-Site: cross-site
      Sec-Fetch-User: ?1
      Upgrade-Insecure-Requests: 1
      User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0
      

[aboutDavid (David)]

您好，在最新的更新后，用户个人资料（/u/user）似乎出现了问题。用户名和头像会显示出来（以及顶部的用户违规列表）。

我们检查了插件列表，逐一禁用它们，直到问题消失。启用安全模式后问题也得到了解决。以下是我们收到的一些客户端错误：

Cannot read properties of null (reading 'getBoundingClientRect')
at Object.offset (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:5104:37)
at e.scrolled (https://amcforum.wiki/assets/discourse-9756bc4a118ac228ac6ac3f2b29c7d4a7d60a9f16ece25de4a772f0055c6eb94.js:2347:106)
at p.invoke (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4339:182)
at p.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4331:141)
at h.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4346:207)
at $._end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4410:9)
at $.end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4363:240)
at $._runExpiredTimers (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4417:192)

启用插件后，这是您（自己的帐户）的显示情况：

这是另一位用户（9pfs）的情况：

这是插件引起的另一个有趣的 bug：

我们目前运行的是 3.2.0.beta2-dev（来自此提交），插件版本为 0.1.0（来自此提交）。

[angus (Angus McLeod)]

@rokejulianlockhart 您是否禁用了 Cookie 或运行了某种隐私扩展？授权流程目前依赖于安全的会话 Cookie 来工作。

@aboutDavid 感谢您的报告。虽然有可能，但您所分享的内容似乎不太可能是由此插件引起的问题。您能否分享一个您的网站链接？另外，您是否启用了任何主题或主题组件？

[Firepup650 (Firepup Sixfifty)]

@angus

您分享的内容似乎不太可能是由此插件引起的问题。您能否分享一个您的网站链接？另外，您是否启用了任何主题或主题组件？

从安全模式故障排除中，我们确切地知道以下几点：

1. 这是一个非官方插件
2. 它不是主题或主题组件。

据我所知，我们有两个非官方插件：

1. Animate avatars（已手动确认不是罪魁祸首）
2. ActivityPub

至于网站链接：

Active Member Chat

[hello-smile6 (9pfs)]

@Firepup650

据我所知，我们有两个非官方插件

升级 UI 在除这两个插件之外的所有插件旁边都显示一个勾号（表明它们是官方插件）。

[angus (Angus McLeod)]

您网站上的问题很可能是由使用了 user-profile-avatar-flair 插件出口的内容引起的。该插件不使用该出口。但是，动画头像插件会使用。

@Firepup650

手动确认不是罪魁祸首

您是如何确认的？

[hello-smile6 (9pfs)]

@angus

你是如何确认的？

@aboutDavid 检查并确保该插件没有客户端 JavaScript。问题是否部分出在服务器端？

[angus (Angus McLeod)]

客户端没有 JavaScript 并不一定意味着没有客户端问题。在这种情况下，问题似乎源于插件插槽的使用方式，可能是在模板中。您能否尝试移除动画头像插件并告知结果？

（顺便说一句，动画头像插件确实有客户端 JavaScript。例如，请参阅）。

[david (David Taylor)]

我在 Meta 上编辑了一个类别（以更改某些组访问权限）。我没有更改任何与 activitypub 相关的设置，但我们在管理员日志中得到了这三项条目：

我想它们实际上是从 nil 变为其默认值，所以行为上没有实际改变？不过，最好避免这种移除日志记录，以免引起混淆。

[angus (Angus McLeod)]

谢谢你的报告大卫，我很快就会看看。

[aboutDavid (David)]

哎呀，我今天有点笨，抱歉

编辑：是的，很可能是动画头像，抱歉浪费你的时间，哈哈

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

@angus

@rokejulianlockhart 你是否禁用了 cookies 或运行了某种隐私扩展？授权流程目前依赖于安全的会话 cookie 来工作。

@angus，据我所知没有。

并且我确保禁用了 uBlock Origin，尽管我并不使用隐私列表。

---

然而，我今天在测试此功能时遇到了另一个问题。

Log in - Mastodon

客户端身份验证失败，因为客户端未知、未包含客户端身份验证或使用了不支持的身份验证方法。

Google Search.