普通视图

发现新文章,点击刷新页面。
昨天以前wzyboy's blog

更换博客评论系统

作者 wzyboy
2024年5月23日 01:02

最近帮家属装修她的博客,我发现装修博客比写博客有意思多了,于是也动起了装修自己博客的念头。本文记录了我把博客的评论系统从 Disqus 更换为 Twikoo 的过程。

一、越来越烂的 Disqus

本博客的搭建工具/平台经历了三个阶段:

  • 2009 年~2010 年:搭建在 Blogger.com 上——当时 Blogger 已经被 Google 收购了;
  • 2010 年~2017 年:「自豪地由 WordPress 驱动」——迁移到自建平台的原因我记不清了,似乎是因为 Blogger 被墙了;
  • 2017 年~现在:使用 Lektor 静态生成。

静态博客相比 WordPress 虽然有诸多优点,但最大的问题在于评论系统很难做成静态的。我刚把博客做成静态的时候想着干脆不做评论系统了,读者如果想留言就寄送电子邮件。后来考察了一番,还是加了一个 Disqus 评论系统,但默认不加载,需要访客点击启用——我看到那一堆慢吞吞的 JavaScript 加载动画实在是心烦。

用了几年 Disqus 之后,这货逐渐走上了 enshittification 的道路。免费用户的网站将被 Disqus 强制插入广告,不仅占地面积很大,且内容多为猎奇 clickbait。请看友人的博客上被 Disqus 插入的巨幅猎奇广告:

rerox-com-disqus-ads

出于未知原因,我的 Disqus 继承了一个祖父计划,因此没有广告:

disqus-plus-plan

但我依然对 Disqus 不满。尤其是 2021 年时,有至少十个月,甚至可能长达一年的时间,Disqus 的邮件通知完全是坏的。现在想来,难道是因为 COVID-19 的影响,Disqus 的某些基础设施崩坏了而无人发现或无法修复?

在 2022 年初的时候 Disqus 的邮件系统修好了,我又能收到邮件了——但所有的邮件都会进 Spam!直到本文写作时为止,Disqus 给我发的邮件还是会被 Gmail 归到 Spam 里。哪怕我一遍一遍点 Not Spam 也没有用:

gmail-disqus-spam-1
gmail-disqus-spam-2

二、静态网站评论系统考察

因为 Disqus 越来越烂,我就想找替代品,但 Disqus 又没有烂到完全不能用(尤其是我有无广告祖父计划),所以我也没有太强的动力去折腾更换。两年前,家属使用 Hugo 重建博客,也面临了评论系统选择的难题。家属并没有无广告 Disqus 账号,也不想为了评论系统交 $12/mo 的天价保护费去广告,那就自建吧?

「家属重建博客」和上文提到的「友人发现他的博客被 Disqus 插入巨幅广告」这两件事是差不多时间发生的,当时我和友人也讨论了一下自建博客评论系统的选择。最终友人为自己的博客搭建了 Golang 写的 Remark42,我为家属的博客搭建了 Python 写的 Isso,我自己的博客则继续用 Disqus。

两年后的现在,我帮家属博客装修的时候发现:友人的 Remark42 不知何时挂了,家属博客的 Isso 虽然还在跑着但是有内存泄露问题,只有 Disqus 依然在苟活。这时候我突然想通了一件事:

静态博客的优点就是无状态、轻量,不需要操心操作系统和软件更新的问题,运维成本极低;如果再自己维护一个评论系统,就把这些优点全部抵消了!

如何解决这个问题呢?像 Disqus 这样的全托管平台也是有的,但是我是不敢用的。自建平台又往往需要在自己的服务器上跑一个 Python / Node.js / Golang 程序,怎么办呢?

在对比调研各种评论系统的过程中我发现了一个全新的视角:serverless 部署。仔细想想,评论系统的后台其实需要处理的事件并不多,无非就是发表评论、拉取评论列表、编辑或删除自己发的评论,最多就是再加个邮件通知功能。这些功能都是可以在一个 HTTP 请求里完成的,这不是正是 serverless computing 最擅长的赛道吗?用 serverless 的评论系统,我就不需要担心运维问题,也不需要占用自己服务器的 RAM,同时又维持了自己对数据的掌控。

