### Author:  [@bmann](https://meta.discourse.org/u/bmann)
#### Post date: [2023年八月16日 15:56 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/66 "2023-08-16T15:56:30Z")
太棒了！
我最近为我们的 CoSocial Co-op 设置了一个 Discourse 服务器，该服务器运行一个 Mastodon 服务器。我最终设置了 OAuth2 插件，因此我们只接受来自我们的 Mastodon 服务器的登录 → [https://members.cosocial.ca](https://members.cosocial.ca)（一个全新的、非常简单的安装，只是“OAuth 证明”）。
我的问题/功能请求是能够将 Mastodon 参与者分阶段/合并到 Discourse 帐户中，这样当 Mastodon 上的帐户回复时，它们就可以链接到关联的 Discourse 帐户/由其拥有。
> **Lemmy 不这样做**
>
> 我记录了 Lemmy \_不\_这样做的方式——你可以通过 Mastodon 进行交互，并在 Lemmy 中为该 Mastodon 帐户创建一个帐户，但你实际上无法使用你的 Mastodon 帐户登录并使用 Lemmy 的一流功能。
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [2023年八月16日 16:12 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/67 "2023-08-16T16:12:24Z")
> [@bmann](#):
>
> 我的问题/功能请求是能够将 Mastodon 参与者暂存/合并到 Discourse 帐户中，这样当 Mastodon 上的帐户回复时，它们就可以与关联的 Discourse 帐户链接/归属。
这已提上日程……
> [@angus](#):
>
> 支持 Discourse 用户在 Mastodon 上验证他们的身份，以便从他们的 Toots 创建的 Discourse 帖子与他们的 Discourse 用户帐户相关联。
并且已在队列中等待审核
>
>
> @pmusaraj This one is ready now too. Just a note on the storage of OAuth Apps. I… decided to use the Plugin Store there because
>
> \- It's a relatively straightforward use case.
> \- I can forsee a significant variability in the authentication details we need to save if we add other authorization methods in the future, a bit like in the Auth system in Discourse itself.
>
> Other than that, I'll let the code speak for itself.
---
### Author:  [@bmann](https://meta.discourse.org/u/bmann)
#### Post date: [2023年八月16日 18:45 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/68 "2023-08-16T18:45:01Z")
太好了。听起来我的 Discourse OAuth 插件用户需要“再次确认”才能与此 AP 插件进行互操作。
我认为现阶段这完全没问题，只是想从另一个角度提及 OAuth 服务器，只要它不冲突即可。“锦上添花”的功能将是“如果使用 Mastodon 服务器进行 OAuth，则自动链接 AP actor 身份”。这完全是未来的设想，而且对于这种设置来说也是独一无二的！
（抱歉没有弹出页面查看那部分！太棒了！）
---
### Author:  [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [2023年八月17日 17:50 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/69 "2023-08-17T17:50:42Z")
> [@angus](#):
>
> 支持接受回复远程笔记的活动，以及发布回复 Discourse 笔记的活动。
添加此功能集的 PR 现已合并。
正如 Angus 在上面指出的，接下来是 OAuth 令牌的用户验证。
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2023年八月17日 23:39 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/70 "2023-08-17T23:39:57Z")
我之前看到的原始 Markdown 文本显示出来的问题似乎也影响到了 meta。我正在关注 `@feature@meta.discourse.org`，几小时前，这个帖子被创建并从该 Actor 联合过来：
> [@Improve usage consistency of chevron icons](https://meta.discourse.org/t/improve-usage-consistency-of-chevron-icons/275544?u=mcdanlj):
>
> The usability of Discourse could be improved by optimizing the consistency of icons. Situation now Sorting For sorting Discourse uses the icon chevron-down and up Topic Summary To open the topics summary users have to use the button with the chevron down. To close it they use the chevron up. Sidebar sections In the sidebar there are buttons with chevron right and do…
在 Mastodon 上，它显示为这样，存在故障：
在 Elk 中，它看起来是这样的，稍微好一点：
我现在刚刚在我的纯 Mastodon 账户上关注了 `@feature@meta.discourse.org` 来测试这个问题，但当然现在已经太晚了，无法在那里看到这个特定的帖子了。😭
所以，我之前从我自己的安装中看到的嵌入式 Markdown 不是数据库有问题，或者即使是，那也是 meta 共享的数据库问题，因此可能与我的测试无关。
---
### Author:  [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [2023年八月18日 02:36 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/71 "2023-08-18T02:36:03Z")
是的，我能复现这个问题，我在一个Mastodon实例和Ivory（iOS应用）中看到了类似的输出。
---
### Author:  [@hello-smile6](https://meta.discourse.org/u/hello-smile6)
#### Post date: [2023年八月20日 02:42 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/72 "2023-08-20T02:42:06Z")
我不确定这是否正常工作。插件已启用，我在启用了 ActivityPub 的类别中创建了一个主题，但我没有在帖子旁边看到徽章（并且我尝试关注该类别的 activitypub actor 似乎失败了，因为它表现得像一个需要用户手动批准的服务器）。
---
### Author:  [@hello-smile6](https://meta.discourse.org/u/hello-smile6)
#### Post date: [2023年八月20日 02:53 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/73 "2023-08-20T02:53:39Z")
> [@hello-smile6](#):
>
> 我尝试关注该分类的 ActivityPub 活动对象，但似乎失败了，因为它表现得像服务器需要用户手动批准关注请求一样。
我刚刚注意到，Meta 上的 #Contribute > Feature 似乎也出现了同样的问题。
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2023年八月20日 21:38 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/74 "2023-08-20T21:38:45Z")
了解限制的_最终目标_将非常有用，而无需担心中间状态。
例如，我认为我在 PR 中看到过一个参考，如果启用了该插件，更改帖子的所有者将被阻止。作为管理员，我必须偶尔使用该功能（例如，在更改类别版主时，我会让新的主要类别版主成为有关置顶帖子的类别的所有者）。我希望最终，这会显示为删除和重新发布，甚至只是被忽略，而不是阻止所有权更改。
我也想知道在类别之间移动帖子。我必须相当频繁地执行此操作，尤其是在新用户发布到错误类别时。我天真地认为，这将导致一个类别参与者取消其提升，而新的类别参与者添加提升，但不会删除底层帖子，这样，如果其他人看到了并提升了帖子，他们的提升就不会因为类别参与者的提升消失而消失。
总的来说，在完成目前指定的特性开发后，无论目前有哪些限制，都非常希望了解启用此插件后，哪些操作将被禁止。
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2023年八月20日 22:11 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/75 "2023-08-20T22:11:23Z")
@hello-smile6 我在今天更新的插件中看到了同样的问题：
我没有看到相关的配置，所以我想这应该是一个 bug。
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [2023年八月21日 13:00 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/76 "2023-08-21T13:00:09Z")
> [@mcdanlj](#):
>
> 我之前看到的原始 markdown 文本显示出来的问题似乎也影响到了 meta。
感谢您进一步的报告。我正在调查此事。
> [@hello-smile6](#):
>
> 我尝试关注该分类的 activitypub actor 似乎失败了
感谢您的报告，我们正在调查此事。
> [@mcdanlj](#):
>
> 很高兴能理解限制的_最终目标_，而不必担心中间状态。
我理解您的想法，但是：
- 插件目前正在积极开发中，试图以这种方式解释事情将是徒劳的，因为解释可能会发生变化。
- 该插件已经处理了相当多的不同场景和边缘情况，如果我现在以叙述的方式解释每一个场景，将花费太长时间（即，多次完成这个长帖）。该插件已经有 400 多个不同的 [specs](https://github.com/discourse/discourse-activity-pub/tree/bbbb941c13e78a4a79b9c665b857f53efc88bc90/spec)。
- 尽管如此，限制通常在 PR 和 commit 的评论中以叙述的方式进行解释，我认为您已经阅读了。
> [@mcdanlj](#):
>
> 我认为我在一个 PR 中看到过一个参考，如果启用了该插件，更改帖子的所有者将被阻止。作为管理员，我偶尔需要使用该功能（例如，在更改分类版主时，我会将新的主要分类版主设为关于置顶帖子的分类的所有者）。我希望最终，这会显示为删除和重新发布，甚至只是被忽略，而不是阻止所有权更改。
这在 PR 中进行了深入讨论：
>
>
> @pmusaraj This is the big one. I won't attempt to cover everything in this descr…iption, but here's some things worth noting:
>
> \- Post Activities are federated as "Announcements" of the Category actor. This means that the federated Notes of the posts will show up in the feeds of the followers of that Category. The author (Actor) of the Note will be the user in Discourse who created the post. This pattern is the same pattern used by other threaded platforms in the fediverse (e.g. Lemmy; see \[further\](https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md#the-announce-activity)) and it works with Mastodon.
> \- Posts in new topics in a "full topic" category are initially published as a "Collection". Note that Mastodon processes Collections. This allows for a few things, particularly:
> - For all replies to the first post prior to initial publication to be published at the same time. This solves the timing issue of initial publication.
> - For any topic metadata to be sent along with the Collection (e.g. Collection summary = Topic title)
> \- I've collected the AP post indicators into a modal that shows when you click the AP logo on the post. Remote posts are indicated with a different colour and have a link to the original in the modal.
> \- In addition for tests of the new functionality I've also added more tests for:
> - Post destruction and recovery
> - Post movement between topics
> \- I've restricted changing post owners and making post wikis, even for admins, in AP topics. This is because remote AP posts have to retain fidelity with the original and both actions may potentially break that fidelity.
> \- I've still allowed for a remote AP note's post to be deleted and edited by staff. This does not federate Delete or Update activities, however it update or remove the local representation of the Note (i.e. the post).
> 我限制了在 AP 主题中更改帖子所有者和创建帖子 wiki，即使是对管理员也是如此。这是因为远程 AP 帖子必须保留原始帖子的保真度，而这两种操作都可能破坏这种保真度。
>
> 可能有一种方法可以让联合与 wiki 和更改帖子所有者一起工作，但是我建议我们在未来的 PR 中将其添加为一项“功能”，因为它将涉及乘以或更改跨多个平台联合出去的对象的 actor。我认为我们永远无法允许更改导入的 ap 帖子的所有者（笔记），因为 actor/object 关联不由 Discourse 拥有，而是由内容创作的地方拥有。为了说明一个类比，在这种情况下，与导入的笔记关联的帖子的删除与其说是一种“删除”，不如说是一种选择_不显示_笔记的选择。
> [@mcdanlj](#):
>
> 我也想知道在分类之间移动帖子。我需要相当频繁地这样做，特别是当新用户在错误的分类中发帖时。我天真地认为，这将导致一个分类 actor 移除其 boost，而新的分类 actor 添加一个 boost，但不会删除底层帖子，这样如果其他人看到了并 boost 了某个帖子，他们的 boost 就不会因为分类 actor boost 的消失而消失。
涉及移动帖子的场景有很多。我现在将处理您提到的特定场景，即在两个不同的 ActivityPub 启用的分类之间移动帖子。
> [@mcdanlj](#):
>
> 一个分类 actor 移除其 boost
您假设帖子在分类之间移动的唯一时间是帖子最初发布在错误的分类中，并且在帖子发布后不久就进行了移动。如果，在帖子发布 4 个月后，您将其移动到另一个分类，因为您想将某个帖子集合合并到一个不同分类的新主题中呢？在这种情况下，发送“撤销”以取消原始 boost 是否有意义？
> [@mcdanlj](#):
>
> 新的分类 actor 添加一个 boost
这取决于我们讨论的是第一个帖子配置还是完整主题配置。对于前者，我们将为第一个帖子添加一个按钮，以便手动发布以专门处理分类移动场景。对于后者，自动添加 boost 可能是有意义的，我将进一步考虑。
> [@mcdanlj](#):
>
> 总的来说，了解当此插件添加后，在当前指定的特性开发完成后，将不允许什么，无论当前存在什么限制，都将非常有帮助。
我理解您的想法，但是我已经分享了关于第二阶段规范中最终状态的相当多的细节。除了该规范之外，并且尽可能温和地说，有太多的用例和场景需要我与您以及 [Discourse.org](http://Discourse.org) 团队深入讨论，同时还要处理它们 🙂
我将在第二阶段完成后，在 OP 中更新预期的行为的总体概述。
---
### Author:  [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [2023年八月21日 15:57 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/77 "2023-08-21T15:57:37Z")
> [@hello-smile6](#):
>
> 我刚注意到 #Feature 在 Meta 上似乎也出现了同样的问题。
我无法重现此问题。我刚刚从一个测试的 Mastodon 帐户关注了 `feature@meta.discourse.org`，在 Mastodon 或 Discourse 中均未看到错误。
---
### Author:  [@hello-smile6](https://meta.discourse.org/u/hello-smile6)
#### Post date: [2023年八月21日 20:00 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/78 "2023-08-21T20:00:48Z")
这可能与我关注的实例有关，这个实例有什么不寻常之处吗？
> **[tilde.zone](https://tilde.zone/)**
>
> mastodon instance of the tildeverse, a collection of small public access \*nix systems for collaboration, creativity, and socializing. a proud part of the small internet.
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2023年八月21日 21:33 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/79 "2023-08-21T21:33:46Z")
哎呀，在我试图提出一个清晰的问题时，我听起来好像在要求大量工作。我很抱歉沟通不当。我很感谢你深思熟虑的回复。
> [@angus](#):
>
> 我将在第二阶段完成后，在帖子首楼更新一个关于预期行为的总体概述。
这正是我想要问的，而不是在这个帖子里持续的详细更新。我原意是想说“在当前指定的特性开发完成后”来阐明何时会有帮助，而不是要求你现在就描述未来的状态。我的问题措辞含糊不清。抱歉！
> [@angus](#):
>
> 远程 AP 帖子必须保留与原始帖子的保真度，并且这两种操作都可能破坏这种保真度。
这正是我_真正_想理解的： **大致来说** ，最终目标是将 Discourse 限制在仅支持标准 ActivityPub 的功能，还是在尽最大努力的基础上，将不受限制的原生 Discourse 体验联合到 fediverse？我过去与 Discourse 集成的经验让我期望尽最大努力；现在我明白你们的计划是追求保真度，以牺牲 Discourse 功能为代价，而这不仅仅是开发过程中的临时措施。
> [@angus](#):
>
> 你假设帖子在类别之间移动的唯一时间是帖子最初发布在错误的类别中，并且移动发生在帖子发布后不久。如果，在帖子发布 4 个月后，你将该帖子移至另一个类别，因为你想将某个帖子集合整合到一个不同类别的新主题中？在这种情况下，发送对原始 boost 的“撤销”是否有意义？
我并没有这样假设。为什么四个月会有区别呢？它现在被归入了一个联合类别，为什么这不会导致联合类别对其进行 boost？至少我天真地会期望发生这种情况。我经常看到人们 boost 几个月前的帖子，所以我不知道有什么特别的原因会导致这种情况不同。
是的，我认为发送对原始 boost 的“撤销”是有意义的。这似乎很常见。（事实上，撤销 boost 然后再进行新的 boost 似乎是“置顶”内容的常见机制；这与此目的无关，但说明了撤销 boost 的常用性，因此不应给其他 ActivityPub 实现带来问题。）
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2023年八月21日 21:34 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/80 "2023-08-21T21:34:43Z")
> [@hello-smile6](#):
>
> 这可能与我关注的实例有关，这个实例有什么不寻常之处吗？
我现在看到 `feature@meta.discourse.org` 来自 mastodon.cloud 也是同样的情况，我认为它运行的是纯粹的 Mastodon。
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [2023年八月22日 07:14 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/81 "2023-08-22T07:14:33Z")
> [@mcdanlj](#):
>
> 总的来说，目标是将 Discourse 限制在仅支持标准 ActivityPub 的范围内，还是在尽力而为的基础上，从不受限制的原生 Discourse 体验联合到 fediverse？我过去与 Discourse 集成的经验让我期望尽力而为；现在我明白你们的计划是追求保真度，以牺牲 Discourse 功能为代价，而且这不仅仅是开发过程中的临时措施。
就我个人而言，我两种想法都没有。[Discourse.org](http://Discourse.org) 将在此设定整体议程，但总的来说，决策是基于它的工作方式和实际情况。如果有一种合理且可持续的方式来允许更改所有帖子的作者身份，无论其来源如何，那就太好了。
> [@mcdanlj](#):
>
> 我没有假设。四个月为什么会有区别？它刚刚进入联合类别，为什么不会导致联合类别对其进行推广？至少，我天真地认为应该会发生这种情况。我经常看到人们推广几个月前的帖子，所以我不知道有什么特别的原因会导致这种情况不同。
>
> 是的，我认为撤销原始推广是有意义的。这似乎很常见。（事实上，撤销推广然后进行新的推广似乎是“提升”内容的典型机制；这与此目的无关，但说明了撤销推广是常用的，因此不应给其他 ActivityPub 实现带来问题。）
仅仅关注撤销原始推广，这种特定的撤销似乎没有意义？在某些情况下，它也可能有点令人惊讶，正如我的例子试图表明的那样。更改类别可能并不意味着要撤销（Undo）内容的原始“可发现性”。它可能是为了另一个原因而在以后更改内容的组织方式。
换句话说，在 Discourse 中对类别更改自动应用原始 Announce 的撤销在某些情况下有效，但在其他情况下则无效。即使在似乎更有意义的情况下，原始 Announce 也并没有真正造成任何危害。因此，遵循最小伤害和最小意外原则，似乎保留原始 Announce 更为合理。如果我遗漏了什么，我很抱歉。
从另一个角度来看，我认为将类别 Actor 的 Announce 活动等同于类别本身的分类角色是不正确的。Announce 是类别 Actor 与其关注者分享内容的方式，但它本身并不是一种分类。它是内容在 Fediverse 中被发现的一种方式。我认为类别和类别 Actor 的 Announce 活动之间不需要一对一的关系。
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2023年八月22日 11:20 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/82 "2023-08-22T11:20:51Z")
> [@angus](#):
>
> 我个人也不这么想。 [Discourse.org](http://Discourse.org) 将在此设定整体议程。
啊。那这确实是团队的问题了。😁
> [@angus](#):
>
> 因此，遵循最小伤害和最小意外的原则，似乎直接保留原始公告更有意义。
这也有道理。我同意，撤销这次提升的价值不大。
那么它就是一个边缘触发信号；它意味着“一篇文章刚刚进入此类别，无论是通过撰写还是移动到此类别”。这在概念上很简单。
然后我会以同样的方式考虑更改文章的作者身份。这将是新的参与者为新作者的文章创建一项新活动，并且没有特别的理由去处理在旧作者名下进行的旧活动，因为旧作者不会撰写任何编辑，也不应被归功于这些新更改。他们实际上并没有在 Discourse 上删除他们的文章，因此删除原始作者的活动不一定能反映某些基本事实。但是，旧作者的参与者之前发布的内容将是他们写的内容，没有理由删除这些文章。而且，如果有人点击链接回到 Discourse，他们将看到当前的内容和作者身份，并且（在有足够权限的情况下）可以看到编辑历史记录。
同样的逻辑也适用于维基。它们在 Discourse 下显示为单一作者身份，但允许其他人撰写。其他作者的更新并不被广泛归因（除非您有足够的权限阅读历史记录）。在 Discourse 的 Web 视图中，归因是否由头像显示，或者与活动关联的 ActivityPub 参与者显示，实际上并没有特别的意义；最终结果是通过一个或另一个渲染管道向另一端的读者呈现归因。
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [2023年八月22日 11:40 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/83 "2023-08-22T11:40:43Z")
> [@mcdanlj](#):
>
> 那么，我也会认为更改帖子的作者与此类似。新参与者将为新作者的帖子创建新活动，而旧作者的旧活动无需做任何处理，因为旧作者不会再进行编辑，也不应因这些新更改而获得功劳。他们实际上并未在 Discourse 中删除帖子，因此删除原始作者的活动并不一定反映了某种基本事实。但旧作者的参与者之前发布的内容将是他们写的内容，没有理由删除这些帖子。如果有人通过链接回到 Discourse，他们将看到当前的内容和作者信息，并（在有足够权限的情况下）查看编辑历史记录。
嗯，我不确定我是否同意。这样做的最终结果将在 Fediverse 中出现两个由不同参与者撰写的相同笔记，它们都将在多个平台上可见。对于第一次接触该内容的新用户来说，他们会看到由不同人撰写的相同内容。反之，当你在 Discourse 中更改作者时，你实际上是在重写历史，对于第一次接触该内容的新用户来说，你只看到新作者。你认为这之间有区别吗？
> [@mcdanlj](#):
>
> 同样的逻辑也适用于维基。它们在 Discourse 中显示为单一作者，但允许其他人撰写。其他作者的更新不会被广泛归因（除非你有足够的权限读取历史记录）。无论是在 Discourse 的 Web 视图中显示头像还是与活动关联的 ActivityPub 参与者，这种归因是否显示实际上并没有太大意义；最终结果是通过一个或另一个渲染管道将归因呈现给另一端的读者。
我不确定我是否完全理解。你的意思是，维基帖子的所有编辑，无论由谁进行，都应被视为标准更新活动，并归因于原始参与者（即发布者）吗？
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [2023年八月22日 11:51 UTC](https://meta.discourse.org/t/activitypub-plugin/266794/84 "2023-08-22T11:51:25Z")
> [@mcdanlj](#):
>
> 我之前看到的原始 Markdown 出现的问题似乎也影响到了 meta。
请注意，这是此 PR 的主题，并附有说明性注释。
>
>
> @pmusaraj This is to address the markdown / html issue reported on meta. A few n…otes on what I'm doing here:
>
> 1. I decided to bite the bullet and create an entirely separate parser (separate from the excerpt parser) to make it clear exactly what's supported and what's going on. This was going to happen at some point, and better sooner than later to help to clarify what's going on.
>
> 2. The immediate issue we are dealing with format-wise arose due to an incorrect handling of header markup (I hadn't included the right markdown rule to convert it to header tags). That issue, specifically as it was arising in posts coming from meta has been addressed.
>
> 3. Folks are already using Notes for long content that may involve a lot of markup. The best solution for long content is actually to federate an Article instead of a Note, as that just takes all the cooked HTML of a post. However Mastodon does not support showing the \`content\` of Articles (yet; it just shows a link currently).
>
> 4. When federating a Note, I think we should start from a relatively conservative base of supported markup and increment from there as appropriate. A Note is really meant to be short, simple, content, so I think this makes sense. Currently that's just \`a\` and \`h\*\` elements.
>
> Note that Mastodon converts \`h\*\` tags to \`strong\`.
[上一頁](https://meta.discourse.org/t/activitypub-plugin/266794.md?page=3)
[下一頁](https://meta.discourse.org/t/activitypub-plugin/266794.md?page=5)