From 25c8452de162cb21cb5112c67232e08255a323df Mon Sep 17 00:00:00 2001
From: BigCoke233 <hi@guhub.cn>
Date: Sun, 1 Feb 2026 00:30:35 +0800
Subject: docs: new draft

Former-commit-id: 55b4ef5c75e462788a717242d8f5428aaf25b2cf
---
 content/posts/site-report-4.md | 53 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 content/posts/site-report-4.md

(limited to 'content/posts')

diff --git a/content/posts/site-report-4.md b/content/posts/site-report-4.md
new file mode 100644
index 00000000..5705d537
--- /dev/null
+++ b/content/posts/site-report-4.md
@@ -0,0 +1,53 @@
++++
+title = '极客死亡计划书 IV'
+subtitle = ''
+slug = 'site-report-4'
+tags = []
+categories = '极客死亡计划书'
+date = 2026-01-31T21:20:42+08:00
+draft = true
+toc = true
++++
+
+[书接上回](/posts/site-report-3/#:~:text=%E6%88%91%E5%9C%A8%E8%BF%99%E9%87%8C%E5%85%88%E7%95%99%E4%B8%80%E4%B8%AA%E5%BC%95%E5%AD%90%EF%BC%8C%E5%85%B3%E4%BA%8E%E8%AF%84%E8%AE%BA%E7%B3%BB%E7%BB%9F%E7%9A%84%E5%8F%98%E6%9B%B4%EF%BC%8C%E5%A4%A7%E6%A6%82%E4%BC%9A%E7%95%99%E5%88%B0%E3%80%8A%E6%9E%81%E5%AE%A2%E6%AD%BB%E4%BA%A1%E8%AE%A1%E5%88%92%E4%B9%A6%20IV%E3%80%8B%E6%9D%A5%E5%86%99%E4%BA%86%E3%80%82)，先前的一期《极客死亡计划书》最后留了个有关评论系统的引子。如你所见，目前我已经完成了评论系统的变更：**我把它删掉了**。当然，我提供了其他交流的途径，你仍然可以与我和其他读者，像在正常的评论系统中一样讨论文章内容。今天的文章将会解释评论系统变更的原因、我对独立博客的评论的想法，以及我对不同类型评论的态度，最后，读者还可以了解到如何使用新的「交互」系统。<!--more-->
+
+## 本博客评论系统的历史变更
+
+从 Typecho 换到静态博客之后，给博客添加评论系统就变得很棘手。本质上，评论是「用户生成内容」（User-generated content），涉及到用户向服务器发送 HTTP 请求，服务器响应请求后将评论数据写入数据库并返回状态信息，其他用户访问页面时，服务器会从数据库读取评论数据。显然，对于静态网站而言，服务器和数据库都是不存在的，所以就需要外接一个评论后端。
+
+记得早年间我还使用过 [Gitalk](https://github.com/gitalk/gitalk)，一个基于 GitHub Issues 的评论系统。后来 GitHub Discussion 推出，更符合「讨论」这个逻辑，于是 [Giscus](https://giscus.app/) 也就诞生了，几天前，我还在使用 Giscus 作为博客的评论系统。这两个评论系统都依托于 GitHub API，需要 GitHub 账号才能使用。用户也不真正拥有自己的数据，所有的讨论实际上都发生在 GitHub 这一个平台上。上一期极客死亡计划书我也表达了对 Giscus 的批评——依赖于 `<iframe>`，使得数据交换、优化加载速度和自定义都变得很难。不过，毋庸置疑地，Giscus 非常易用，不需要自己维护后端，使用 GitHub 登录也避免了绝大多数的垃圾邮件。
+
+在此之前，我也有使用过 Valine 和 Waline，它们都依托数据库，可以很轻易地在 LeanCloud 上部署（不过就在最近，LeanCloud 已经停止服务了），也可以自托管。我也有听闻，并且作为访客使用过其他人网站上的 Twikoo、Artalk 和 Remark42。这些评论系统的设计各有特色，但共同之处是你需要自己搭建并维护后端和数据库，这不难，但必然会增加网站架构的复杂性。
+
+动态博客加上评论系统是顺带的事情，但对于静态博客来说，为静态网页加上动态的内容，还要单独维护一个后端，就显得有些不符合静态网站这种架构的哲学了——*既然你都选择维护额外的后端和服务器了，那你为什么不直接用动态博客呢？反正都要有后端的，一个轻量的 CMS 并不会占用太多资源。*
+
+本来我是为了摆脱 Giscus，才开始思考要不要自托管评论系统这件事的，但我很快意识到我并不想增加网站的复杂性。如果使用传统的填写称呼、电子邮箱和网址直接评论的方式，就会有身份被冒充的风险（获得某人的邮箱地址简直是轻而易举），而且垃圾信息也很难避免，需要做额外的措施。如果使用必须登录才能评论的方式，的确能解决上述问题，但我希望自己的个人信息被上传到尽可能少的地方，而且如果要变更邮箱地址，四处更改账号信息也是吃力的活儿，我的上网原则之一是「如非必要，绝不注册」，我当然不希望我的读者必须额外注册才能评论，维护一个用户认证系统也会让维护后端变得更复杂。
+
+显然，这已经告别了绝大部分的评论系统了。
+
+为了认证用户且不必维护新的认证系统，那么最简单的方式当然是使用一个现有的认证系统。我指的并不是 Google 登录、Apple 登录和社交媒体账号登录这种方案，因为实际上我仍然需要将用户的登录信息储存在自己的数据库里。最好是使用去中心化的身份系统，比如 OpenPGP 密钥对。
+
+## Email and OpenPGP
+
+诚然，OpenPGP 也受到批评，它有时会[失效](https://gpg.fail/)。不过，在本文中，我们**假定**它是有效的，~~因为我还没有开始了解和研究它为什么有缺陷~~，而且，OpenPGP 也有替代品，你可以把本文中提及的 OpenPGP 理解为「OpenPGP 和与之类似的加密标准」。
+
+在上一期《极客死亡计划书》中，我提到，电子邮件的发信一般是可信的。如果你收到了来自 `hi@eltr.ac` 的邮件，那么发信人基本可以确定就是 Eltrac。尽管也有伪造发信地址的技术手段存在[^1]，但 SPF、DKIM 和 DMARC 等反制手段也很成熟了。在发信协议之上，也可以使用 OpenPGP 加密或者签名邮件[^2]，使用公钥验证再次验证发信人的身份。
+
+所以，如果能开发一种基于电子邮件的评论系统就太好了，大多数用户都有电子邮箱账号，而且电子邮箱是去中心化的，大家可以使用自己熟悉的邮件服务进行评论。我的设想是，评论者向一个电子邮箱地址发送邮件，比如 `comment@geedea.pro`，邮件主题是页面标识（标题、URL 或者别的什么 ID），而邮件正文是评论内容。邮件服务器在这个邮箱收到特定格式的邮件后，如果没有问题，就把它当作有效的评论处理，存入数据库或者通过 CI/CD 工作流直接写入博客源代码。如果用户有提供签名，验证身份之后还可以像 Git commit 那样，在前端显示 `Verified` 或者一把小锁，表示评论者的身份是可靠的。技术上来讲，这完全可行。用户交互层面也不会很麻烦，因为可以使用 `mailto:` 链接，帮用户自动填写邮箱地址和邮件主体，用户只需要在自己的邮件客户端里撰写评论正文。
+
+不过，我仍然需要一个用来接收和处理邮件的后端，把邮件内容写入博客显然也会增加网站架构的复杂度。通过发送邮件在网站上发送评论，仔细想想，其实非常反直觉，用户需要在不同的界面之间跳转，而且邮件发送和服务器处理会造成时延，用户不能立刻得到反馈。
+
+这个方案最终还是没有被我采用，尽管头脑风暴的过程很爽。兴许写下来之后，会有人觉得有用吧。
+
+## Let's ActivityPub
+
+谈到去中心的认证系统，那就不得不谈联邦宇宙了。尽管我并不了解 ActivityPub 规范和设计思想，但我大概了解联邦宇宙的工作方式。简单来说，所有人都可以选择待在自己选择的服务器上，并且与其他服务器通信，构成「互联网」。联邦宇宙并没有提供密码学意义上的身份认证，但至少伪造身份并不容易，尤其是对于那些拥有自己的域名，并且使用这个域名自建联邦宇宙实例的人来说。
+
+比起一对一的电子邮件，开放的联邦宇宙更适合「公开讨论」
+
+## Now, Webmention
+
+[^1]: 参见：[Email Spoofing - Wikipedia](https://en.wikipedia.org/wiki/Email_spoofing)
+
+
+[^2]: 一般来说，不建议发送加密的邮件，因为不符合标准。有关为什么不应该加密邮件内容的讨论，可以参考 [Migadu 的说法](https://migadu.com/procon/#not-encrypted)。况且，有了 SSL/TLS 的保护，邮件在发送过程中往往是安全的。
-- 
cgit v1.2.3