经过一些对比,我最终选择了 Twikoo 评论系统。这一评论系统支持运行在多个 serverless 平台上,使用 MongoDB 作为存储,支持消息推送和邮件通知。根据 GitHub 上的信息,作者还是一个大学生,应该是 00 后吧。顺便,Twikoo 用的消息推送 SDK 也是同一作者写的。年轻有为啊!

三、搭建 Twikoo

Twikoo 被许多简体中文独立博客所采用,搭建教程一大把。不少 serverless 平台提供一定的免费额度,足够运行 Twikoo 了,照着官方教程很快就能搭一个出来。我又写了一个脚本,把 Isso 的 SQLite 里的评论转成 Twikoo 的 JSON 格式再导入——家属的博客就这样从 Isso 迁移到了 Twikoo 评论系统。

发现了 Twikoo 的好,我也想给自己的博客换上。但作为一个 System Reboot Engineer,我对 serverless 平台的要求更高一些,我想要 IaC。家属的 Twikoo 是搭建在 Netlify 上的,而我一直在用 AWS 全家桶,为什么不试试在 AWS Lambda 上跑呢?尤其是两年前 AWS Lambda 增加了 Function URL 功能,不需要配置 API Gateway 了,使用起来更方便了。

Twikoo 本来没有专门对 AWS Lambda 做适配,于是我根据 AWS Lambda Function URL 的文档给上游贡献了一些代码,使它成功地在 AWS Lambda 上跑起来了。

AWS Lambda Function URL 的地址形如 https://axtoiiithbc3vetyqfgq7ozalu0cnkii.lambda-url.us-west-2.on.aws/,真的太长太丑了!反正我的博客本来就在用 AWS CloudFront,干脆加到博客的 wzyboy.im 域名下,这样还能减少一次 CORS preflight 请求

四、导入 WordPress 及 Disqus 里的评论

七年前我从 WordPress 迁移到静态博客的时候,没有迁移评论。后来用上了 Disqus 评论,我也没把 WordPress 评论导入进去。但是现在既然用上了一个数据操作更加方便的平台(指可以直连 MongoDB 进行操作),我就想把 WordPress 和 Disqus 的评论都导入到 Twikoo 里。

Twikoo 支持导入 WordPress 的评论,然而我的 WordPress 早在七年前就已经停服了。我一直留着数据库备份,与其把整个 WordPress 复活再用插件把评论导出,不如直接对数据库进行操作,导出成 Twikoo 的格式而不是 WordPress 的格式。于是我把七年前的数据库备份导入 MariaDB,再快速糊了一个 Python 脚本wp_comments 表里评论导出成 Twikoo 使用的 JSON 格式,然后在 Twikoo 的管理界面导入进去。

Twikoo 也支持导入 Disqus 的评论。我从 Spam 里捞出 Disqus 给我发的评论导入邮件之后,一键导入 Twikoo,才发现这里面居然还有不少垃圾评论(在 Twikoo 里显示为隐藏评论,只有管理员能看到)。这里面有些是真的垃圾评论,有些是 Disqus 误报的。我在 Twikoo 里对这些垃圾评论进行了处理。另外 Disqus 导出的 XML 里不包含 email 字段,无法从 Gravatar 拉取头像。别人的评论没办法,我自己的评论还是可以二次处理一下的。于是把刚刚清理过后的评论再次导出,把我发表的评论都加上我自己的邮箱等信息,然后清空 MongoDB 重新导入,这样就有头像了。

至此,旧评论全部导入到了 Twikoo 里。一共从 WordPress 导入了 1734 条评论,从 Disqus 导入了 211 条评论。其中 WordPress 的评论也包括了 2009 年从 Blogger 导出的评论。

五、尾声

Twikoo 默认打开了展示 User-Agent 的功能,会显示评论者的操作系统和浏览器信息。翻看一下老评论,看到各种 Windows XP、Google Chrome 5.x、Android 1.2 啥的,感觉好怀念!仿佛回到了十几年前,一大批 WordPress 独立博客如雨后春笋遍地蓬勃生长的时代,那时候不少博客都装了一个显示评论者操作系统和浏览器信息的插件。

在我写作本文的时候我刚好读到一篇文章,讲因为中国大陆独特网络环境——内容审查、封闭花园、移动互联网兴起导致传统网页衰落——简体中文互联网上公开的内容,尤其是较旧的内容,正在快速消亡。本博客虽然近年来更新不多,但也已经存续了 15 年,我将尽我所能让它继续存在下去,不要轻易消亡。通过复活 2009 至 2017 年间的旧评论,我也希望能为对抗 link rot尽一份绵薄之力。

