Blog/source/_posts/2023/06/使用 Mastodon 作为博客的评论系统.md
2023-06-24 02:25:37 +08:00

5.2 KiB
Raw Permalink Blame History

author title date tags category fedi_url
SouthFox 使用 Mastodon 作为博客的评论系统 2023-06-16 11:20:30
Mastodon
联邦宇宙
技术
技术 https://foxsay.southfox.me/@SouthFox/110552875318585284

又在博客的评论系统上左右摇摆了,就算没有人来评论。

之前写过一篇使用 Giscus 作为博客评论系统的文章,一年下来的使用体验感受良好,只需要经过一点点配置就能为博客嵌入一个支持 Markdown 支持、代码高亮、表情回应、邮件通知、数据背靠 GitHub的评论系统,性价比十分之高。但代价也是背靠 GitHub 作为一个大商业公司「发病」是一个不断扔骰子的过程随着时间流逝扔出个「大发病」的概率将会趋近于必然。可能是什么「大会员」或是「API 收大费」。为了避免最坏情况发生所以有必要准备一些备选方案。

比如 Cusdis 是我之前尝试过一阵的评论系统方案,虽然各方面都比较优秀,但是它上面的一些小小「毛刺」最终让我放弃继续使用(主要是一些样式问题),更大的原因也是我开始觉得为了一年不到十多条的评论是否有必要开一个数据库+评论系统。

所以最后是打算复用一些已经建立的应用作为博客的评论系统,例如 cactus 评论系统就可以使用 Matrix 聊天协议作为博客的评论系统。不过我觉得着有点「重」了,而且 Matrix 主流实现 Synapse 对于房间、媒体管理这些支持并不算太好,要是被恶意刷请求之后很难清理干净。

所以最后将目光放向了 Mastodon ,现在谷歌上搜索 mastodon blog comment 就能搜索出很多方案本次我也是参touqiefenghe了其中两篇的解决方案

Adding comments to your blog, powered by mastodon

Mastodon as comment system for your static blog

主要思想就是利用 Mastodon 的帖子 API 获取一条博文下的所有回复,然后处理后插入的指定位置,并不是太复杂。

实现

作为一个备选方案我并没有删掉之前基于 Giscus 的评论方案,现在是处于共存状态。要启用基于 Mastodon 的方案就在文章的元数据中指定 fedi_url 这个变量:

<% if (item.no_comment){ %>
  <!-- no comment -->
<% } else { %>
  <% if (item.fedi_url){ %>
    <div id="comments">
      <p id="mastodon-comments-list"></p>
      <script src="<%- url_for('./js/fedicomment.js') %>" post-url="<%- item.fedi_url %>"> async</script>
    </div>
    <noscript>Enable JavaScript to view the comments.</a></noscript>
  <% } else { %>
    <script src="https://giscus.app/client.js"
				data-*="……"
            async>
    </script>
  <% } %>
<% } %>

然后引入 fedicomment.js 这个文件,不直接通过模板直接写入主要还是因为自己自找没趣设置了 CSP 禁止 inline javascript

<script src="<%- url_for('./js/fedicomment.js') %>" post-url="<%- item.fedi_url %>"> async</script>

这一段指定了 post-url 这个属性,作为一个变量传入脚本文件里,参见:Get data attribute of script tag?

之后在脚本文件里将作为全局变量调用:

var post_url = document.currentScript.getAttribute("post-url");

实际的脚本文件课参见 GitHub 上: fedicomment.js (毕竟要是直接复制过来也太凑字数了),不过实际也是整合了前面提到的两篇参考文章。

缺点

**麻烦:**使用这套方案的最大特点就是要多一步操作,因为 Mastodon 的帖子 id 是根据时间戳生成的,不能提前知晓。所以得在 Mastodon 发好文然后获取帖子链接才能插入到博文这里。或许通过配置自动构建的形式使用帐号的 token 预先发好帖然后自动插回文件再提交是种解决办法,但是肯定少不了折腾。而且虽说是在博客上的评论系统但是不能在博客上直接评论。

**管理:**如果不是身为站点管理员的话,那么将无法管理帖文下恶意评论,只能在站点层面的封禁才能移除评论。而且即使身为管理,想要删除单条帖文还得先进行「检举」操作标记这条帖文,然后在管理后台才能删除单条帖文的操作。

**限制:**如果站点开启了「安全模式」的话,那么将无法直接调用帖文的 API ,这样自然谈不上在博客中显示评论了。

总结

总体来说,对于想复用服务的人或是联邦爱好者来说可以一试,不过其实相比 Mastodon ,直接在博客上用 Serveless 函数平台服务兼容 ActivityPub 协议似乎是个更好的选择?不过这就相当于从依赖 GitHub 改为依赖其它平台了……