作者在博客中探讨了评论系统的问题，认为现有的解决方案如Disqus、自托管系统和GitHub Issues都存在各种缺陷，如速度慢、用户追踪、管理复杂等。作者最终选择使用Bluesky作为评论系统，认为其社区健康且API设计良好，能够提供更好的用户体验。

博客评论系统的问题

多年来，我的博客一直没有合适的评论系统。这并不是我主动选择的，而是因为我找不到一个不让人头疼的解决方案。

• Disqus：加载缓慢、占用资源多、追踪用户，而且我无法掌控任何内容。此外，它还会让每个页面的加载速度变得极其缓慢。
• 自托管解决方案：理论上不错，但实际上需要管理用户、处理垃圾信息、维护数据库，基本上等于在运营一个小型社交平台。如果用户不在你附近，加载速度也会非常慢。
• GitHub Issues 作为评论系统：可能适合一些开发者博客，但感觉像是临时解决方案，并且限制了只有 GitHub 用户才能参与。
• 完全不加评论：简洁明了，但会失去与读者的互动。我的一些最有趣的发现正是来自那些出乎意料的评论讨论。

我使用 Bluesky 已经有一段时间了。最近，这个社区的氛围比 Twitter 更加健康，API 设计良好，且这种去中心化的方式意味着我不必依赖单一公司。人们已经在 Bluesky 上做了一些有趣的事情，比如在协议上发布博客内容，并使用 Bluesky 的评论作为博客的评论系统。为什么不自己试试呢？

为什么 Bluesky 是一个合理的选择

越想越觉得，直接使用 Bluesky 作为评论系统非常合理：

• 无需维护基础设施：我不需要管理数据库、用户账户或构建审核工具，Bluesky 已经处理了这些。
• 更丰富的内容支持：用户可以发布图片、链接和线程，这些都能让讨论更加有趣。
• 真实身份：由于用户使用的是他们的 Bluesky 个人资料，且一个个人资料可以在任何支持的平台上使用，这增加了责任感，减少了恶意评论的可能性。
• 跨平台讨论：评论也存在于 Bluesky 上，因此人们可以通过社交媒体发现我的博客文章，反之亦然。
• 内容所有权：我拥有我的内容，用户也拥有他们的内容，没有任何平台锁定。

工作流程很简单：我发布一篇博客文章，分享到 Bluesky，编辑文章以添加 AT URI，然后对该 Bluesky 帖子的回复就会成为我博客的评论。

构建组件

理解 AT 协议

Bluesky 运行在 AT 协议上，其文档出人意料地不错。我需要了解的关键概念包括：

• DIDs（去中心化标识符）：唯一的用户 ID，如 did:plc:abc123... 或 did:web:joe.coffee。
• CIDs（内容标识符）：唯一的帖子 ID。
• AT URIs：内容的地址，如 at://did:plc:user.../app.bsky.feed.post/postid。

要获取评论，我只需要调用 getPostThread 端点并传入正确的 URI，无需认证，非常简单。

组件架构

最终，我构建了三个主要部分：

1. 主评论组件：负责获取并显示评论线程。
2. 回复组件：处理单个帖子及其回复的渲染，包括元数据和指向原始 Bluesky 帖子的链接。
3. 嵌入组件：用于处理图片和开放图谱预览等丰富内容。

这种分离使得每个部分都易于管理。

处理嵌套回复

有趣的部分是处理嵌套回复。Bluesky 的线程可以无限嵌套，但我需要以一种可读且不破坏布局的方式显示它们。我采用了一种简单的递归方法，每个回复都可以渲染子回复，并通过视觉缩进来显示层级关系。我将深度限制在 5 层，因为超过这个深度，讨论通常会变成两个人的争吵。

处理丰富内容

Bluesky 的一个优点是帖子可以包含不仅仅是文本。用户可以嵌入图片、外部链接，甚至引用其他帖子。每种嵌入类型都需要特殊处理。

• 图片：Bluesky 通过其 CDN 提供图片，用户经常在一个回复中发布多张图片。我构建了一个响应式网格布局，根据图片数量进行调整，并添加了全屏查看图片的模态框。
• 外部链接：渲染为带有缩略图和描述的卡片，就像在 Bluesky 应用中一样。
• 其他嵌入类型：由于 AT 协议是可扩展的，可能会出现新的嵌入类型，因此我为其提供了一个优雅的回退消息。

与 Astro 集成

将这一功能与我的 Astro 博客集成非常简单。我已经有了 React 集成（用于背景和音乐组件），并使用 client:load 指令确保评论组件立即加载。

现在，我只需在文章的前言中添加以下内容即可启用评论：

yaml bsky: did: "my-bluesky-did" postCid: "the-post-id"

我学到了什么

TypeScript 是你的朋友

通过 @atcute/client 包，所有 API 响应都有正确的 TypeScript 类型。这使得开发更加顺畅，因为我可以依赖自动补全，并在类型错误成为运行时错误之前捕获它们。

渐进增强有效

我将评论作为博客的增强功能，而不是核心依赖。如果 JavaScript 被禁用或 API 宕机，博客文章（早已渲染）仍然可以正常工作，只是评论不会显示。