那么,欢迎在全新的评论系统里留下评论。《隐私声明》也已更新。

从 LUKS 迁移到 LUKS + LVM

作者 wzyboy
2024年5月10日 23:46

本文记录一下我最近从 LUKS 迁移到 LUKS + LVM 的过程。整理是最好的复习!

背景

Device mapper 是 Linux 里将块设备映射成虚拟块设备的框架。

dm-crypt 是用 DM 进行透明加密的组件。例如:将 /dev/sda2 映射成 /dev/mapper/cryptsda2,则往 /dev/mapper/cryptsda2 这个块设备写入的数据会被加密后实际写入下层的 /dev/sda2 块设备里。

LUKS 是以 dm-crypt 为基础,增加了密钥管理功能的加密实现。

我的笔记本电脑是这样的分区结构:

NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1          259:0    0 476.9G  0 disk
├─nvme0n1p1      259:1    0   512M  0 part  /boot
├─nvme0n1p2      259:2    0 450.0G  0 crypt /
└─nvme0n1p3      259:3    0  26.4G  0 crypt [SWAP]

一个引导分区(p1),一个主分区(p2),一个交换分区(p3)。其中主分区是用 LUKS 加密的,需要我每次开机时输入密码进行解锁;交换分区是以 plain dm-crypt 加密的,其密钥来自 /dev/urandom 提供的随机数据。交换分区以随机密钥进行加密是一种常见做法,密钥只存在于 RAM 里,关机之后交换分区就完全无法解密了,防止 RAM 里的敏感数据留在交换分区里被读取——尤其是在异常关机的时候。

休眠、但是醒不来

这样的加密交换分区有一个问题:无法休眠,确切地讲是能休眠,但是永远醒不来——因为断电之后密钥已经被丢弃了,所以重新开机的时候系统无法读取交换分区里的数据,所以无法恢复到之前的状态。

由于我的笔记本电脑几乎一直是插着电用,所以十几年来很少用到休眠的功能(更别提以前 Linux 休眠醒来之后网卡、扬声器等容易出 bug);偶尔要带出门的话,短时间我就睡眠,长时间我就直接关机。直到最近,由于一连串巧合,我的笔记本电脑没有插电,电池耗尽,系统自动尝试进入休眠状态——成功了,然后就再也醒不来了。

更糟糕的是,systemd 在系统启动时会等待交换分区出现,但因为永远等不到,所以会浪费两分钟等待直到超时。由于「从休眠中醒来」这个任务没有完成,所以下次重启电脑的时候,systemd 还会再等两分钟超时,周而复始。

我实在是不知道如何清除掉这个 flag 让它不要再等。最终我想了个解决方案:systemd 是根据 UUID 去找交换分区的,那我新建一个喂给它不就行了?于是我从日志里找到 systemd 苦等的 UUID,再用 mkswap -U that_uuid 建立一个 swap,再重启一次,果然它就不再等了。事成之后要记得 wipefs 擦掉分区签名,否则以后就一直是明文交换分区了。

结果这样的事情又发生了几次,每次我都要重启几次来修复。痛定思痛,我决定一劳永逸地解决这个问题,不然每次(不小心)触发休眠就会很麻烦。

思路

我调研了多种方法,在虚拟机里尝试了一番,发现最简单的方法是用 LUKS + LVM

LVM 也是基于 DM 的组件,主要用于在块设备上映射出多个逻辑卷(LV),这些 LV 类似于分区,但是不受分区表的限制,可以灵活地调整,甚至可以提供快照等功能。由于我的某些执念,我一直不愿意将两个 DM 套娃使用,因此我笔记本电脑上只有 LUKS,而 NAS 上只有 LVM。实际在虚拟机里测试了一下,发现 DM 叠叠乐也没什么大不了的,因此也就接受了。至于是将 LVM 叠在 LUKS 上,还是将 LUKS 叠在 LVM 上——当然是前者,因为后者和我现在的处境没什么太大的区别,并不能解决加密交换分区的问题。

