是的，Discourse 可以通过其评论嵌入小部件实现类似的功能。除其他外，这可能有助于减轻一些人在启动一个只有少数活跃用户的论坛时所经历的尴尬：https://meta.discourse.org/t/ai-sockpuppet-accounts-to-jumpstart-my-community/292396。新的 Discourse 站点可以使用博客文章来推广和引导其论坛。现在这种情况在某种程度上是可能的，但允许用户直接从嵌入小部件进行评论将使整个过程更加无缝。
3 个赞
在 WordPress 端提供一个简单的、与 Discourse 连接的评论表单，这样访问者就不必先访问 Discourse 并在此创建账户，然后再发表评论，这有助于减少阻力并提高参与度，至少对于像我这样的发布者是如此。
就我的用例而言，最理想的情况是评论者只需提供姓名和电子邮件地址即可发表评论。然后，可以使用这些信息在 Discourse 中创建一个暂存用户，并邀请他们完全加入以继续对话，而不会阻止他们发表评论。
我们发现，创建账户才能在已发布的文章上发表评论所带来的额外阻力，使得提高参与度和最终在我们的论坛中发展社区变得困难。例如，当被问及我们的评论部分（使用当前的 Discourse-WordPress 集成）时，一位作者给了我们以下反馈：
关于对话区域：既然你提到了……我记得看到过。当时，我实际上认为我会暂时忘记它，因为它似乎需要花费很多时间来注册。这有力地证明了大多数人对必须经历这个过程的感受。我通常近乎痴迷地想看到对我的写作的评论。我记得我自嘲地笑着说：“我想我没有那么痴迷，以至于要现在处理这个。” 理想情况下，你应该对所有人开放评论，无需注册。但任何程度的简化/便捷都会提高参与度。像这样的评论通常是一种冲动行为。如果人们遇到任何阻碍，他们往往会继续前进，而不是花时间。
3 个赞
我前几天刚想到这个问题。奇怪的是，我有点怀念博客文章中的WordPress评论，因为人们似乎可以很快上手，门槛非常低。
尽管有一个非常简单的注册流程，但现在如果有人想评论一篇文章，他们必须访问一个新页面。我认为跨越这个门槛可能会让人觉得太麻烦。感觉就像我想评论A，但我必须访问B来评论A，然后回到A来看评论。直接在A下面评论A会感觉更自然。
我喜欢分阶段用户的想法。我想也许可以通过让WordPress评论表单向Discourse论坛发送电子邮件，然后通过这种方式分阶段用户来黑入它，尽管我想象一下，这样完全集成可能会变得更加复杂。
3 个赞
我认为以前是可以这样做的，但我很确定 Discourse 现在会将电子邮件的“发件人标题”与退信地址进行比较。如果两者不匹配，电子邮件将被拒绝。（如果 Discourse 没有检查退信地址，评论系统很容易被滥用——任何电子邮件地址都可以输入到表单中。）
有几种方法可以解决 Discourse 作为评论系统的问题。我认为最好的方法是让 Discourse 改进其评论嵌入式 iframe，以便用户可以作为已认证的 Discourse 用户与之交互。如果那不可行，可以开发一个嵌入式的 Discourse 评论 Web 应用程序。那将是一个有趣的项目，但在深入研究之前，我想确保 Discourse 不会通过其嵌入式评论 iframe 提供类似的功能。
还有一些特定于 WordPress 的解决方案。最简单的一种是启用 WordPress 评论 和 WP Discourse 插件。风险是这会减少 Discourse 论坛上的活动。我认为可以通过 WordPress UI 来帮助解决这个问题——例如，链接到 Discourse 上正在进行的对话。
还可以开发专门针对充当 Discourse SSO 提供程序的 WordPress 站点的功能。我在该主题的先前帖子中对此进行了介绍。要做好这项工作可能需要对 WP Discourse 插件进行重大更改。除非（我在这里自言自语）：
我想通过上面的截图说明的是，对于充当 Discourse SSO 提供程序的 WordPress 站点，评论可以显示在 Discourse 评论 iframe 中。评论可以通过一个发布到 Discourse API 的表单创建。这可能需要对 Discourse 评论 iframe 进行一些更改，以确保在新评论添加时刷新它，但不需要用户能够作为已认证的 Discourse 用户与之交互。
4 个赞
所以，如果我理解正确的话，这个想法是评论者在 WordPress 端注册，然后通过嵌入的 Discourse iframe 发表评论，该评论会发布到 Discourse 的主题上，然后刷新 WordPress 上的显示，使其立即显示出来。
我想 WordPress 的注册过程会验证电子邮件。但这还需要将 Discourse SSO 提供商切换为 WordPress——这是可行的，但有些不幸，因为它将摩擦转移到了另一方，对于那些可能只想注册论坛的人来说。
我倾向于同意你在这里所说的：
如果甚至可以在 iframe 中直接 注册，或者至少是分阶段进行，这样就可以继续评论（只有在电子邮件验证后才能发布），这对我来说将是一种平衡易用性和安全性的解决方案。
2 个赞
是的，你理解对了。如果 WordPress 是 SSO 提供商，那么允许用户评论 Discourse 主题的问题并不难解决。就与 WP Discourse 插件的当前状态协同工作而言，棘手的部分是如何在 WordPress 上显示评论——目前 WP Discourse 的评论部分并不镜像 Discourse 主题的回复。相反，它会显示精选的“最佳”评论。
更新 WP Discourse 插件来处理这种情况是可能的，但要正确处理，就需要完全重写它处理 Discourse 评论的方式。这不是我能决定的，但我认为改进 Discourse 评论 iframe 会是更好的时间利用方式。
5 个赞
我只是想为想要此功能的用户增加我的声音。
如果 WP 用户能够直接在 WP 的帖子下注册/登录并发表评论，而无需导航到论坛，那就太好了，这样整个体验会更像一个评论系统。他们的评论将同时显示在帖子下方和创建的 discourse 线程中。他们始终可以选择无缝地仅在 discourse、仅在 wordpress 或同时在两者中发布。我不知道这该如何实现，但这将是集成 WP 评论和 Discourse 的一种非常无缝的方式，感觉不那么笨拙，并且无疑会大大增加我们从现有插件获得的评论数量。
3 个赞
也许是这个：
但据我所知，它完全劫持了 Discourse 的登录。
这将允许用户直接在 WordPress 帖子下发布评论，并自动将该帖子填充到相应的 Discourse 线程中吗？
我正在着手处理这个问题。第一个版本是为使用 Remix 框架作为前端的无头 WordPress 网站准备的。完成后，我将为常规 WordPress 网站制作一个版本。这很可能是一个扩展 WP Discourse 插件的插件。我希望我为无头 WordPress 网站所做的大部分工作都可以迁移到常规 WordPress 网站，但这可能需要一些妥协。
允许用户直接从外部网站发表评论很容易实现。主要要求是外部网站能够访问用户的 Discourse 凭据。这可以通过将外部网站用作 Discourse 的 DiscourseConnect 提供商，或者将 Discourse 配置为外部网站的 DiscourseConnect 提供商来实现。
在第二种情况下——即外部网站不是 Discourse 的 DiscourseConnect 提供商——当用户第一次想从外部网站发表评论时，他们需要点击一个链接，将他们在外部网站的账户与他们的 Discourse 账户关联起来（或者在他们尚未注册 Discourse 的情况下注册 Discourse）。从用户的角度来看，这可以非常顺畅。
然而，上述更改并不能使整个体验感觉像一个常规的评论系统。对于评论系统，人们通常的期望是能够阅读和与所有评论进行交互。WP Discourse 插件只显示从 Discourse 提供的特殊路由中拉取的一系列精选评论。它不提供与评论交互的任何功能。
问题的难点在于：
- 在 WordPress 上分页显示一个主题的所有评论，同时考虑到评论可能成千上万条。
- 提供一个用户界面，让用户能够了解他们在长长的评论列表中所处的位置。
- 弄清楚如何显示直接回复其他评论的评论。（Discourse 的这方面约定与大多数评论系统处理回复的方式不一致。）
- 允许用户直接回复某条评论、点赞某条评论、编辑自己的评论等。
- 处理在 Discourse 上创建的评论，这些评论可能包含在外部网站上不易渲染或交互的内容或标记。例如 oneboxes、投票……
- 提供一种按最新、最旧、最佳等过滤评论的方式……
所有这些都需要在不给外部网站服务器带来过大负载、不向 Discourse 发送过多 API 请求、不消耗用户设备过多内存（目标是创建一个轻量级的评论系统）的情况下完成。这是可以实现的，但不能简单地将其添加到现有的 WP Discourse 代码中而不进行重大更改。
4 个赞
很高兴听到你已经开始着手了！
只是一个想法：既然部分想法是为了减少人们发表评论的阻力，那么专注于第一次评论的无缝体验可能是一个好主意。如上所述，许多人似乎只想用他们的电子邮件地址发表评论；那么问题就在于验证和登录，或者创建账户（我想这取决于 DiscourseConnect 的配置方式）。
一旦用户进入，我预计他们更有可能访问相应的论坛主题，以获得所有基于 Discourse 的讨论功能。我只希望这个问题的所有困难部分不要阻碍解决“第一次评论”的问题。拥有数千条评论，我们必须弄清楚分页问题，那将是“一个幸福的烦恼”。 
4 个赞
这对我来说足够了，因为新老用户将参与并相互互动。对我来说，外部的image|690x215, 50%
image|690x429, 50% 没什么大不了的。
是的，这是个真正的担忧。第一步是上线一个演示站点。有一个实时站点来测试事物应该能清楚地表明阻力点在哪里。
允许匿名用户评论帖子在技术上可能是可行的。我能想到的唯一非黑客的方式是让一个真实用户代表匿名用户发布评论。但这感觉有点奇怪。
我知道 WordPress 有一个允许“访客”用户创建评论的设置。它的限制是，如果创建访客评论的用户在创建评论后在站点上注册，那么“访客”评论将不会与真实用户关联。代表某人发帖必须以类似的方式工作——无法知道创建匿名评论的用户是他们提供的电子邮件地址的所有者。
理想情况下，用户将在外部站点或 Discourse 上进行身份验证，然后再创建评论。
从用户的角度来看，最少的阻力是外部站点是 Discourse 的 SSO 提供商的情况。这样他们就可以评论 Discourse 主题，而无需访问 Discourse 站点。
从站点所有者的角度来看，最容易的技术身份验证方式是让 Discourse 作为外部站点的身份验证提供商。这是我目前在本地测试站点上使用的配置。外部（Remix）站点甚至没有用户表。它只是根据 Discourse /session/sso_provider 路由的响应来创建用户会话。
使用 Discourse 作为外部站点的身份验证提供商的缺点是，它迫使用户通过 Discourse 注册/登录过程。这个过程本身没什么问题，只是它似乎迫使用户下载所有 Discourse 资源，而他们可能只想在外部站点上发表评论。所以有点慢。我会进一步调查……
是的 也许将其减少到几百条以获得更现实的场景。我想说的重点是，一旦你超过一页帖子（20 条帖子），问题就会变得复杂。
编辑：可以使用 Discourse 邀请来简化流程——如果匿名用户想评论帖子，评论表单旁边会显示一个电子邮件字段。提交评论将触发 Discourse 向该电子邮件地址发送邀请。评论将被保存在队列中，直到邀请被接受。这将允许用户在他们有灵感时创建评论，并让他们立即获得关于评论状态的反馈。
4 个赞
我很期待看到 @simon 在这方面有什么解决方案。
我只是想指出，在这方面正在开发的另一个解决方案是使用 ActivityPub。在其最新版本中，官方的 Wordpress ActivityPub 插件增加了对 Discourse ActivityPub 插件的支持。
这意味着，如果您安装了 Wordpress ActivityPub 插件和 Discourse ActivityPub 插件，您所需要做的就是设置一个类别来“关注”一个发布帖子的 Wordpress 作者（或整个 Wordpress 网站），您的 Wordpress 帖子将作为新主题出现在该 Discourse 类别中。
（请注意，Wordpress 插件有发布延迟，这就是为什么在视频中它需要一分钟才能出现在 Discourse 中；跳到 1:40 处可以看到它出现）。
Wordpress ActivityPub 插件也支持活动摄入，并且已经设置好将回复帖子的传入活动处理为该帖子的“评论”，但是这部分目前还不能与 Discourse 插件发送出的活动一起工作（我认为 Wordpress 插件尚不支持已发布的笔记）。但这应该很快也会奏效。
参见更多
6 个赞
请注意，Wordpress 插件的维护者 Matthias 已经解决了这个问题，因此很快就可以通过 ActivityPub 在 Discourse 和 Wordpress 之间实现发布共享和原生的双向评论。
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
3 个赞
这个话题的初衷是，由 Discourse 驱动的评论系统可以提供与 Coral 类似的功能，并增加了将网站评论分离成常规 Discourse 话题的好处。Discourse 提供了审核网站评论的能力，并允许与评论相关的讨论在论坛上进行。
我认为无需争论审核的必要性。
允许评论分离成实际的 Discourse 话题的需求可能不太明显。我的假设是，进行任何形式的在线对话都很困难——面对面的交流提供了各种在线上不存在的微妙线索。与超过少数人进行有意义的在线对话几乎是不可能的。这就是 Discourse 发挥作用的地方。Discourse 的群组功能提供了限制谁可以参与话题的能力。评论者群组可以被允许参与封闭的 Discourse 话题。这在某种程度上与 fediverse 的工作方式相反。
话虽如此，我对 Discourse/WordPress fediverse 集成如何工作感到好奇。例如，如果 Sally 评论了 Bob 的 WordPress 帖子，如果她有一个 Discourse 账户，她的评论会发生什么？如果她没有 Discourse 账户，她的评论又会发生什么？Sally 是否有任何方法可以选择不将她的评论发布到 fediverse？
跑题了，但随着西方国家正在实施或提议的各种在线伤害类型的法案，如果 Sally 的评论被认为具有冒犯性，谁将负责发布它？我假设目前这是一个无法回答的问题。
3 个赞
很有趣！
我建议这样理解 ActivityPub 如何处理审核和分组（以及其他在线沟通的规则）：它主要是一个通信标准。它提供了一些机制来处理这些问题，但很大程度上将它们留给系统中的各种客户端。
电子邮件作为一个通信标准，是一个不完美的，但或许有用的类比。“电子邮件”是一系列通信标准，允许您与互联网上的任何人交换消息。它存在各种“质量控制”问题，例如垃圾邮件。我们称之为“电子邮件”的这套标准中有一些方面有助于解决这些问题（例如 DMARC、DKIM、SPF 等），但也许质量控制的主要处理方式是在电子邮件客户端本身。Gmail 之所以成为一个流行的电子邮件客户端，部分原因在于它在处理垃圾邮件（以及类似的质量控制问题）方面做得相当好。
沿着这个类比，Discourse 将是 ActivityPub 的“Gmail”。所有使 Discourse 成为一个出色的讨论平台的审核工具、用户分组和其他功能（几乎）仍然可以在 ActivityPub 的上下文中获得。我将通过开始回答您的问题来详细说明这一点。
我将首先描述会发生什么，然后我们也许可以继续讨论更细致的问题。为了回答基本问题，我将省略很多细节：
-
Sally 的评论作为 ActivityPub 对象从 WordPress 发布。
-
该对象被 Discourse 摄取并转换为一个帖子。
-
如果 Sally 的“Actor”与 Discourse 中的用户账户相关联，该帖子将与该用户账户相关联。如果她的 Actor 尚未与用户账户相关联，将从 Sally 的 Actor 创建一个暂存用户，他们将拥有该帖子。
您可以在此主题中看到上述过程：
-
Discourse 的类别 WordPress - SocialHub 正在关注 Matthias 的 WordPress。
-
Matthias 使用他的常规 WordPress 账户在他的博客上发布了一篇新文章。
-
这在 Discourse 中显示为一个新主题，帖子与与 Matthias 的 Actor 相关联的暂存用户相关联。
-
评论的工作方式完全相同。
只是为了回答可能最明显的问题：Matthias 能否将从他的 WordPress Actor 创建的“暂存”用户与他在该服务器上的常规 Discourse 用户进行协调？
短期答案是，Discourse 插件有一个“授权”功能集，目前允许您声明您在其他 Discourse 服务器或 Mastodon 服务器上的 Actor 的所有权，这会将任何此类暂存用户合并到您的账户中（这意味着您现在在您的主 Discourse 账户中拥有这些帖子）。该功能集可以扩展到 WordPress。我承认这有点啰嗦，通过这个演示可能更容易理解我的意思：
长期答案是，身份证明可能在某个时候被嵌入到 ActivityPub 活动中，也许消除了用户驱动的授权的需要，这意味着“协调”可能是（更）自动的。
鉴于 Matthias 仍然通过他的 ActivityPub Actor 控制他的暂存用户的身份属性（这可以在 WordPress 上编辑，编辑内容会传播到 Discourse 上的暂存用户），也许另一个问题是“协调”是否必要。
我说的这些大部分是为了铺垫，以便我们可以继续讨论您更细致、更重要的问题。我希望到目前为止我解释得清楚。
2 个赞
很有意义。
关于审核问题，我指的是使用 Discourse 来审核 WordPress 评论。这就是允许 Discourse 以类似于 Coral 的方式使用的功能。如果 WordPress 评论实际上是 Discourse 评论，通过 API 从 WordPress 发布到 Discourse，那么这很容易实现。它开箱即用。这允许使用 Discourse 提供的任何由 AI 驱动的审核工具。我想知道通过 WordPress/Discourse ActivityPub 集成是否可以实现类似的功能。
暂存用户的身份证明是什么？他们的电子邮件地址是从源服务器传递过来的吗？
就我（个人）而言，不希望将内容发布到整个联邦宇宙，似乎在技术上可以在 Discourse 站点和 WordPress 站点之间建立一对一的 ActivityPub 关系，但我不知道这是否会破坏 ActivityPub 协议的宗旨。
编辑：值得补充的是，目标是创建一个网站与其关联的 Discourse 论坛之间的双赢关系。Discourse 的审核工具旨在提供保证，表明网站的评论系统得到了良好的审核。网站的评论部分旨在用于为 Discourse 站点提供主题和用户。
2 个赞
从 ActivityPub 对象转换而来的帖子与通过 API 创建的帖子应用了基本相同的前置处理和后置处理函数。入口点不同（即 ActivityPub 控制器而不是 posts 控制器），但帖子的创建方式基本相同。
*从技术上讲，如果你通过 API 创建一个帖子，实际处理是通过 NewPostManager 完成的，然后它将大部分工作交给 PostCreator。NewPostManager 处理的主要内容（就我们而言）是审核队列。其他所有内容都在 PostCreator 中处理。
目前，ActivityPub 插件会跳过 NewPostManager，而是将其交给插件自己的 PostHandler 中的 PostCreator。我这样做主要是为了在初始实现中降低复杂性。插件的 PostHandler 没有内在原因不能将帖子交给 NewPostManager 并从中受益于审核队列检查。
总之，通过 ActivityPub 插件创建的帖子与通过普通 API 创建的帖子之间没有实质性区别。
这有几个层面。
-
首先，从源服务器到你的服务器的 POST 请求使用 HTTP 签名进行签名，以确保请求确实来自源服务器。
-
其次，该源服务器上的每个 Actor（即用户）都有一个 UUID，即与其域关联的 ID，在 fediverse 中是唯一的。它看起来像这样：
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619dActivityPub 不使用电子邮件。
-
你收到的每个 Activity（例如，创建帖子状对象）都与一个 Actor ID 相关联。每个 Actor ID 都可以解析为 Actor 属性。
-
因此，当你的服务器收到一个“Activity”（例如，创建一个新的帖子状对象）时，根据你收到该活动的域，你知道执行该活动的 Actor 的属性。你信任发送域，但这总是如此，例如，Discourse 信任带有 WP Discourse 插件的 WordPress 实例来发送正确的用户属性。
因此，暂存用户本身不需要身份证明 本身，就像通过电子邮件创建的暂存用户不需要身份证明一样。
身份证明的需要出现在 ActivityPub Actor 的真实用户与另一个 Discourse 帐户（如上面 Matthias 的例子）想要合并（或“对账”）他们的身份时。他们可能不喜欢在一个 Discourse 上实际上有两个“用户”。我应该指出，没有这种对账，他们可以控制
- 通过源域控制 ActivityPub Actor / 暂存用户的身份属性，例如，通过更新他们的 Wordpress 配置文件，这些更新被联合，Discourse 应用相同的；以及
- 通过源域控制 ActivityPub Actor / 暂存用户的相关内容，例如，通过编辑他们的 Wordpress 评论，发送一个 Update 活动，然后由 Discourse 处理。
但尽管如此，他们可能觉得在 Discourse 上实际上有两个用户“很麻烦”。这就是为什么该插件具有“授权”功能集，允许你显示你的普通 Discourse 用户与具有暂存用户的 ActivityPub Actor 相关联。这目前通过特定于平台的授权机制完成：
- 对于 Mastodon，通过 Mastodon 的 OAuth API 完成。它要求你对你的 Mastodon 帐户进行身份验证，以证明你控制相关的 Actor。
- 对于 Discourse，通过用户 API 完成。这在我之前的帖子中的视频中有所展示。
- 对于 Wordpress，有几种方法可以完成同样的事情，例如，通过 WP Discourse 插件的 DiscourseConnect。这尚未实现。
一旦你证明你拥有与暂存用户关联的 Actor，暂存用户就会与你的普通用户合并，他们的帖子就归你所有，并且与该 Actor 关联的任何新 Activity 都会自动归你所有。但这个功能集实际上更多是为了改善用户体验，严格来说并非必需。这些各种用户的真实用户从一开始就控制着用户属性及其内容。
是的，可以控制传出发布的接收者，并限制传入发布的来源。这是否破坏了 ActivityPub 的目的值得商榷。严格来说，ActivityPub 只是一种标准。我认为没有理由不能以这种方式使用该标准。历史上，ActivityPub 一直与去中心化社交网络相关联，特别是 Mastodon，这可能是为什么你觉得这种方法破坏了 ActivityPub 的目的。但我会区分 ActivityPub 标准本身及其现有的实现。
此外，在此上下文中，我想指出，就像电子邮件一样，我们所说的“ActivityPub”实际上是一系列标准。标题为“ActivityPub”的标准文档必须与另一个名为“ActivityStreams”的标准文档一起阅读，该文档描述了这里的主要对象。ActivityStreams 标准比 ActivityPub 本身更“服务中立”（即，与去中心化社交网络的关系较少）。
再举一个类比，区块链作为一种技术，仅仅是一个去中心化账本，我第一次听说它时，它让我想起了托伦斯土地登记系统，该系统是在 19 世纪（在澳大利亚）发明的，其原因与区块链的发明基本相同（即防止房地产交易欺诈）。但区块链最流行的实现是比特币，它有（不同的）特定用途和某些文化价值。这个类比不是最好的，但有一种思考方式是，Mastodon 和去中心化社交网络之于 ActivityPub，就像比特币之于区块链。
事实上，我帮助与 NodeBB、Flarum 等公司一起成立一个新的 W3C ActivityPub for Forums 工作组的原因之一，就是试图将 ActivityPub 集成的焦点从现有实现（例如 Mastodon）转移到论坛的关注点，例如你提出的关于审核的关注点。我们实际上今天有会议。如果你有时间，我很想有一位“Discourser”（这是一个词吗？）在那里
4 个赞
我指的是使用 Discourse 的审核工具来审核 出现在 WordPress 上的评论。从技术上讲，这可以通过 Discourse API 请求或 Webhook 来完成——在 Discourse 上执行审核操作后，可以发出请求来更改 WordPress 上评论的状态。
假设已更改设置，使 ActivityPub 帖子由审核队列处理，那么评论最初在 WordPress 上发布与在 Discourse 上出现之间仍然存在时间延迟问题。我认为这需要几分钟？
对于这种情况，主要卖点之一是“使用 Discourse 审核您网站的评论”。它接着列出了 Discourse 的审核功能、信任级别系统、审核队列、AI 驱动的审核工具等。这些工具对于小型博客来说是很好的补充，但对于主流新闻网站来说是必需的。我认为最好的实现方式是使用 Discourse 作为评论的唯一真相来源，而不是让评论存在于两个（或更多）数据库中。
那太好了！由于没有时间仔细思考，我认为我无法很好地代表 Discourse。
我对将主题、帖子和用户视为数据的想法有一些普遍的担忧。需要有一种方法来确保不丢失讨论发生的上下文。
从更实际的角度来看，ActivityPub 协议在各国引入在线危害法案之前就已经流行起来了。需要有一些保证，即消耗来自源服务器数据的服务器将尊重删除请求。否则，在源服务器上生成内容的用户的风险在于，如果其内容后来被认为在其国家/地区有害，可能会面临法律追索。
3 个赞