默认的性能优化

由于我不需要管理任何后端基础设施，服务器端的性能优化已经内置。Bluesky 的 CDN 处理图片交付，其公共 API 快速且缓存良好，我不需要关心数据库查询或服务器扩展。

结果

我对最终结果非常满意。与传统博客评论相比，讨论感觉更加自然——用户使用他们的真实个人资料，分享图片和链接，更像社交媒体。

下一步

我考虑了一些改进，但说实话，核心系统运行得非常好，我并不急于改变它。有时，最好的解决方案就是那种几乎无形地工作的方案。

为什么这种方法有效

传统的评论系统试图在每个独立网站上重现社交媒体功能。我认为这是本末倒置。人们已经有他们喜欢使用的社交媒体账户。与其强迫他们创建新账户并学习新界面，为什么不尝试在他们已经存在的地方与他们相遇呢？

这种方法随着平台的发展而扩展，因为它利用了平台。随着 Bluesky 的发展，更多的人可以参与博客讨论，而无需我额外的工作。由于一切都建立在开放协议上，我不会被锁定在任何单一平台的决定中。如果 Bluesky 变得不好，我随时可以切换到另一个 AppView，比如 zeppelin 或 Blacksky 的 AppView。

理论上，我甚至可以编写自己的评论 AppView。ATProto 设计灵活，尤其是在数据方面，因此这样做会非常简单。我只需要监听 firehose 上的正确事件，并以合理的方式存储数据，并定期重建评论线程。

在我看来，当独立网站能够连接到更广泛的讨论而不牺牲其独立性时，网络会变得更好。我认为这是其他去中心化平台（如 Mastodon）的目标，但 Bluesky 对用户拥有身份和通过 PDS 实现应用互操作的关注最终使其成为更好的选择。

---

想看看它的实际效果吗？这篇文章下方的评论就是由上述系统驱动的。

评论、问题、疑虑。

在 Bluesky 上加入讨论。

评论主要围绕Bluesky生态系统的优缺点展开，观点多样，既有支持也有质疑。

支持观点： 1. 创新与开放性：多位评论者认为Bluesky为互联网带来了新的开放性和创新。例如，评论3提到：“This is an amazing idea! Not only if fixes the problem of commenting but also allow people to continue the conversion on Bluesky.”（这是一个很棒的想法！它不仅解决了评论问题，还让人们可以在Bluesky上继续对话。）评论9也表示：“Feels like Bluesky is single-handedly making the Internet an open for new ideas again.”（感觉Bluesky正在让互联网重新对新想法开放。）

2. 用户体验：部分评论者认为Bluesky的评论系统设计良好，甚至激发了他们的创作欲望。评论15提到：“I like this a lot! I don't have a blog, but this kind of makes me want to start one.”（我非常喜欢这个！我没有博客，但这让我想开始一个。）

质疑与担忧： 1. 平台依赖与可持续性：多位评论者担心Bluesky的长期可持续性和平台依赖问题。评论10指出：“I'm not optimistic about BlueSky's profitability - the current free-at-point of use is a result of VC funding.”（我对Bluesky的盈利能力不乐观——目前的免费使用是VC资金的结果。）评论13也提到：“If BlueSky banned you tomorrow what is the plan? If BlueSky went bankrupt tomorrow?”（如果Bluesky明天封禁了你，计划是什么？如果Bluesky明天破产了呢？）

2. 用户门槛与兼容性：部分评论者认为Bluesky的用户门槛较高，且与其他平台的兼容性存在问题。评论7提到：“It’s odd to eliminate using GitHub issues as comments because the user would need a GitHub account then decide on bluesky.”（取消使用GitHub问题作为评论很奇怪，因为用户需要GitHub账户，然后决定使用Bluesky。）评论11则建议使用Mastodon：“I’d go with Mastodon which is an actual open protocol with multiple servers and clients and clearly not for profit.”（我会选择Mastodon，它是一个真正的开放协议，有多个服务器和客户端，显然不是为了盈利。）

3. 内容审核：部分评论者对Bluesky的内容审核机制表示担忧。评论4和5都提到了这个问题：“Nice. But what about moderation?”（不错，但内容审核呢？）“Only thing I’m wondering about with this is how do you moderate the comments? Delete spam or rude comments?”（我唯一担心的是如何审核评论？删除垃圾或粗鲁的评论？）

其他观点： 1. 技术借用：评论12提出了“技术借用”的概念：“Id love a term for this sort of thing. It's like tech hijacking or something.”（我很想为这类事情找到一个术语。这有点像技术劫持。）

2. 历史对比：评论16和17提到了其他类似的评论系统，如Webmention和Mastodon：“Reminds me of https://indieweb.org/Webmention”（这让我想起了https://indieweb.org/Webmention）“See also: Toot toot! Mastodon-powered Blog Comments [2023]”（另见：Toot toot! Mastodon驱动的博客评论[2023]）

总结：Bluesky的评论系统在创新和开放性方面受到认可，但其可持续性、用户门槛、内容审核等问题也引发了广泛讨论。部分评论者建议使用其他更成熟的开放协议，如Mastodon。