所以我的分区调整计划是(对照前文的分区结构):

  1. 将 450 GiB 的 p2 和 26.4 GiB 的 p3 两个分区删除,建立一个新的 476.4 GiB 的 p2 取而代之;
  2. 将新的 p2 作为 LUKS 容器,但不在里面直接创建文件系统,而是再叠一层 LVM,在里面创建两个 LV,一个作为主分区(root),一个作为交换分区(swap)。

根据我在虚拟机里的试验,这样调整过后,开机时系统会先解开 LUKS,然后按需求(全新启动还是从休眠中恢复)读取 root 和/或 swap。

实施

在折腾这些分区之前得先备份数据。我的主分区是 450 GiB,但只有 235 GiB 数据在里面。我有块 500 GB 的 SSD 移动硬盘可以暂存数据,这块移动硬盘里最大的一个分区是 377 GiB,倒是够存;但这分区没有加密,而且是 exFAT 文件系统,因此不适合把笔记本电脑里的数据直接复制进去。

那我把整个 LUKS 容器给 dd 进去?这就又太大了,而且由于加密数据块的信息熵极高,所以再怎么压缩也是塞不下的。要不在移动硬盘里创建一个 LUKS 容器然后把文件系统整个倒进去?但是我的笔记本电脑用的是 Ext4 文件系统,似乎并没有像 xfs_copy 那样只复制有用数据块的工具。我灵机一动,想到可以用 BorgBackup 直接直接读取 LUKS 解密后的明文块设备,由于 Borg repo 是加密的,所以可以存到不加密的移动硬盘里。

BorgBackup 甚至专门有个文档解释了这种用法:

  1. 首先用 zerofree 把 Ext4 文件系统里的没用的数据块归零——这工具比 dd if=/dev/zero 更环保、高效
  2. borg create --read-special repo::archive /dev/mapper/luks-xxxx 备份 Ext4 所在的块设备,那些被归零的数据块几乎不会占用存储空间
  3. borg extract --stdout repo::archive | dd of=/dev/mapper/xxxx 恢复 Ext4 到新的块设备上

由于以下操作都是需要对系统分区进行操作,所以我是启动进 archiso 里操作的。在退出主系统之前,先把 /etc/fstab/etc/crypttab 里即将没用的条目给注释掉,防止调整完后进系统时 systemd 又在那儿苦等。

第 2 步完成之后的分区调整命令(根据记忆默写;忘记屏摄了):

# 擦除 p2 上的 LUKS 签名防止被 cryptsetup 误读
wipefs -a /dev/nvme0n1p2
# 删除 p2 p3 并建立新的 p2
sgdisk -d 2 -d 3 -n 2 /dev/nvme0n1
# 在 p2 上创建 LUKS 容器
cryptsetup luksFormat /dev/nvme0n1p2
# 加载 LUKS 容器
cryptsetup open /dev/nvme0n1p2 lukslvm
# 初始化 LVM 并创建两个 LV
pvcreate /dev/mapper/lukslvm
vgcreate arch /dev/mapper/lukslvm
lvcreate -n root -L 450G lukslvm
lvcreate -n swap -l 100%FREE lukslvm

此时应该已经有 /dev/mapper/arch-root/dev/mapper/arch-swap 两个 LV 了。它们的下层设备是 /dev/mapper/lukslvm 这个 LUKS 容器,而 LUKS 容器的下层设备是 /dev/nvme0n1p2 这个 SSD 的分区。这就是 DM 叠叠乐!

此时执行第 3 步,将之前备份的 Ext4 写入到 /dev/mapper/arch-root 上。写入成功后 file -sL /dev/mapper/arch-rootblkid 应该能观察到和原先一样的 UUID。

上述操作中,第 2 步耗时 53 分钟,450 GiB 的文件系统(已用 235 GiB)最终被去重和压缩成 162 GiB 的 Borg repo;第 3 步将压缩后的文件系统写回 450 GiB 的块设备里,耗时 143 分钟。

恢复完成之后,需要调整一下 boot loader 传递给内核的参数:

options rd.luks.uuid=5834fee0-d5f5-4985-aef1-c55d50bd069c rd.luks.options=discard root=UUID=e15bf41d-3922-49a8-abc2-7640f66e318c rw

其中 rd.luks.uuid= 是 LUKS 容器(上文的 /dev/mapper/lukslvm)的 UUID,因为重建了容器,所以这个值需要更新;而 root= 是主分区的 UUID,因为我整个 Ext4 导出到导入,一个字节都没有动过,所以这个值是不变的。

