是的，这是经过设计的微妙区别。这里的假设是，大多数阅读此主题/帖子的用户不一定需要立即知道“此帖子来自社区外的用户”。作为管理员或实现该功能的人员，了解这一点很有趣，但大多数人希望专注于内容。因此，我们选择对帖子的 ActivityPub 技术细节保持相对沉默。
2 个赞
那么我的用户是不同的。他们肯定想知道。但这一定是文化差异的一个例子，以及我们芬兰人如何接近反社会行为（根据美国内容创作者的说法，因为我们完全无法进行美国规模的闲聊 
）。
但使用 CSS 进行调整相对容易，所以默认值是可以的（并且如果有人想知道同样的事情，这里就有一个解决方案）。
2 个赞
我从 Mastodon 回复了 Discourse 的帖子，但回复没有出现在 Discourse 中。这是个 bug，还是尚未实现此功能，或者不打算实现此功能？
这是bug还是其他什么。我刚进行了一次讨论，话题发布到了Mastodon，收到了那里的评论，我也回复了话题，那里的内容也可见。
标准问题：您是否使用了最新版本？
1 个赞
是的，我刚刚安装了该插件，尽管我不得不使用这个分支（PR 待处理）才能使其正常工作：GitHub - kuba-orlik/discourse-activity-pub: Adds ActivityPub support to Discourse.
2 个赞
你好，你能帮我解答一些与管理相关的问题吗，我一直找不到答案：
- 一旦帖子被联邦化，是否可以由本地管理员进行管理？也就是说，可以编辑、隐藏、删除吗？
- 如果在原始实例中编辑了帖子，联邦实例中会更新吗？
- 如果管理员想通过标记选项或消息/聊天联系联邦用户，他们可以吗？这些远程发帖者在本地实例中是不是实际上不是用户？
- 如果我在两个联邦实例中有相同用户名和电子邮件地址的账户，它们在每个实例中仍然会被视为两个不同的账户，对吧？没有办法“合并”它们。
- 是的
- 是的（或者应该）
- 不，但是你可以删除有问题的演员（在 Mastodon 中其他用户可以举报，但发生什么取决于管理员）
- Discourse 通过 ActivityPub 从不查看电子邮件。相反，可能有几个
icaria@...，其中“域部分”、实例名称会变化，这些账户仍然由同一个人拥有。你不能合并这些账户，因为那样你实际上会禁止服务器获取主题/帖子。
1 个赞
好的，我们在实例中启用了插件，创建了一个连接到标签的 actor，并联合了我们的第一个帖子到 Fediverse。非常令人兴奋！也很棒。
有一些问题（可能是一些缺失功能的建议，但我仍在尝试了解有哪些功能）：
作为一名看到联合帖子的 Discourse 用户，是否有办法获取到 Mastodon 上对应 toot（消息）的链接，以便在那里轻松地进行 boost？我在添加到主题的小日志中找不到它：
作为一名看到来自 Discourse 的 toot 的 Mastodon 用户，是否有简单的方法可以找到 actor 的 Mastodon 帐户以便关注？他们可以看到发帖人的帐户，但看不到 actor 的。如果他们关注到论坛的链接，我找不到任何方法可以推断出如何找到 actor。
为什么插件会 boost 所有回复，而不是让它们仅仅是回复，典型的“安静的公开”回复？这些 boost 会给那些在 Mastodon 上关注 actor 的人带来很多额外的噪音。
当一名 Mastodon 用户开始一个新帖子（不是回复）并提及 actor 的帐户或 Discourse 用户的帐户时，应该发生什么？
最后，这看起来不正常，而且我们收到了很多这样的信息（几个小时内就有一百多条）：
Job exception: stack level too deep
activesupport-7.2.2.1/lib/active_support/core_ext/object/blank.rb:166:in `present?'
/var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/json_ld.rb:57:in `base_object_id'
/var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/json_ld.rb:58:in `base_object_id'
(snip, dozens of these)
/var/www/discourse/plugins/discourse-activity-pub/lib/discourse_activity_pub/json_ld.rb:58:in `base_object_id'
/var/www/discourse/plugins/discourse-activity-pub/app/jobs/discourse_activity_pub_process.rb:25:in `process_id'
/var/www/discourse/plugins/discourse-activity-pub/app/jobs/discourse_activity_pub_process.rb:8:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
sidekiq-7.3.9/lib/sidekiq/processor.rb:220:in `execute_job'
sidekiq-7.3.9/lib/sidekiq/processor.rb:185:in `block (4 levels) in process'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:180:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
sidekiq-7.3.9/lib/sidekiq/job/interrupt_handler.rb:9:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:26:in `track'
sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:134:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:173:in `invoke'
sidekiq-7.3.9/lib/sidekiq/processor.rb:184:in `block (3 levels) in process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:145:in `block (6 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_retry.rb:118:in `local'
sidekiq-7.3.9/lib/sidekiq/processor.rb:144:in `block (5 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/config.rb:39:in `block in <class:Config>'
sidekiq-7.3.9/lib/sidekiq/processor.rb:139:in `block (4 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/processor.rb:281:in `stats'
sidekiq-7.3.9/lib/sidekiq/processor.rb:134:in `block (3 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_logger.rb:15:in `call'
sidekiq-7.3.9/lib/sidekiq/processor.rb:133:in `block (2 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_retry.rb:85:in `global'
sidekiq-7.3.9/lib/sidekiq/processor.rb:132:in `block in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_logger.rb:40:in `prepare'
sidekiq-7.3.9/lib/sidekiq/processor.rb:131:in `dispatch'
sidekiq-7.3.9/lib/sidekiq/processor.rb:183:in `block (2 levels) in process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `handle_interrupt'
sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `block in process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `handle_interrupt'
sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:86:in `process_one'
sidekiq-7.3.9/lib/sidekiq/processor.rb:76:in `run'
sidekiq-7.3.9/lib/sidekiq/component.rb:10:in `watchdog'
sidekiq-7.3.9/lib/sidekiq/component.rb:19:in `block in safe_thread'
如果你点击截图中的“Note”标签，你将获得一个指向 Discourse 上 Note 对象的链接，但我不确定这是否是你想要的。你能更详细地解释一下你期望发生什么吗？也许分享一个你希望实现的用户故事。
你是指 Discourse 用户吗？目前你无法关注 Discourse 用户。
你能详细说明一下你期望发生什么吗？也许用一个用户故事。
这将在合并后得到解决。
1 个赞
这是新问题吗？还是和之前“Job exception: stack level too deep”的问题基本一样？
1 个赞
确实如此！我错过了之前的报告。PR 很快就会出来。
1 个赞
It happens, too much on a plate
谢谢。
1 个赞
当然！
作为一个既有 Discourse 账户又有 Mastodon 账户的 Discourse 用户，我在 Discourse 上看到一个联合话题，我想从我的 Mastodon 账户快速转发（分享）它，这样我所有的 Mastodon 关注者都能知道它，并可能从他们的 Mastodon 账户进行回复，为 Discourse 上的话题带来大量的联合反馈（也许其中一些不知道论坛的人会因此加入 Discourse！）。
好的，要做到这一点，用户需要轻松找到一个 URL，他们可以将其粘贴到 Mastodon 客户端的搜索框中，该 URL 将提供与 Discourse 帖子对应的联合推文（消息）。
我在 Discourse 界面中找不到这个 URL。到目前为止，我发现从 Discourse 转发联合帖子的唯一简单方法是已经关注了 Discourse 参与者，并且该帖子出现在我的 Mastodon 时间线上。这对于已经关注该参与者的用户来说是可以的，但对于那些尚未关注该参与者的 Discourse 用户来说则不行。
希望我能解释清楚问题，而不是让事情更混乱。
我将在更好地理解当前行为后，再发布关于持续转发的用户故事。
1 个赞
如果我没理解错的话，你那样几乎找不到任何 Mastodon 的内容。
对我来说，这类问题在于对话本身。因为所有内容都是转推，我必须找到第一条帖子才能了解整个话题，因为转推的评论从不会向关注者显示。所以对话就会消失。
而且，如果我转推 Discourse 的评论，它会显示为“用户-actor”，而这个用户是无法被关注的。
这些，以及（标签）的明显缺乏，是目前主要的疑问——至少对我来说是这样。
1 个赞
好的，我找到了我想要的链接……在回复中，但不在顶部的帖子中：
在回复中，它是右上角的联合图标，在截图的“22h”旁边。
如果你点击它，你会得到这个对话框：
这确实指向了 Mastodon 上的回复：icaria36 🎶: "@icaria36@the.socialmusic.network This is a test …" - SoNoMu
我缺少顶部帖子的等效图标和链接。它可能就在某个显眼的地方，但我找不到。
编辑：
啊，等等，那个链接只出现在来自 Mastodon 的帖子中，而不是 Discourse 原生帖子。我刚意识到那个小图标有一个蓝色和一个绿色版本来区分这一点。蓝绿色不是区分如此小图标的好颜色组合。我的桌面显示器相当不错，我也没有色盲，但直到现在仔细查看这些图标时才注意到区别。
对我来说，一个大问题是……
作为一个回复联合域中 Discourse 帖子的 Mastodon 用户，如果有人回复我的帖子或在 Discourse 中提及我，我希望收到 Mastodon 通知。
现在，Discourse 用户回复 Mastodon 用户帖子时，Mastodon 用户很可能错过这些回复，因为即使他们被回复或被提及，他们也不会收到通知。这使得在 Mastodon 上进行实际对话比已经存在的更加困难——因为你甚至不知道有人回复了你的评论。同样，除非我遗漏了什么。
但是，请将这一切仅仅视为改进的反馈。这个插件已经令人印象深刻，我们正在继续使用它，并且我们很乐意帮助报告问题和测试新功能。非常感谢 @angus 和他的团队！
1 个赞
如果发布到 ActivityPub 类别或标签（具有相关设置），发布和投递都会自动进行。两者之间的区别以及这些管理员控件是为了灵活性和特定用例。
发布 = 该帖子可在联邦宇宙上找到。
投递 = 该帖子已投递给相关参与者的关注者。
该操作允许您随时投递相同的帖子，包括在帖子已经投递之后。这有各种用例，例如：
-
您最初发布了一个主题，但没有将主题中的所有帖子投递给您的关注者（因为您不想垃圾邮件）。然后，您可以单独投递帖子。
-
该帖子在新的关注者关注您的参与者之前发布。您可以再次投递相同的帖子。
如果您点击该主题的“主题信息”，如果帖子已在 Mastodon 上进行联合，您应该会看到该帖子已被投递。
2 个赞
好的，现在我们有了一个来自真实用户的真实用户故事，它非常清楚地解释了问题。
如果我们想分享一个特定的联合帖子到 Fedi，有人知道我们该怎么做吗？我试了：
- 查看 @fediverse@the.socialmusic.network 的个人资料 - 没有可见的帖子
- 查看我自己的 socialmusic 个人资料 - 没有可见的帖子
- 在 Discourse 论坛上寻找一个“分享”按钮：Masto 搜索不识别该 URL
2 个赞
那是我！感谢这个激动人心的插件，我们正在享受在论坛上捣鼓 Federation。\n\n我有几个问题，如果之前有人问过，请原谅（我在论坛上搜索过，但没看到任何内容）。\n\n- 在 Mastodon/etc. 端，私有、仅限关注者、未列出帖子的处理方式是怎样的？\n- 对于注重隐私的用户，比如运行 Gotosocial 的用户，他们的联合回复是如何处理的？\n\n我特别考虑的是同意问题：如果有人不愿意他们的帖子在公共论坛上被搜索到。他们可能不知道他们正在回复的主题在 Discourse 上是公开可见的。Discourse 用户的帖子标记得很清楚，但如果我在同一个帖子里回复一个 AP 用户，我可能会忽略它最初是一个 Discourse 主题。
3 个赞