除了更新内核参数,还要确保 initrd 里有 LVM 相关的组件。调整完成之后,退出 archiso 重启,成功进系统!

现在分区布局变成了这样:

NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                       259:0    0 476.9G  0 disk
├─nvme0n1p1                                   259:1    0   512M  0 part  /boot
└─nvme0n1p2                                   259:2    0 476.4G  0 part
  └─luks-5834fee0-d5f5-4985-aef1-c55d50bd069c 254:0    0 476.4G  0 crypt
    ├─arch-root                               254:1    0   450G  0 lvm   /
    └─arch-swap                               254:2    0  26.4G  0 lvm   [SWAP]

试试休眠……成功了!试试唤醒……也成功了!

再也不用小心翼翼害怕休眠了!

2023 年度总结

作者 wzyboy
2024年1月18日 18:38

以往都是在一年的最后几天写年度总结,但这篇 2023 年度总结却是拖到 2024 年才写。

Fediverse

2022 年年末的时候,由于不满 Elon Musk 对 Twitter 的管理,我像许多 Twitter 难民一样,将发表微博客的平台由 Twitter 转移到了 Fediverse。现在我使用 Fediverse 已经一年多了,感觉良好。我的 Fediverse 实例是自建的,计划是像本博客一样,至少运营十年。实例没有向公众开放注册,而是靠朋友之间口口相传,慢慢地增加了少量(不到十人)的用户入驻。有种盖了个楼自己先住进去,然后亲朋好友也都搬来成为邻居的感觉!

在 Fediverse 上,每条帖子不再限制只能 140 个字,因此有时候我本想水一篇博客,最终只是在 Fediverse 上发了一条较长的微博客。

现实生活的忙碌

2023 年四月份的时候,我和家属人生中第一次买房。七月份的时候搬家,之后就忙着各种装修和改造。以前租房的时候,想在墙上挂个东西也会受到房东的限制;现在有了自己的房子,自然是想怎么改造就怎么改造。趁着政府有补贴,我们把天然气取暖换成了电力驱动的热泵空调,把储水式热水器也换成了效率更高的即热式热水器。我自学了一些电工知识,拆开了家里各种开关盒和插座盒,甚至爬到阁楼上增加了新的电路,把家里的开关换成了智能开关,还在房间的天花板上钻孔并安装了吸顶灯。卧室的衣帽间看着也不顺眼,于是我们买了电动工具,把墙垛拆掉,改成了独立衣柜。更大一些的工程,则是请工人来更专业、更有效率地完成。

第一次买房和第一次装修,波折是少不了的。下半年花了很多时间和精力在这些事情,使得我大部分时间处在一个现实生活忙碌的状态。

未能成文的选题

综合上面两点及一些其他原因,2023 年我有好几个想写个博客的选题,最终未能成文:

买房记/装修记

整个流程的时间跨度太大,细节过多,无从下手,而且感觉与本博客的整体基调不搭,最终没写。

BackBlaze 安利文

我一直在用 BackBlaze B2 作为便宜的对象存储,2023 年我尝试了一下它的旗舰产品——整机备份服务。尝试的原因是主要是我有一些重要性较低的数据不值得搞多重备份,但又不能没有备份,我就想着只搞一份异地备份。这些数据体积又较大,传统按容量收费的服务不是很划算。想到我本来就在用 BackBlaze B2,不如试试它不限容量的 Computer Backup 服务。

BackBlaze Computer Backup 是一个订阅制服务,每个授权可用于一台计算机,存储空间是无限的(所有插在电脑上的硬盘都可以备份,包括移动硬盘但不包括网络存储)。需要取回数据的时候,可以免费下载 zip 压缩包,也可以让他们给你快递一个移动硬盘(可退还)。我用了一下感觉体验很不错,新用户引导简洁明快,客户端也小巧灵动。唯一的缺点是不支持 Linux。

当时的价格是 $70/y,现在已经涨价到 $90/y 了如果有感兴趣的读者可以使用我的注册链接获取一个月免费试用(我也可以拿一个月免费时间)。

新电脑

上一次配台式机还是 2016 年的事情了,时隔七年多,我趁着 Black Friday 配置了一台新的台式机。本来想多拍一些美美的照片,水一篇博客,但是因为装修问题,房间里比较乱,最后拼好了也懒得再拍照了。

我对电脑硬件不是很在行,在选购配件的过程中得到了不少友人的指点与帮助,在此特别感谢 @OrcaXS 的指导。

Bazzite 与 Linux Gaming

早在 Valve 刚推出 Proton 这个 Linux Gaming 大杀器的时候,我就听说 Linux 的游戏性能比 Windows 更好了,但是我一直没有正经试过——因为从 2008 年开始,我的 Linux 电脑一直是集显或是「亮机卡」,无论是什么操作系统都是没法好好玩游戏的。2023 年我配置了一台新的台式机,有了强劲的显卡(RTX 4070 Ti),也许可以考虑体验一下 Linux Gaming?友人向我推荐了 Bazzite 这个新鲜玩意儿。

Bazzite 的理念挺先进的,用 Fedora Kinoite 提供的 immutable 系统作为基础,增加一堆 Linux Gaming 所需的软件,还加上 Steam Deck 的 UI,拼出一个稳健且易用的系统。Bazzite 比起桌面操作系统,更像是个手机/游戏机的固件,整个系统作为一个整体升级,极大地减少各软件包之间 ABI 兼容性以及手动安装闭源显卡驱动的痛苦,实在出现问题了还能一键回滚。

然而我插了一块旧 SSD 到新电脑上,安装 Bazzite 实际试了下,发现 rpm-ostree 虽然理念先进,但实际上速度好慢哦。NVIDIA 的垃圾闭源驱动和 Wayland 相性也不好;开源驱动又不支持我的显卡。而且我用 Bazzite 不就是为了减少折腾获得一个开箱即用的体验吗?要是花了过多时间在折腾上,就有点本末倒置了。

算了算了,不折腾了。

书、影、游

小说/轻小说/漫画

2023 年我没有读什么新的小说,只是重读了几本以前读过的小说,还读了一些之前读的轻小说的续作。随着新的一季《无职转生》动画的上映,我把《无职转生》的轻小说从第 8 卷推到了第 20 卷。感想:第 15 卷开始剧情变得好看很多了。

电视剧/电影/动画

影视方面,我看了不少 MCU 里的电视剧,印象最佳的是 WandaVision,之后的感觉一部不如一部。我还是挺喜欢 Marvel 的作品的,从 2008 年的 Iron Man 开始,我每一部 MCU 电影都没有错过,有些甚至专门去看了首映场。但近几年我感觉 MCU 电影的质量愈发下降了。最近的 The Marvels 我还没看,但是听说也是大烂片。

游戏

Steam 统计我 2023 年玩得时间最长的游戏——依然是 Factorio。年末假期的时候,我和几位朋友一起联机,开了一个五人局,还是挺欢乐的。

类似 Factorio 的工厂游戏 Satisfactory 在 2023 年末推出了 Early Access Update 8,加之打折,我便购入玩了一段时间。Early Access 多人模式的 bug 较多,且游戏内的剧情部分还在 WIP 感觉有点无聊,最终没有玩多久,还是回到了 Factorio 的怀抱。

《原神》我 AFK 了一段时间,但 4.0 版本枫丹上线之后,我又回归了——主线剧情还是想跟进一下的。HoYoverse 的新作《崩坏:星穹铁道》也在 2023 年正式开服了。我玩了几个月,感觉是比《原神》更轻松的叙事;一旦习惯了回合制战斗的设定,还挺好玩的。然而下半年由于现实生活的忙碌,我逐渐 AFK 了。

写给 Twitter 用户的 Fediverse 指南

作者 wzyboy
2023年1月13日 10:36

作为一个用了十几年 Twitter 的用户,我于两个月前从 Twitter 迁移到了 Fediverse 联邦宇宙。本文面向 Twitter 难民介绍如何开始使用 Fediverse,以及它与 Twitter 的异同。

一、欢迎来到 Fediverse 联邦宇宙!

如果你没有听说过 Fediverse / Mastodon / Pleroma / ActivityPub 等概念,请先阅读拙作《Fediverse 联邦宇宙》。

简而言之,Fediverse 联邦宇宙是一张不同站长搭建的不同的站点之间互通有无的网络。互通有无是指站点之间虽然域名不同,但是可以互相通信,就像 Email 那样。Fediverse 存在已久,但近期 Twitter 风雨飘摇,大量 Twitter 用户主动或被迫离开 Twitter,使得 Fediverse 社区人数激增。根据 instances.social 的爬虫统计,截至 2023-01-12,在 Fediverse 里已经有超过 1.7 万个站点、705 万用户。

Fediverse 里使用 ActivityPub 协议进行通讯。实现这一协议的服务器软件有很多,目前使用量最大的三个软件是:

  • Mastodon:使用 Ruby on Rails + Node.js 构建,站点和用户数量最多,以至于有些人直接以 Mastodon 代指 Fediverse;
  • Pleroma:使用 Elixir 构建,相比 Mastodon 来说非常轻量;
  • Misskey:使用 TypeScript 构建,UI 自定义性非常强。

此外还有类似 Instagram 的 Pixelfed 和类似 YouTube 的 PeerTube 等都是 Fediverse 里的成员。本文主要关注类似 Twitter 的 Fediverse 软件。

二、选择你的站点

如上文所说,不同站长搭建的不同域名的 Fediverse 站点之间是可以互相通讯的,因此在目前那 1.7 万个站点中的任何一个注册账号,都算是加入了 Fediverse(你想注册多个也没关系)。虽说站点数量很多,但并不是所有站点都对公众开放注册。由于近期 Twitter 难民潮,不少大型站点服务器承载不住压力而暂时关闭了注册。我推荐在选择站点时考察以下几点:

  • 域名。正如注册一个电子邮箱一样,你所选择的站点的域名会成为你在 Fediverse 的用户名的一部分,所以选择一个域名好看、好记的站点吧!
  • 站规。不同站点有不同的规则,选择一个你志同道合的站点很重要。
  • 管辖权。根据站点服务器所在国家的不同,用户所需要遵守的法律也不同。比如在一些日本的站点中,萝莉控相关内容是允许的,但是在欧洲一些国家,这些内容是违法的。
  • 安全及隐私。如果你居住在中国,建议选择一个服务器不在中国大陆,且站点管理员也不在中国大陆的站点,以免因言获罪
  • 站点稳定性。有些站点会公示自己的服务状态,选择一个较为稳定的站点,可以减少重温 Twitter 大鲸鱼的机会!

目前用户数量在 10k 以上的简体中文站点有四个,均由 Mastodon 驱动:

  • m.cmx.im——也称「草莓县」,目前 35k 用户。该站前身为 cmx.im,前任站长被喝茶后关站,新站域名改为 m.cmx.im站点博客
  • alive.bar——也称「活吧」,目前 28k 用户。
  • wxw.moe——也称「呜站」,目前 20k 用户。服务状态
  • o3o.ca——也称「嘟站」,目前 16k 用户。由位于加拿大的非盈利团体 O3O 维护。服务状态

请自行考察各站情况之后选择加入哪个。注册账号之后,可使用 Movetodon 检查你的 Twitter 好友在 Fediverse 里的用户名并一键关注。

作为一个 System Reboot Engineer,我也维护了一个 Fediverse 站点 dabr.ca

如果你也是 Twitter 难民并和我在 Twitter 上互相关注,欢迎 DM 我获得注册链接。

三、选择你的网页端/客户端

十几年前,Twitter 第三方网页端很流行。一方面是因为当时 Twitter 本身并不能发图,也没有链接缩短服务,第三方网页端集成了图片预览、上传图片到图床并插入链接、链接缩短等方便的功能,比官方网页好用;另一方面是对于在生活在中国的推友来说,在 Twitter 被墙之后,搭建一个第三方网页端便可免翻墙刷推、发推,较为方便。那时自建博客也很流行,很多推友都有一个自己域名和 PHP 主机跑着 WordPress,额外再加一个 embr 之类不费什么力气。

可惜当年较为开放的 Twitter,现今已经严格限制其 API 的使用了,扼杀了大量优秀的第三方客户端。幸运的是,Fediverse 里的开源软件们并没有那么多限制,因此各种 Fediverse 网页端/客户端可谓百花齐放。

基于静态文件的网页端(点开即用):

Android 客户端:

  • Tusky——对 Mastodon 支持较好;
  • Husky——对 Pleroma 支持较好;
  • Fedilab——界面略复杂但是功能较丰富;
  • Twidere——似乎是目前唯一一个能将多账户时间线合并的;
  • Twidere X——据说是 Twidere 的新版,我没试过,不过看起来还不错。

iOS 客户端:

  • Toot!——我不怎么用 iOS,这是家属推荐的,我用了一下的确挺好用。

还有两个我觉得挺有趣的需要后端支持的网页端:

  • Bloat——极简主义,不需要 JavaScript;
  • Halcyon——高仿 Twitter,但是 PHP。

四、Fediverse 与 Twitter 的不同

术语

Twitter 里发的内容叫「tweet」,原义是鸟叫,通常译为「推」。Fediverse 里对用户发的内容没有一个统一的称谓,用户量最大的 Mastodon 把它叫「toot」,原义是象鸣,通常译为「嘟」。ActivityPub 协议里把用户发的东西叫「Note」,但太拗口了我没见人平时这么用的。我觉得用中立的「status」(状态)或「message」(消息)也挺好。

用户名

Fediverse 的用户名由两部分组成,形如 @username@example.org。如果两个账户前面部分一样但是域名不一样,那它们可能不属于同一个人。有些自建站点的用户起了类似于 @i@example.org 这样的用户名,导致别人 @ 的时候可能会自动补全一大堆 @i@... 开头的账户,需要注意区分。如果你也想自建的话,建立谨慎选择自己的用户名。

如果 @ 的人和自己是同一域名的话,域名部分可以省略,服务器会自动识别这是一个本站用户。

时间线

与 Twitter 只有一条 timeline 不同,Fediverse 里的时间线通常分为三条:

  • Home timeline:你 follow 的人发的内容;
  • Local / public timeline:当前站点的所有人发的公开内容;
  • Known network / federated timeline:与当前站点相连的所有站点的所有人发的公开内容。

@alice@foo.tld 关注了 @bob@bar.tld,那 foo.tldbar.tld 就算相连了,Bob 发布的公开内容除了会显示在 Alice 的 home timeline 里,也会进入 foo.tld 的 federated timeline 里。

除了这些用户间的关注之外,站点管理员可以通过 relay 同时连接很多站点,使 federated timeline 丰富起来。

可见范围

与 Twitter 只有账户级别的公开/锁推两种状态不同,Fediverse 里用户账户的状态(是否上锁)和单条消息的可见范围是独立存在的。消息的可见范围有:

  • direct——只有提及的用户才能看到这条消息
  • followers-only——只有关注你的用户才能看到这条消息
  • unlisted——不会显示在 public timeline 上,但是关注你的用户可以在 home timeline 里看到,任何点进你主页的人(包括游客)也能看到
  • public——完全公开

用户账户上锁之后,别的用户需要你批准才能关注你(和 Twitter 一样),但上锁账户依然可以发送 public 的消息,让没有关注你的用户也能看到。这一特性比 Twitter 灵活多了。你也可以反向操作,不上锁但是发 follower-only 的内容,激励别人关注你。

需要注意的是,Fediverse 的 direct 消息和 Twitter DM 不同——它并不是两个人之间的私密对话,而只是一条只有提及用户的才能看到的消息。如果 Alice 和 Bob 在互发 direct 消息的时候不小心提及 Charlie,那 Charlie 也是能看到这条消息的。这些 direct 消息也会出现你的个人主页上,只不过提及的人才能看到而已。

Pleroma 有一个仅限 Pleroma 用户之间的 Chats 功能,是类似 Twitter DM 的私密对话。

富文本

Twitter 发文只能发纯文字,但 Fediverse 之间传递的消息其实是 HTML。所以只要客户端支持,用户是可以用 HTML / Markdown / BBCode 之类各种格式撰写内容,然后统一转换成 HTML 发出去的。Pleroma 和 Misskey 都支持丰富的撰写格式,但 vanilla Mastodon 不支持(但是能正常显示别人发的)。

标题 / CW / 内容警告

与 Twitter 只有正文不同,Fediverse 里的消息可以有标题。在主流 Fediverse 客户端里,如果一条消息有标题,则会把标题作为 CW(content warning)显示,正文部分需要手动展开。这一功能常常被用来标记 NSFW 内容或剧透。

转推 / 转嘟?

Fediverse 没有 Twitter 那样的 quoted retweet 的功能。如果强行在发文时附带一条别人的链接,有些客户端能显示出预览,但是被引用的那个人并不会收到任何通知。


本文地址: https://wzyboy.im/post/1513.html 。转载请注明出处。

❌
❌